New subject: [alsa-devel] multi pcm and mmap problem

23 Nov 2007

At Wed, 21 Nov 2007 16:27:52 -0500,
Tim wrote:
...
On Wednesday 21 November 2007 06:01:22 am you wrote:
...
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.
OK. First, here's my simple testing .asoundrc :
pcm.multi_rec {
            type multi;
            slaves.a.pcm "hw:1,0";
            slaves.a.channels 12;
            slaves.b.pcm "plughw:0,2";
            slaves.b.channels 16;
            bindings.0.slave a;
            bindings.0.channel 4;
            bindings.1.slave b;
            bindings.1.channel 10;
          }
ctl.multi_rec {
            type hw;
            card 0;
          }
The two cards are SBLive! (emu10k1) and Delta1010LT (ice1712).
And here is the command line I run:
   arecord -I -v -t wav -c2 -r 48000 -f S32_LE -Dmulti_rec -d 3   \
      --buffer-size 128 arecord-multi-ice-emu.wav
My problem is under ALSA 1.0.15 no sound is recorded from slave 'b' - 
 (the plughw:0,2 channel).
When I look at the two generated wav files, the first has data, and the second
 has all zeros.
So as I said before, I found that ALSA is copying data from the 
 plughw:0,2 HW PCM area to its LINEAR PCM area (i.e. the actual conversion
 is taking place), but then somehow the data is not finally copied to its
 multi slave b PCM area - just all zeros are copied.
Hence all zeros are stored in the second wav file.
But with ALSA 1.0.9b, since all the areas are allocated with mmap(),
 it works fine. It is only after ALSA 1.0.9b, that I get the problem.
Because ALSA 1.0.15 is allocating both the plughw:0,2 LINEAR PCM area 
 and multi slave slave b's PCM area with malloc().
It seems ALSA doesn't want to copy to areas created with malloc().
OK, point taken.

The problem is that the multi plugin creates unnecessary local buffer.
It works somehow when the slave is a hw, but it doesn't for other
types.

Try the patch below.  This should fix the problem.  Now the multi
plugin just shadows the slave buffers via mmap.
...
...
...
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...)
My point was this: 
Under ALSA 1.0.9b, (and with my fix to ALSA 1.0.15 to force it to use
 mmap() always - see above), if I run:
     arecord -I -v -t wav -c2 -r 48000 -f S32_LE -Dmulti_rec -d 3   \
        --buffer-size 128 arecord-multi-ice-emu.wav
 it will run. But if I run
     arecord -I -v -t wav -c2 -r 48000 -f S32_LE -Dmulti_rec -d 3   \
        --buffer-size 256 arecord-multi-ice-emu.wav
 it fails with "mmap() failed: Invalid argument".
I quadrupled the available locked memory with a line in 
    /etc/security/limits.conf 
    *               -       memlock          128 
 but the second command line still fails. 
What am I doing wrong? How can I increase mmap() limits?
It must be irrelevant now...


Takashi

diff -r 3539f279ec38 src/pcm/pcm_multi.c

--- a/src/pcm/pcm_multi.c	Wed Nov 21 12:19:43 2007 +0100
+++ b/src/pcm/pcm_multi.c	Fri Nov 23 14:40:39 2007 +0100
@@ -690,13 +690,43 @@ static snd_pcm_sframes_t snd_pcm_multi_m
 	return size;
 }
 
-static int snd_pcm_multi_mmap(snd_pcm_t *pcm ATTRIBUTE_UNUSED)
+static int snd_pcm_multi_munmap(snd_pcm_t *pcm)
 {
+	free(pcm->mmap_channels);
+	free(pcm->running_areas);
+	pcm->mmap_channels = NULL;
+	pcm->running_areas = NULL;
 	return 0;
 }
 
-static int snd_pcm_multi_munmap(snd_pcm_t *pcm ATTRIBUTE_UNUSED)
+static int snd_pcm_multi_mmap(snd_pcm_t *pcm)
 {
+	snd_pcm_multi_t *multi = pcm->private_data;
+	unsigned int c;
+
+	pcm->mmap_channels = calloc(pcm->channels,
+				    sizeof(pcm->mmap_channels[0]));
+	pcm->running_areas = calloc(pcm->channels,
+				    sizeof(pcm->running_areas[0]));
+	if (!pcm->mmap_channels || !pcm->running_areas) {
+		snd_pcm_multi_munmap(pcm);
+		return -ENOMEM;
+	}
+
+	/* Copy the slave mmapped buffer data */
+	for (c = 0; c < pcm->channels; c++) {
+		snd_pcm_multi_channel_t *chan = &multi->channels[c];
+		snd_pcm_t *slave;
+		if (chan->slave_idx < 0) {
+			snd_pcm_multi_munmap(pcm);
+			return -ENXIO;
+		}
+		slave = multi->slaves[chan->slave_idx].pcm;
+		pcm->mmap_channels[c] =
+			slave->mmap_channels[chan->slave_channel];
+		pcm->running_areas[c] =
+			slave->running_areas[chan->slave_channel];
+	}
 	return 0;
 }
 
@@ -850,6 +880,7 @@ int snd_pcm_multi_open(snd_pcm_t **pcmp,
 		return err;
 	}
 	pcm->mmap_rw = 1;
+	pcm->mmap_shadow = 1; /* has own mmap method */
 	pcm->ops = &snd_pcm_multi_ops;
 	pcm->fast_ops = &snd_pcm_multi_fast_ops;
 	pcm->private_data = multi;

    

Re: [alsa-devel] multi pcm and mmap problem

Takashi Iwai

Takashi Iwai

Tim

Takashi Iwai

Tim

Takashi Iwai

Tim

Takashi Iwai

Tim

John Rigg

tags

participants (3)