non-interleaved mode

non-interleaved mode

[Steve Longerbeam]

Hi,

The driver for the sound engine I'm working on requires NONINTERLEAVED. 
Will ALSA core give my driver a full period of left-only samples, 
followed by a full period of right-only samples? Or are left/right 
samples split within a single period (ie. first half of period is left 
samples, second half is right samples)?

Thanks,
Steve

Re: non-interleaved mode

[Takashi Iwai]

At Tue, 10 Jul 2007 11:08:01 -0700,
Steve Longerbeam wrote:
> 
> Hi,
> 
> The driver for the sound engine I'm working on requires NONINTERLEAVED. 
> Will ALSA core give my driver a full period of left-only samples, 
> followed by a full period of right-only samples? Or are left/right 
> samples split within a single period (ie. first half of period is left 
> samples, second half is right samples)?

The former case.  The standard non-interleaved buffer consists of
(the same buffer-size of) full-length of mono-streams.


Takashi

Re: non-interleaved mode

[J. Scott Merritt]

On Wed, 11 Jul 2007 10:47:56 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> At Tue, 10 Jul 2007 11:08:01 -0700,
> Steve Longerbeam wrote:
> > 
> > Hi,
> > 
> > The driver for the sound engine I'm working on requires NONINTERLEAVED. 
> > Will ALSA core give my driver a full period of left-only samples, 
> > followed by a full period of right-only samples? Or are left/right 
> > samples split within a single period (ie. first half of period is left 
> > samples, second half is right samples)?
> 
> The former case.  The standard non-interleaved buffer consists of
> (the same buffer-size of) full-length of mono-streams.
> 
> 
> Takashi

Doesn't this depend upon the driver implementation ?  IIRC, I tried to
request NON-INTERLEAVED on the PXA270 AC97 driver and it told me that
wasn't a permitted operation (one of the reasons that I needed to use
mmap access in SALSA-Lib).

Re: non-interleaved mode

[Takashi Iwai]

At Wed, 11 Jul 2007 09:13:24 -0400,
J. Scott Merritt wrote:
> 
> On Wed, 11 Jul 2007 10:47:56 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > At Tue, 10 Jul 2007 11:08:01 -0700,
> > Steve Longerbeam wrote:
> > > 
> > > Hi,
> > > 
> > > The driver for the sound engine I'm working on requires NONINTERLEAVED. 
> > > Will ALSA core give my driver a full period of left-only samples, 
> > > followed by a full period of right-only samples? Or are left/right 
> > > samples split within a single period (ie. first half of period is left 
> > > samples, second half is right samples)?
> > 
> > The former case.  The standard non-interleaved buffer consists of
> > (the same buffer-size of) full-length of mono-streams.
> > 
> > 
> > Takashi
> 
> Doesn't this depend upon the driver implementation ?  IIRC, I tried to
> request NON-INTERLEAVED on the PXA270 AC97 driver and it told me that
> wasn't a permitted operation (one of the reasons that I needed to use
> mmap access in SALSA-Lib).

The latter case, "multi-streams in each period" style, cannot be
represented in ALSA API, more specifically, snd_pcm_channel_info
struct.  Thus, it has to be remapped virtually to the normal
non-interleaved streams (each with full periods), or to avoid mmap and
copy the data inside the driver.

There is another COMPLEX_MMAP access type, but it's also for linear
frames with constant increments, where each channel can be represented
with snd_pcm_channel_info record.  The "multi-streams in each period"
is non-linear.


Takashi

Re: non-interleaved mode

[Steve Longerbeam]

Takashi Iwai wrote:
> At Wed, 11 Jul 2007 09:13:24 -0400,
> J. Scott Merritt wrote:
>   
>> On Wed, 11 Jul 2007 10:47:56 +0200
>> Takashi Iwai <tiwai@suse.de> wrote:
>>
>>     
>>> At Tue, 10 Jul 2007 11:08:01 -0700,
>>> Steve Longerbeam wrote:
>>>       
>>>> Hi,
>>>>
>>>> The driver for the sound engine I'm working on requires NONINTERLEAVED. 
>>>> Will ALSA core give my driver a full period of left-only samples, 
>>>> followed by a full period of right-only samples? Or are left/right 
>>>> samples split within a single period (ie. first half of period is left 
>>>> samples, second half is right samples)?
>>>>         
>>> The former case.  The standard non-interleaved buffer consists of
>>> (the same buffer-size of) full-length of mono-streams.
>>>
>>>
>>> Takashi
>>>       
>> Doesn't this depend upon the driver implementation ?  IIRC, I tried to
>> request NON-INTERLEAVED on the PXA270 AC97 driver and it told me that
>> wasn't a permitted operation (one of the reasons that I needed to use
>> mmap access in SALSA-Lib).
>>     
>
> The latter case, "multi-streams in each period" style, cannot be
> represented in ALSA API, more specifically, snd_pcm_channel_info
> struct.  Thus, it has to be remapped virtually to the normal
> non-interleaved streams (each with full periods), or to avoid mmap and
> copy the data inside the driver.
>
> There is another COMPLEX_MMAP access type, but it's also for linear
> frames with constant increments, where each channel can be represented
> with snd_pcm_channel_info record.  The "multi-streams in each period"
> is non-linear.
>
>
>   

Last night I ran an experiment.  I created a 16-bit stereo .wav file 
with all left samples = 0x5555, and all right samples = 0xAAAA. I then 
played the .wav using aplay, and just before trigger start in my driver 
I searched the DMA buffer for the first occurrence of 0xAAAA. The right 
samples didn't start until exactly half-way through the entire DMA buffer!

So now I'm confused, you say there should be one full period of left, 
followed by one full period of right, but I'm observing that the whole 
buffer is split in half, with the first half left, the second half 
right. How did this happen? Is there any way for a driver to query ALSA 
core about the non-interleaved layout of samples in memory?

I'm running 2.6.21.1 which is alsa-driver 1.0.14rc3, and I'm using 
alsa-lib 1.0.14rc3 and alsa-utils 1.0.14rc2.

Steve

Re: non-interleaved mode

[Jaroslav Kysela]

On Wed, 11 Jul 2007, Steve Longerbeam wrote:

> Last night I ran an experiment.  I created a 16-bit stereo .wav file 
> with all left samples = 0x5555, and all right samples = 0xAAAA. I then 
> played the .wav using aplay, and just before trigger start in my driver 
> I searched the DMA buffer for the first occurrence of 0xAAAA. The right 
> samples didn't start until exactly half-way through the entire DMA buffer!

Yes, it's the right non-interleaved behaviour. You can imagine this layout 
as separate "mono" ring buffers for each channels - see 
snd_pcm_lib_ioctl_channel_info() in pcm_lib.c . Driver might modify 
info->offset if required (see hdsp.c driver for example).

						Jaroslav

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

Re: non-interleaved mode

[Steve Longerbeam]

Jaroslav Kysela wrote:
> On Wed, 11 Jul 2007, Steve Longerbeam wrote:
>
>   
>> Last night I ran an experiment.  I created a 16-bit stereo .wav file 
>> with all left samples = 0x5555, and all right samples = 0xAAAA. I then 
>> played the .wav using aplay, and just before trigger start in my driver 
>> I searched the DMA buffer for the first occurrence of 0xAAAA. The right 
>> samples didn't start until exactly half-way through the entire DMA buffer!
>>     
>
> Yes, it's the right non-interleaved behaviour. You can imagine this layout 
> as separate "mono" ring buffers for each channels - see 
> snd_pcm_lib_ioctl_channel_info() in pcm_lib.c . Driver might modify 
> info->offset if required (see hdsp.c driver for example).
>   

thanks, that cleared everything up for me.

Steve