[alsa-devel] multi pcm and mmap problem

Takashi Iwai tiwai at suse.de
Wed Nov 21 12:01:22 CET 2007

At Wed, 21 Nov 2007 01:58:41 -0500,
terminator356 at users.sourceforge.net wrote:
> After 2 years I've finally traced and fixed a problem
>  which was preventing me from using anything after 
>  ALSA 1.0.9b !
> In ALSA lib 1.0.9b: 
> pcm/pcm_generic.c:
> int snd_pcm_generic_channel_info()
> {
>         snd_pcm_generic_t *generic = pcm->private_data;
>                 return snd_pcm_channel_info(generic->slave, info);
> }
> But in ALSA lib 1.0.15: 
> pcm/pcm_generic.c:
> int snd_pcm_generic_channel_info()
> {
>         snd_pcm_generic_t *generic = pcm->private_data;
>         if (pcm->mmap_shadow) {
>                 /* No own buffer is required - the plugin won't change
>                  * the data on the buffer, or do safely on-the-place
>                  * conversion
>                  */
>                 return snd_pcm_channel_info(generic->slave, info);
>         } else {
>                // Tim: TESTED: This is now called instead of the other one!
>                 /* Allocate own buffer */
>                 return snd_pcm_channel_info_shm(pcm, info, -1);
>         }
> }
> My multi PCM consists of a plughw:0,2 and a hw:1,0
> In ALSA 1.0.9b, all five PCMs ALSA creates for this arrangement
>  create their areas with mmap(). And it works.
> But in ALSA 1.0.15 my hw:1,0 and its multi PCM areas are
>  created with mmap(), and my plughw:0,2 and its PCMs areas 
>  are created with malloc(). 
> Can't hear/record any sound from the plughw:0,2 part of the multi.
> I have verified that ALSA 1.0.15 is copying the plughw:0,2 HW PCM 
>  areas to its LINEAR PCM areas, but NOT finally to its multi PCM areas.
> It just copies all zeros. 
> That's the reason I hear/record no sound from the plughw:0,2 part
>  of the multi PCM.
> So I reverted the function's code back to 1.0.9b and presto!
> It works now, the same as in ALSA 1.0.9b 
> So please tell me, am I missing something?

Well, first of all, could you elaborate what is the real problem you
are facing?  Judging from your description above, it sounds like a
clear bug, but I'm not sure where to start.

In addition to the detailed bug description, a testcase program would
be greatly helpful.

> Should I add something more to my .asoundrc ?
> I see that besides {type multi ... }, there is a {type share ...} defined. 
> *** Does the 'share' have any use here? Can't find any docs on it.

The share type is used only for share plugin, so you can ignore it.

> Also:
> Yes, I can see now, why you made this code change.
> mmap() has limits, so you switched over to malloc().
> Those limits force the user to use small buffers
>  and/or reduce the number of channels created.

No, mmap was never used between plugins.  It was only for the hw layer
even in the earlier verson.  In the earlier version, SHM was used
instead.  But, the plugin buffer is referred only locally, so it makes
no sense to use SHM for that.  That's why now it was switched to
malloc.  (snd_pcm_channel_info_shm() is a rest of the old behavior,
and thus its name is confusing...)


More information about the Alsa-devel mailing list