Memory allocation and the "prealloc" procfile

Memory allocation and the "prealloc" procfile

[Andy Robinson]

I'm using Mandrake 10.1 on a DELL Precision M60.
Soundcard is Intel 82801DB-ICH4
ALSA version 1.0.6

By default, /proc/asound/card0/pcm0p/sub0/prealloc contains the number
64 and SNDCTL_DSP_GETOSPACE reports a total of 16k bytes output space
available. If I
echo 128 >/proc/asound/card0/pcm0p/sub0/prealloc
then SNDCTL_DSP_GETOSPACE reports a total of 32k bytes.

My question is, what is the rest of the "prealloc" memory being used
for? And how can I change the amounts used for whatever other purposes,
so as to get a bigger SNDCTL_DSP_GETOSPACE buffer? It's not such a
problem for me but one of my users reports that with a 128k "prealloc",
he still gets only 4k from SNDCTL_DSP_GETOSPACE. Is it perhaps an ALSA
version issue?

I've asked before about this but still not found the answer. I'd be
grateful for any help.

I did look at the source but found it a bit difficult, as an ALSA
newbie, to see where the decision is being made.

Andy Robinson, Seventh String Software, www.seventhstring.com



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Memory allocation and the "prealloc" procfile

[Takashi Iwai]

At Mon, 04 Apr 2005 10:03:37 +0100,
Andy Robinson wrote:
> 
> I'm using Mandrake 10.1 on a DELL Precision M60.
> Soundcard is Intel 82801DB-ICH4
> ALSA version 1.0.6
> 
> By default, /proc/asound/card0/pcm0p/sub0/prealloc contains the number
> 64 and SNDCTL_DSP_GETOSPACE reports a total of 16k bytes output space
> available. If I
> echo 128 >/proc/asound/card0/pcm0p/sub0/prealloc
> then SNDCTL_DSP_GETOSPACE reports a total of 32k bytes.
> 
> My question is, what is the rest of the "prealloc" memory being used
> for? And how can I change the amounts used for whatever other purposes,
> so as to get a bigger SNDCTL_DSP_GETOSPACE buffer? It's not such a
> problem for me but one of my users reports that with a 128k "prealloc",
> he still gets only 4k from SNDCTL_DSP_GETOSPACE. Is it perhaps an ALSA
> version issue?

It might be.  It's worth to try the latest ALSA version, anyway.

If you want a bigger buffer, you can call SNDCTL_DSP_SETFRAGMENT ioctl
to specify the fragments and its size explicitly.


Takashi


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Memory allocation and the "prealloc" procfile

[Andy Robinson]

> Message: 3
> Date: Tue, 05 Apr 2005 19:16:39 +0200
> From: Takashi Iwai <tiwai@suse.de>
> To: Andy Robinson <andy@seventhstring.com>
> Cc: ALSA devel <alsa-devel@lists.sourceforge.net>
> Subject: Re: [Alsa-devel] Memory allocation and the "prealloc" procfile
> 
> At Mon, 04 Apr 2005 10:03:37 +0100,
> Andy Robinson wrote:
> > 
> > I'm using Mandrake 10.1 on a DELL Precision M60.
> > Soundcard is Intel 82801DB-ICH4
> > ALSA version 1.0.6
> > 
> > By default, /proc/asound/card0/pcm0p/sub0/prealloc contains the number
> > 64 and SNDCTL_DSP_GETOSPACE reports a total of 16k bytes output space
> > available. If I
> > echo 128 >/proc/asound/card0/pcm0p/sub0/prealloc
> > then SNDCTL_DSP_GETOSPACE reports a total of 32k bytes.
> > 
> > My question is, what is the rest of the "prealloc" memory being used
> > for? And how can I change the amounts used for whatever other purposes,
> > so as to get a bigger SNDCTL_DSP_GETOSPACE buffer? It's not such a
> > problem for me but one of my users reports that with a 128k "prealloc",
> > he still gets only 4k from SNDCTL_DSP_GETOSPACE. Is it perhaps an ALSA
> > version issue?
> 
> It might be.  It's worth to try the latest ALSA version, anyway.
> 
> If you want a bigger buffer, you can call SNDCTL_DSP_SETFRAGMENT ioctl
> to specify the fragments and its size explicitly.
> Takashi

I will try a later ALSA version and see what happens.

But I'm still curious to know, what is all
that /proc/asound/card0/pcm0p/sub0/prealloc
memory used for? I specify 128k but only get a 32k buffer reported by
SNDCTL_DSP_GETOSPACE (and one of my users gets only 4k of buffer) ...
where is the rest going? AFAIK this prealloc file relates only to
playback and only to one specific stream.

SNDCTL_DSP_SETFRAGMENT doesn't help - it can change the way the buffer
is divided into fragments but will not increase the total
SNDCTL_DSP_GETOSPACE buffer size (e.g. it can give you twice as many
fragments, of half the size).

This problem doesn't just affect me, it affects users of my software.
Therefore I would be happier if I could find some tweak to ALSA's
configuration to fix this. I consider it more user-friendly for me to
say to them "tweak this configuration file" rather than "you must
install a later ALSA version".

Regards,
Andy Robinson, Seventh String Software, www.seventhstring.com



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Memory allocation and the "prealloc" procfile

[Andy Robinson]

> Message: 5
> Date: Fri, 8 Apr 2005 12:55:29 +0200 (METDST)
> From: Clemens Ladisch <clemens@ladisch.de>
> To: Andy Robinson <andy@seventhstring.com>
> cc: ALSA devel <alsa-devel@lists.sourceforge.net>
> Subject: Re: [Alsa-devel] Re: Memory allocation and the "prealloc" procfile
> 
> Andy Robinson wrote:
> > But I'm still curious to know, what is all that
> > /proc/asound/card0/pcm0p/sub0/prealloc memory used for?
> 
> For the buffer. :)
> 
> > I specify 128k but only get a 32k buffer reported by
> > SNDCTL_DSP_GETOSPACE (and one of my users gets only 4k of buffer)
> 
> Doesn't happen on my machine.  What parameters are you using?
> 
> 
> $ cat ospace.c
> #include <stdio.h>
> #include <fcntl.h>
> #include <sys/soundcard.h>
> 
> int main()
> {
> 	int fd;
> 	audio_buf_info i;
> 	int x;
> 
> 	fd = open("/dev/dsp", O_WRONLY);
> 	x = 1;
> 	ioctl(fd, SNDCTL_DSP_STEREO, &x);
> 	x = AFMT_S16_LE;
> 	ioctl(fd, SNDCTL_DSP_SETFMT, &x);
> 	x = 48000;
> 	ioctl(fd, SNDCTL_DSP_SPEED, &x);
> 	ioctl(fd, SNDCTL_DSP_GETOSPACE, &i);
> 	close(fd);
> 	printf("buffer bytes: %d * %d = %d\n", i.fragstotal, i.fragsize, i.fragstotal * i.fragsize);
> 	return 0;
> }
> $ cat /proc/asound/cards
> 0 [ICH5           ]: ICH4 - Intel ICH5
>                      Intel ICH5 with AD1985 at 0xfebff400, irq 209
> $ cat /proc/asound/card0/pcm0p/sub0/prealloc
> 64
> $ ospace
> buffer bytes: 16 * 4096 = 65536
> $ echo 128 > /proc/asound/card0/pcm0p/sub0/prealloc
> $ ospace
> buffer bytes: 16 * 8192 = 131072
> 
> 
> Regards,
> Clemens

Amazing! Thank you enormously for this, which produces the same result
on my system as yours. It is indeed a matter of ioctl order, as Takashi
Iwai also suggests.

If I add extra SNDCTL_DSP_GETOSPACE/printf at each point to your sample
then I see the following (prealloc is 128) :

       fd = open("/dev/dsp", O_WRONLY);
buffer bytes: 8 * 4096 = 32768

        ioctl(fd, SNDCTL_DSP_STEREO, &x);
buffer bytes: 8 * 8192 = 65536

        ioctl(fd, SNDCTL_DSP_SETFMT, &x);
buffer bytes: 32 * 4096 = 131072

        ioctl(fd, SNDCTL_DSP_SPEED, &x);
buffer bytes: 16 * 8192 = 131072

I don't know know if this surprises you but it certainly surprises me! I
would have expected that if prealloc is 128k then SNDCTL_DSP_GETOSPACE
would tell us 128k ... instead of 32k, just after opening the device.

I have been using the following order:
- open
- SNDCTL_DSP_SETFRAGMENT
- SNDCTL_DSP_GETOSPACE
- set up other parameters (sample rate & format)

my reasoning being that I have read, with regard to
SNDCTL_DSP_SETFRAGMENT in native OSS, that
"NOTE! This ioctl call must be used as early as possible. The optimum
location is immediately after opening the device."
and it seemed natural to me that after SNDCTL_DSP_SETFRAGMENT to ask for
what we want, we call SNDCTL_DSP_GETOSPACE to see what we got. And in
fact this does seem to work on native OSS.

So I will change this to:
- open
- SNDCTL_DSP_SETFRAGMENT
- set up other parameters (sample rate & format)
- SNDCTL_DSP_GETOSPACE

Which seems like it should be ok on native OSS and ALSA too. Come to
think of it, if I was a sloppier programmer and hadn't bothered to call
SNDCTL_DSP_GETOSPACE at all, then everything would have been fine.

I am very happy to have an answer to this problem which has been bugging
me for months, and has prevented some people from using the Linux
version of my software - thank you again. You may be wondering why I
didn't switch to using ALSA directly, but the point is that I want
maximum compatibility, including older systems which don't use ALSA.

Regards,
Andy Robinson, Seventh String Software, www.seventhstring.com



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click