Couple of questions

Couple of questions

[Adrian McMenamin]

If my driver declares this:

	.info = (SNDRV_PCM_INFO_NONINTERLEAVED),

Can I expect samples to come in all left followed by all right, or how?
And will cat somefile.wav > /dev/dsp using oss emulation respect that?

And what default frequency can I expect cat to use in the above?

Thanks

Adrian



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Couple of questions

[Takashi Iwai]

At Thu, 16 Mar 2006 00:01:11 +0000,
Adrian McMenamin wrote:
> 
> If my driver declares this:
> 
> 	.info = (SNDRV_PCM_INFO_NONINTERLEAVED),
> 
> Can I expect samples to come in all left followed by all right, or how?

Yes.  It's the non-interleaved format (LLLLLLLL....RRRRRR.....).

> And will cat somefile.wav > /dev/dsp using oss emulation respect that?

Yes.

> And what default frequency can I expect cat to use in the above?

ALSA has no default frequency.  OSS assumes 8kHz for /dev/audio.
/dev/dsp has no default, IIRC, but practically 44.1kHz.

So "cat some > /dev/dsp" is not a good way for testing at all...
It's usable for checking that "something" works at least, but not for
checking the detailed functionality.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Couple of questions

[Adrian McMenamin]

On Thu, 2006-03-16 at 11:42 +0100, Takashi Iwai wrote:
> At Thu, 16 Mar 2006 00:01:11 +0000,
> Adrian McMenamin wrote:
> > 
> > If my driver declares this:
> > 
> > 	.info = (SNDRV_PCM_INFO_NONINTERLEAVED),
> > 
> > Can I expect samples to come in all left followed by all right, or how?
> 
> Yes.  It's the non-interleaved format (LLLLLLLL....RRRRRR.....).
> 
> > And will cat somefile.wav > /dev/dsp using oss emulation respect that?
> 
> Yes.
> 
> > And what default frequency can I expect cat to use in the above?
> 
> ALSA has no default frequency.  OSS assumes 8kHz for /dev/audio.
> /dev/dsp has no default, IIRC, but practically 44.1kHz.
> 
> So "cat some > /dev/dsp" is not a good way for testing at all...
> It's usable for checking that "something" works at least, but not for
> checking the detailed functionality.


Thanks. My problem is I cannot get the alsa utilities to compile/work
(they compile but seg fault on use). Is there a good OSS only app I can
use to test the basic play stuff?



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Couple of questions

[Carlos Munoz]

Adrian McMenamin wrote:

>On Thu, 2006-03-16 at 11:42 +0100, Takashi Iwai wrote:
>  
>
>>At Thu, 16 Mar 2006 00:01:11 +0000,
>>Adrian McMenamin wrote:
>>    
>>
>>>If my driver declares this:
>>>
>>>	.info = (SNDRV_PCM_INFO_NONINTERLEAVED),
>>>
>>>Can I expect samples to come in all left followed by all right, or how?
>>>      
>>>
>>Yes.  It's the non-interleaved format (LLLLLLLL....RRRRRR.....).
>>
>>    
>>
>>>And will cat somefile.wav > /dev/dsp using oss emulation respect that?
>>>      
>>>
>>Yes.
>>
>>    
>>
>>>And what default frequency can I expect cat to use in the above?
>>>      
>>>
>>ALSA has no default frequency.  OSS assumes 8kHz for /dev/audio.
>>/dev/dsp has no default, IIRC, but practically 44.1kHz.
>>
>>So "cat some > /dev/dsp" is not a good way for testing at all...
>>It's usable for checking that "something" works at least, but not for
>>checking the detailed functionality.
>>    
>>
>
>
>Thanks. My problem is I cannot get the alsa utilities to compile/work
>(they compile but seg fault on use). Is there a good OSS only app I can
>use to test the basic play stuff?
>
>
>  
>
Hi Adrian,

Unfortunately, I can't offer any help. I am doing exactly what you are 
doing to test my alsa driver. I'm also using /dev/dsp. However, what I 
noticed when cat'ing a wav file to /dev/dsp is that the 
snd_xxx_playback_pointer() function only gets called for a short while 
and then it's no called any more. The dma buffer is only partially 
filled. The driver is not aware of this and just wraps around the buffer 
repeating the sound data over and over. I compiled aplay with no X 
support (command line only) but can't get it to work. So now I'm in the 
middle of writing a light alsa application to test the driver. I hope to 
have something by tomorrow at the latest. If I ever get it to work I can 
send it to you if you are interested.

Thanks,


Carlos


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Couple of questions

[Lee Revell]

On Thu, 2006-03-16 at 21:08 +0000, Adrian McMenamin wrote:
> Thanks. My problem is I cannot get the alsa utilities to compile/work
> (they compile but seg fault on use).

It would be useful to debug this now that your driver works...

>  Is there a good OSS only app I can
> use to test the basic play stuff?
> 

/usr/bin/play.  I thought it used to be an independent app but the one I
have seems to be part of sox.

Or just write one in C, it will take you 5 minutes.  It's basically cat
file.wav > /dev/dsp and just add ioctls to set the format, sample rate,
etc.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Couple of questions

[Adrian McMenamin]

On Thu, 2006-03-16 at 11:42 +0100, Takashi Iwai wrote:
> At Thu, 16 Mar 2006 00:01:11 +0000,
> Adrian McMenamin wrote:
> > 
> > If my driver declares this:
> > 
> > 	.info = (SNDRV_PCM_INFO_NONINTERLEAVED),
> > 
> > Can I expect samples to come in all left followed by all right, or how?
> 
> Yes.  It's the non-interleaved format (LLLLLLLL....RRRRRR.....).
> 
Will the middle layer still copy over data in the same period size as
for mono in this case? Or does it double - ie one period's worth of left
and one of right?



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Couple of questions

[Lee Revell]

On Thu, 2006-03-16 at 23:34 +0000, Adrian McMenamin wrote:
> On Thu, 2006-03-16 at 11:42 +0100, Takashi Iwai wrote:
> > At Thu, 16 Mar 2006 00:01:11 +0000,
> > Adrian McMenamin wrote:
> > > 
> > > If my driver declares this:
> > > 
> > > 	.info = (SNDRV_PCM_INFO_NONINTERLEAVED),
> > > 
> > > Can I expect samples to come in all left followed by all right, or how?
> > 
> > Yes.  It's the non-interleaved format (LLLLLLLL....RRRRRR.....).
> > 
> Will the middle layer still copy over data in the same period size as
> for mono in this case?

Yes.  One 4 frame period interleaved is LRLRLRLR, non-interleaved
LLLLRRRR.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Couple of questions

[Takashi Iwai]

At Thu, 16 Mar 2006 19:16:36 -0500,
Lee Revell wrote:
> 
> On Thu, 2006-03-16 at 23:34 +0000, Adrian McMenamin wrote:
> > On Thu, 2006-03-16 at 11:42 +0100, Takashi Iwai wrote:
> > > At Thu, 16 Mar 2006 00:01:11 +0000,
> > > Adrian McMenamin wrote:
> > > > 
> > > > If my driver declares this:
> > > > 
> > > > 	.info = (SNDRV_PCM_INFO_NONINTERLEAVED),
> > > > 
> > > > Can I expect samples to come in all left followed by all right, or how?
> > > 
> > > Yes.  It's the non-interleaved format (LLLLLLLL....RRRRRR.....).
> > > 
> > Will the middle layer still copy over data in the same period size as
> > for mono in this case?
> 
> Yes.  One 4 frame period interleaved is LRLRLRLR, non-interleaved
> LLLLRRRR.

The period size is same, but the copy is not done like LLLLRRRR.

As default, the whole buffer is divided to number of channels.  For
example, using two channels,

	|LLLLLLL..|RRRRRRR....|
	|<--- buffer_size --->|

and using six channels,

	|1111....|2222....|.....|6666....|
	|<-------- buffer_size --------->|

where each channel has a length of (period_size * periods) samples.
Unless the buffer size is changed, this assignment of each channel
also isn't changed.

The above is the default behavior.  You can change the assignment as
you like by defining proper copy and silence callback, too.  For
mmap, you need to define CHANNEL_INFO ioctl, too.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Couple of questions

[Adrian McMenamin]

On Fri, 2006-03-17 at 11:13 +0100, Takashi Iwai wrote:

> 
> The period size is same, but the copy is not done like LLLLRRRR.
> 
> As default, the whole buffer is divided to number of channels.  For
> example, using two channels,
> 
> 	|LLLLLLL..|RRRRRRR....|
> 	|<--- buffer_size --->|
> 
> and using six channels,
> 
> 	|1111....|2222....|.....|6666....|
> 	|<-------- buffer_size --------->|
> 
> where each channel has a length of (period_size * periods) samples.
> Unless the buffer size is changed, this assignment of each channel
> also isn't changed.
> 
> The above is the default behavior.  You can change the assignment as
> you like by defining proper copy and silence callback, too.  For
> mmap, you need to define CHANNEL_INFO ioctl, too.
> 

Presumably this is what happens at the start, but when doing a single
period update presumably it is split LLLLRRRR on non interleaved



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Couple of questions

[Takashi Iwai]

At Fri, 17 Mar 2006 20:27:32 +0000,
Adrian McMenamin wrote:
> 
> On Fri, 2006-03-17 at 11:13 +0100, Takashi Iwai wrote:
> 
> > 
> > The period size is same, but the copy is not done like LLLLRRRR.
> > 
> > As default, the whole buffer is divided to number of channels.  For
> > example, using two channels,
> > 
> > 	|LLLLLLL..|RRRRRRR....|
> > 	|<--- buffer_size --->|
> > 
> > and using six channels,
> > 
> > 	|1111....|2222....|.....|6666....|
> > 	|<-------- buffer_size --------->|
> > 
> > where each channel has a length of (period_size * periods) samples.
> > Unless the buffer size is changed, this assignment of each channel
> > also isn't changed.
> > 
> > The above is the default behavior.  You can change the assignment as
> > you like by defining proper copy and silence callback, too.  For
> > mmap, you need to define CHANNEL_INFO ioctl, too.
> > 
> 
> Presumably this is what happens at the start, but when doing a single
> period update presumably it is split LLLLRRRR on non interleaved

No, as I wrote in the above, the assignment of each channel isn't
changed, i.e. the buffer position of each channel remains.

The middle layer handles the whole buffer simply as a bundle of
multiple mono streams.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Couple of questions

[Adrian McMenamin]

On Fri, 2006-03-17 at 21:29 +0100, Takashi Iwai wrote:
> At Fri, 17 Mar 2006 20:27:32 +0000,
> Adrian McMenamin wrote:
> > 
> > On Fri, 2006-03-17 at 11:13 +0100, Takashi Iwai wrote:
> > 
> > > 
> > > The period size is same, but the copy is not done like LLLLRRRR.
> > > 
> > > As default, the whole buffer is divided to number of channels.  For
> > > example, using two channels,
> > > 
> > > 	|LLLLLLL..|RRRRRRR....|
> > > 	|<--- buffer_size --->|
> > > 
> > > and using six channels,
> > > 
> > > 	|1111....|2222....|.....|6666....|
> > > 	|<-------- buffer_size --------->|
> > > 
> > > where each channel has a length of (period_size * periods) samples.
> > > Unless the buffer size is changed, this assignment of each channel
> > > also isn't changed.
> > > 
> > > The above is the default behavior.  You can change the assignment as
> > > you like by defining proper copy and silence callback, too.  For
> > > mmap, you need to define CHANNEL_INFO ioctl, too.
> > > 
> > 
> > Presumably this is what happens at the start, but when doing a single
> > period update presumably it is split LLLLRRRR on non interleaved
> 
> No, as I wrote in the above, the assignment of each channel isn't
> changed, i.e. the buffer position of each channel remains.
> 
> The middle layer handles the whole buffer simply as a bundle of
> multiple mono streams.
> 

So, just to be clear. When I am transferring a "period" I should
actually stream half a period's worth of bytes into the channel playing
the left and half a period into the right - and can advance each dma
transfer through the buffer by half a period length on both the left and
the right side of the buffer



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Couple of questions

[Lee Revell]

On Fri, 2006-03-17 at 23:29 +0000, Adrian McMenamin wrote:
> 
> So, just to be clear. When I am transferring a "period" I should
> actually stream half a period's worth of bytes into the channel
> playing
> the left and half a period into the right - and can advance each dma
> transfer through the buffer by half a period length on both the left
> and
> the right side of the buffer 

No, one period.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Couple of questions

[Adrian McMenamin]

On Fri, 2006-03-17 at 18:46 -0500, Lee Revell wrote:
> On Fri, 2006-03-17 at 23:29 +0000, Adrian McMenamin wrote:
> > 
> > So, just to be clear. When I am transferring a "period" I should
> > actually stream half a period's worth of bytes into the channel
> > playing
> > the left and half a period into the right - and can advance each dma
> > transfer through the buffer by half a period length on both the left
> > and
> > the right side of the buffer 
> 
> No, one period.
> 


How does that work? That would imply that there were half as many
periods in the DMA buffer as specified here...

static snd_pcm_hardware_t snd_pcm_aica_playback_hw = {

	.info = (SNDRV_PCM_INFO_NONINTERLEAVED),
	.formats =
	    (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE |
	     SNDRV_PCM_FMTBIT_IMA_ADPCM),
	.rates = SNDRV_PCM_RATE_8000_48000,
	.rate_min = 8000,
	.rate_max = 48000,
	.channels_min = 2,
	.channels_max = 2,
	.buffer_bytes_max = AICA_BUFFER_SIZE,
	.period_bytes_min = AICA_PERIOD_SIZE,
	.period_bytes_max = AICA_PERIOD_SIZE,
	.periods_min = AICA_PERIOD_NUMBER,
	.periods_max = AICA_PERIOD_NUMBER,
};


As the buffer and period (in bytes) size is constant. 



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Couple of questions

[Lee Revell]

On Fri, 2006-03-17 at 23:51 +0000, Adrian McMenamin wrote:
> On Fri, 2006-03-17 at 18:46 -0500, Lee Revell wrote:
> > On Fri, 2006-03-17 at 23:29 +0000, Adrian McMenamin wrote:
> > > 
> > > So, just to be clear. When I am transferring a "period" I should
> > > actually stream half a period's worth of bytes into the channel
> > > playing
> > > the left and half a period into the right - and can advance each dma
> > > transfer through the buffer by half a period length on both the left
> > > and
> > > the right side of the buffer 
> > 
> > No, one period.
> > 
> 
> 
> How does that work? That would imply that there were half as many
> periods in the DMA buffer as specified here...
> 
> static snd_pcm_hardware_t snd_pcm_aica_playback_hw = {
> 
> 	.info = (SNDRV_PCM_INFO_NONINTERLEAVED),
> 	.formats =
> 	    (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE |
> 	     SNDRV_PCM_FMTBIT_IMA_ADPCM),
> 	.rates = SNDRV_PCM_RATE_8000_48000,
> 	.rate_min = 8000,
> 	.rate_max = 48000,
> 	.channels_min = 2,
> 	.channels_max = 2,
> 	.buffer_bytes_max = AICA_BUFFER_SIZE,
> 	.period_bytes_min = AICA_PERIOD_SIZE,
> 	.period_bytes_max = AICA_PERIOD_SIZE,
> 	.periods_min = AICA_PERIOD_NUMBER,
> 	.periods_max = AICA_PERIOD_NUMBER,
> };
> 
> 
> As the buffer and period (in bytes) size is constant. 
> 
> 

That's why the maximum buffer and period is in bytes not frames.  Stereo
has twice as many bytes per frame than mono.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Couple of questions

[Adrian McMenamin]

On Fri, 2006-03-17 at 18:58 -0500, Lee Revell wrote:
> On Fri, 2006-03-17 at 23:51 +0000, Adrian McMenamin wrote:
> > On Fri, 2006-03-17 at 18:46 -0500, Lee Revell wrote:
> > > On Fri, 2006-03-17 at 23:29 +0000, Adrian McMenamin wrote:
> > > > 
> > > > So, just to be clear. When I am transferring a "period" I should
> > > > actually stream half a period's worth of bytes into the channel
> > > > playing
> > > > the left and half a period into the right - and can advance each dma
> > > > transfer through the buffer by half a period length on both the left
> > > > and
> > > > the right side of the buffer 
> > > 
> > > No, one period.
> > > 
> > 
> > 
> > How does that work? That would imply that there were half as many
> > periods in the DMA buffer as specified here...
> > 
> > static snd_pcm_hardware_t snd_pcm_aica_playback_hw = {
> > 
> > 	.info = (SNDRV_PCM_INFO_NONINTERLEAVED),
> > 	.formats =
> > 	    (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE |
> > 	     SNDRV_PCM_FMTBIT_IMA_ADPCM),
> > 	.rates = SNDRV_PCM_RATE_8000_48000,
> > 	.rate_min = 8000,
> > 	.rate_max = 48000,
> > 	.channels_min = 2,
> > 	.channels_max = 2,
> > 	.buffer_bytes_max = AICA_BUFFER_SIZE,
> > 	.period_bytes_min = AICA_PERIOD_SIZE,
> > 	.period_bytes_max = AICA_PERIOD_SIZE,
> > 	.periods_min = AICA_PERIOD_NUMBER,
> > 	.periods_max = AICA_PERIOD_NUMBER,
> > };
> > 
> > 
> > As the buffer and period (in bytes) size is constant. 
> > 
> > 
> 
> That's why the maximum buffer and period is in bytes not frames.  Stereo
> has twice as many bytes per frame than mono.



Err...yes :)

I am still confused though. In mono, every time a period is played a new
period is loaded into the DMA buffer and then transferred into the
hardware's buffer.

How does this work now - wait for one period to play on the left (or
right) channel and then transfer one period's worth on the left and
right channel (ie ALSA fills the buffer up with 2 periods at a go in
stereo) or transfer half a period's worth on each channel but move the
copy pointer on a full period (ie ALSA transfers just one period's worth
which translates as half a period in either channel) 



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Couple of questions

[Lee Revell]

On Sat, 2006-03-18 at 00:08 +0000, Adrian McMenamin wrote:
> On Fri, 2006-03-17 at 18:58 -0500, Lee Revell wrote:
> > On Fri, 2006-03-17 at 23:51 +0000, Adrian McMenamin wrote:
> > > On Fri, 2006-03-17 at 18:46 -0500, Lee Revell wrote:
> > > > On Fri, 2006-03-17 at 23:29 +0000, Adrian McMenamin wrote:
> > > > > 
> > > > > So, just to be clear. When I am transferring a "period" I should
> > > > > actually stream half a period's worth of bytes into the channel
> > > > > playing
> > > > > the left and half a period into the right - and can advance each dma
> > > > > transfer through the buffer by half a period length on both the left
> > > > > and
> > > > > the right side of the buffer 
> > > > 
> > > > No, one period.
> > > > 
> > > 
> > > 
> > > How does that work? That would imply that there were half as many
> > > periods in the DMA buffer as specified here...
> > > 
> > > static snd_pcm_hardware_t snd_pcm_aica_playback_hw = {
> > > 
> > > 	.info = (SNDRV_PCM_INFO_NONINTERLEAVED),
> > > 	.formats =
> > > 	    (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE |
> > > 	     SNDRV_PCM_FMTBIT_IMA_ADPCM),
> > > 	.rates = SNDRV_PCM_RATE_8000_48000,
> > > 	.rate_min = 8000,
> > > 	.rate_max = 48000,
> > > 	.channels_min = 2,
> > > 	.channels_max = 2,
> > > 	.buffer_bytes_max = AICA_BUFFER_SIZE,
> > > 	.period_bytes_min = AICA_PERIOD_SIZE,
> > > 	.period_bytes_max = AICA_PERIOD_SIZE,
> > > 	.periods_min = AICA_PERIOD_NUMBER,
> > > 	.periods_max = AICA_PERIOD_NUMBER,
> > > };
> > > 
> > > 
> > > As the buffer and period (in bytes) size is constant. 
> > > 
> > > 
> > 
> > That's why the maximum buffer and period is in bytes not frames.  Stereo
> > has twice as many bytes per frame than mono.
> 
> 
> 
> Err...yes :)
> 
> I am still confused though. In mono, every time a period is played a new
> period is loaded into the DMA buffer and then transferred into the
> hardware's buffer.
> 
> How does this work now - wait for one period to play on the left (or
> right) channel and then transfer one period's worth on the left and
> right channel (ie ALSA fills the buffer up with 2 periods at a go in
> stereo) or transfer half a period's worth on each channel but move the
> copy pointer on a full period (ie ALSA transfers just one period's worth
> which translates as half a period in either channel) 
> 
> 

Maybe I'm misunderstanding but...

You wait for one period to play in both channels then transfer one
period for the left channel and one period for the right.  So each DMA
transfer moves twice as much data as the mono case.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Couple of questions

[Adrian McMenamin]

On Fri, 2006-03-17 at 19:17 -0500, Lee Revell wrote:

> Maybe I'm misunderstanding but...
> 
> You wait for one period to play in both channels then transfer one
> period for the left channel and one period for the right.  So each DMA
> transfer moves twice as much data as the mono case.
> 
> Lee


Ah, much clearer now. Thanks



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Couple of questions

[Adrian McMenamin]

On Thu, 2006-03-16 at 11:42 +0100, Takashi Iwai wrote:
> At Thu, 16 Mar 2006 00:01:11 +0000,
> Adrian McMenamin wrote:
> > 
> > If my driver declares this:
> > 
> > 	.info = (SNDRV_PCM_INFO_NONINTERLEAVED),
> > 
> > Can I expect samples to come in all left followed by all right, or how?
> 
> Yes.  It's the non-interleaved format (LLLLLLLL....RRRRRR.....).
> 
> > And will cat somefile.wav > /dev/dsp using oss emulation respect that?
> 
> Yes.


Are you sure about this bit? Either my code is extremely broken or cat
isn't doing anything other than pump the bytes in as a simple stream



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Couple of questions

[Carlos Munoz]

Adrian McMenamin wrote:

>On Thu, 2006-03-16 at 11:42 +0100, Takashi Iwai wrote:
>  
>
>>At Thu, 16 Mar 2006 00:01:11 +0000,
>>Adrian McMenamin wrote:
>>    
>>
>>>If my driver declares this:
>>>
>>>	.info = (SNDRV_PCM_INFO_NONINTERLEAVED),
>>>
>>>Can I expect samples to come in all left followed by all right, or how?
>>>      
>>>
>>Yes.  It's the non-interleaved format (LLLLLLLL....RRRRRR.....).
>>
>>    
>>
>>>And will cat somefile.wav > /dev/dsp using oss emulation respect that?
>>>      
>>>
>>Yes.
>>    
>>
>
>
>Are you sure about this bit? Either my code is extremely broken or cat
>isn't doing anything other than pump the bytes in as a simple stream
>  
>
Hi Adrian,

If I cat a wav file to /dev/dsp I just hear noise. However, if  the 
driver opens/reads the same wav file (bypassing the alsa layer) and 
feeds it to the hardware I get perfect sound. Your may want to try that 
to validate your driver and hardware. You might need to parse the file 
into RL buffers as you read it.


Carlos




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642