delta-66 bug?

delta-66 bug?

[ian]

hi all,
i've been having sample rate problems with my m-audio delta 66. using
envy24control, i have it set up so that the master clock comes from spdif
(which is always 48K). the spdif is routed to hardware out 3 and 4. using
xmms with the oss output plugin, i'm playing a cd through pcm channels
1&2, which are routed to hardware outs 1&2.
playing audio through spdif is fine, until i try to play using xmms too.
when i do that, the hardware outs 3&4 (where spdif is routed to) get
distorted.
xmms is requesting a sample rate of 44.1K when opening the device, and is
getting it, even though the master clock shuold be locked to spdif (rate
state has the locked option on). isn't the oss layer supposed to be
resampling the pcm input to 48K?
i'm using redhat 7.3, with alsa rc6, and a low latency & rtc patched
2.4.19 kernel.
thanks,
ian






-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: delta-66 bug?

[Jan "Evil Twin" Depner]

Ian,

	I won't even attempt to figure out what you're doing but I wanted to
point out that ALSA 0.9rc6 had major problems setting master clock for
the envy24 chipset.  Try moving up to rc7 or rc8 and see if it gets
better.

Jan

On Mon, 2003-03-10 at 16:42, ian wrote:
> hi all,
> i've been having sample rate problems with my m-audio delta 66. using
> envy24control, i have it set up so that the master clock comes from spdif
> (which is always 48K). the spdif is routed to hardware out 3 and 4. using
> xmms with the oss output plugin, i'm playing a cd through pcm channels
> 1&2, which are routed to hardware outs 1&2.
> playing audio through spdif is fine, until i try to play using xmms too.
> when i do that, the hardware outs 3&4 (where spdif is routed to) get
> distorted.
> xmms is requesting a sample rate of 44.1K when opening the device, and is
> getting it, even though the master clock shuold be locked to spdif (rate
> state has the locked option on). isn't the oss layer supposed to be
> resampling the pcm input to 48K?
> i'm using redhat 7.3, with alsa rc6, and a low latency & rtc patched
> 2.4.19 kernel.
> thanks,
> ian
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: delta-66 bug?

[Jan "Evil Twin" Depner]

It makes sense when you read - "i.e. tries to convert the sample format,
rate or channels automatically when the card doesn't support it
natively".  OTOH, the envy24 chipset *does* support 44.1KHz natively so
maybe it's just confused.  I really don't know much about this, it's
just that I had all kinds of problems with envy24 and ALSA 0.9rc6.  One
thing that I have read (and it sounds reasonable) is that if you're
going to go to 44.1KHz in the end you're probably better off recording
at that rate since resampling from 48KHz to 44.1KHz won't sound as
good.  If you come up with an answer let me know.

Jan



On Mon, 2003-03-10 at 18:11, ian wrote:
> ah, thank you!
> i updated to the latest non-cvs packages. things have got a bit better!
> now if i set the clock to spdif, it stays locked to spdif. so the delta-66
> driver is doing it's job. but now if i use xmms to play a stream through
> pcm, the playback is too fast. (spdif sets the card to 48kHz, and xmms is
> trying to open the pcm device at 44.1kHz). so it would seem there is a
> problem with the oss layer - namely that it is not resampling the stream
> from 44.1kHz to 48kHz.
> or am i not reading the info on this page right?
> http://www.alsa-project.org/~iwai/OSS-Emulation.html
> thanks again!
> ian
> 
> 
> On 10 Mar 2003, Jan "Evil Twin" Depner wrote:
> 
> > Ian,
> >
> > 	I won't even attempt to figure out what you're doing but I wanted to
> > point out that ALSA 0.9rc6 had major problems setting master clock for
> > the envy24 chipset.  Try moving up to rc7 or rc8 and see if it gets
> > better.
> >
> > Jan
> >
> > On Mon, 2003-03-10 at 16:42, ian wrote:
> > > hi all,
> > > i've been having sample rate problems with my m-audio delta 66. using
> > > envy24control, i have it set up so that the master clock comes from spdif
> > > (which is always 48K). the spdif is routed to hardware out 3 and 4. using
> > > xmms with the oss output plugin, i'm playing a cd through pcm channels
> > > 1&2, which are routed to hardware outs 1&2.
> > > playing audio through spdif is fine, until i try to play using xmms too.
> > > when i do that, the hardware outs 3&4 (where spdif is routed to) get
> > > distorted.
> > > xmms is requesting a sample rate of 44.1K when opening the device, and is
> > > getting it, even though the master clock shuold be locked to spdif (rate
> > > state has the locked option on). isn't the oss layer supposed to be
> > > resampling the pcm input to 48K?
> > > i'm using redhat 7.3, with alsa rc6, and a low latency & rtc patched
> > > 2.4.19 kernel.
> > > thanks,
> > > ian
> > >
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Alsa-devel mailing list
> > > Alsa-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/alsa-devel
> >
> >
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: delta-66 bug?

[ian]

ah, thank you!
i updated to the latest non-cvs packages. things have got a bit better!
now if i set the clock to spdif, it stays locked to spdif. so the delta-66
driver is doing it's job. but now if i use xmms to play a stream through
pcm, the playback is too fast. (spdif sets the card to 48kHz, and xmms is
trying to open the pcm device at 44.1kHz). so it would seem there is a
problem with the oss layer - namely that it is not resampling the stream
from 44.1kHz to 48kHz.
or am i not reading the info on this page right?
http://www.alsa-project.org/~iwai/OSS-Emulation.html
thanks again!
ian


On 10 Mar 2003, Jan "Evil Twin" Depner wrote:

> Ian,
>
> 	I won't even attempt to figure out what you're doing but I wanted to
> point out that ALSA 0.9rc6 had major problems setting master clock for
> the envy24 chipset.  Try moving up to rc7 or rc8 and see if it gets
> better.
>
> Jan
>
> On Mon, 2003-03-10 at 16:42, ian wrote:
> > hi all,
> > i've been having sample rate problems with my m-audio delta 66. using
> > envy24control, i have it set up so that the master clock comes from spdif
> > (which is always 48K). the spdif is routed to hardware out 3 and 4. using
> > xmms with the oss output plugin, i'm playing a cd through pcm channels
> > 1&2, which are routed to hardware outs 1&2.
> > playing audio through spdif is fine, until i try to play using xmms too.
> > when i do that, the hardware outs 3&4 (where spdif is routed to) get
> > distorted.
> > xmms is requesting a sample rate of 44.1K when opening the device, and is
> > getting it, even though the master clock shuold be locked to spdif (rate
> > state has the locked option on). isn't the oss layer supposed to be
> > resampling the pcm input to 48K?
> > i'm using redhat 7.3, with alsa rc6, and a low latency & rtc patched
> > 2.4.19 kernel.
> > thanks,
> > ian
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/alsa-devel
>
>



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: delta-66 bug?

[Takashi Iwai]

At Tue, 11 Mar 2003 00:11:43 +0000 (GMT),
ian wrote:
> 
> ah, thank you!
> i updated to the latest non-cvs packages. things have got a bit better!
> now if i set the clock to spdif, it stays locked to spdif. so the delta-66
> driver is doing it's job. but now if i use xmms to play a stream through
> pcm, the playback is too fast. (spdif sets the card to 48kHz, and xmms is
> trying to open the pcm device at 44.1kHz). so it would seem there is a
> problem with the oss layer - namely that it is not resampling the stream
> from 44.1kHz to 48kHz.

the driver doesn't check how is the current spdif input rate, and it
doesn't restrict the possible sample rates for the later open.

the implementation of clock sync with an external source is still an
open question.  for example, when the external clock is changed, how
the driver should handle it...?


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: delta-66 bug?

[Jaroslav Kysela]

On Tue, 11 Mar 2003, Takashi Iwai wrote:

> At Tue, 11 Mar 2003 00:11:43 +0000 (GMT),
> ian wrote:
> > 
> > ah, thank you!
> > i updated to the latest non-cvs packages. things have got a bit better!
> > now if i set the clock to spdif, it stays locked to spdif. so the delta-66
> > driver is doing it's job. but now if i use xmms to play a stream through
> > pcm, the playback is too fast. (spdif sets the card to 48kHz, and xmms is
> > trying to open the pcm device at 44.1kHz). so it would seem there is a
> > problem with the oss layer - namely that it is not resampling the stream
> > from 44.1kHz to 48kHz.
> 
> the driver doesn't check how is the current spdif input rate, and it
> doesn't restrict the possible sample rates for the later open.
> 
> the implementation of clock sync with an external source is still an
> open question.  for example, when the external clock is changed, how
> the driver should handle it...?

It should return an error ASAP.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en