At Wed, 21 Nov 2007 01:58:41 -0500, terminator356@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...)
Takashi