Buffer size/periods (Layla3G)

Buffer size/periods (Layla3G)

[Mark Hills]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1479 bytes --]

Hello,

I am investigating problems I'm having with recording over long periods. 
I'm using a Layla3G and tested various ALSA versions including 1.0.14 and 
1.0.16 on different machines.

I've noticed that when I open the first pair of subdevices, my request for 
1000ms buffer size is handled differently to other devices:

   $ ./test_buffers "hw:Layla3G,0,0" 1000
   buffer_size=16384 period_size=128

   $ ./test_buffers "hw:Layla3G,0,2" 1000
   buffer_size=32768 period_size=256

   $ ./test_buffers "hw:Layla3G,0,4" 1000
   buffer_size=32768 period_size=256

   $ ./test_buffers "hw:Layla3G,0,6" 1000
   buffer_size=32768 period_size=256

If I try other buffer sizes, I can see is a limit to buffer size of 16384 
samples on the ,0 subdevice, which is also affecting the chosen period 
size. But only on the first subdevice. Is there a reason, or is this a 
bug?

Also, there seem to be failures at certain buffer sizes:

   $ ./test_buffers "hw:Layla3G,0,2" 429
   buffer_size=18912 period_size=96

   $ ./test_buffers "hw:Layla3G,0,2" 430
   set_buffer_time_near: Invalid argument

   $ ./test_buffers "hw:Layla3G,0,2" 431
   buffer_size=19008 period_size=96

Can anyone explain to me what's going on here, or is this also a bug?

The overall problem I'm investigating is snd_pcm_readi() returning 
incomplete buffers after running for long periods until another 
snd_pcm_prepare(). It seems possible that this is related.

Any help is greatly appreciated.

Thanks,

Mark

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1788 bytes --]

#include <stdio.h>
#include <alsa/asoundlib.h>

#define RATE 44100
#define CHANNELS 2

#define CHK(msg, r) \
{ \
	if ((r) < 0) { \
		fprintf(stderr, "%s: %s\n", msg, snd_strerror(r)); \
		return -1; \
	} \
}

int main(int argc, char *argv[])
{
	int r, dir;
	unsigned int p;
	snd_pcm_t *pcm;
	snd_pcm_hw_params_t *hw_params;
	snd_pcm_uframes_t buffer_size, period_size;

	r = snd_pcm_open(&pcm, argv[1], SND_PCM_STREAM_CAPTURE, 0);
	CHK("open", r);

	r = snd_pcm_hw_params_malloc(&hw_params);
	CHK("params_malloc", r);

	r = snd_pcm_hw_params_any(pcm, hw_params);
	CHK("params_any", r);

	r = snd_pcm_hw_params_set_access(pcm, hw_params,
					 SND_PCM_ACCESS_RW_INTERLEAVED);
	CHK("params_set_access", r);

	r = snd_pcm_hw_params_set_format(pcm, hw_params, SND_PCM_FORMAT_S32);
	CHK("set_format", r);

	r = snd_pcm_hw_params_set_rate(pcm, hw_params, RATE, 0);
	CHK("set_rate", r);

	r = snd_pcm_hw_params_set_channels(pcm, hw_params, CHANNELS);
	CHK("set_channels",r);

	if (argc > 2) {
	        p = atoi(argv[2]) * 1000;
		r = snd_pcm_hw_params_set_buffer_time_near(pcm, hw_params,
							   &p, &dir);
		CHK("set_buffer_time_near", r);
	}

	if (argc > 3) {
		p = atoi(argv[3]) * 1000;
		r = snd_pcm_hw_params_set_period_time_near(pcm, hw_params,
							   &p, &dir);
		CHK("set_period_time_near", r);
	}

	r = snd_pcm_hw_params(pcm, hw_params);
	CHK("hw_params", r);

	r = snd_pcm_hw_params_get_buffer_size(hw_params, &buffer_size);
	CHK("get_buffer_size", r);

	r = snd_pcm_hw_params_get_period_size(hw_params, &period_size, &dir);
	CHK("get_period_size", r);

	printf("buffer_size=%d period_size=%d\n",
	       (int)buffer_size, (int)period_size);

	r = snd_pcm_close(pcm);
	CHK("pcm_close", r);

	return 0;
}

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Buffer size/periods (Layla3G)

[Giuliano Pochini]

On Sun, 16 Mar 2008 12:02:58 +0000 (GMT)
Mark Hills <mark@pogo.org.uk> wrote:

> Hello,
>
> I am investigating problems I'm having with recording over long periods.
> I'm using a Layla3G and tested various ALSA versions including 1.0.14 and
> 1.0.16 on different machines.
>
> I've noticed that when I open the first pair of subdevices, my request for
> 1000ms buffer size is handled differently to other devices:
>
>    $ ./test_buffers "hw:Layla3G,0,0" 1000
>    buffer_size=16384 period_size=128
>
>    $ ./test_buffers "hw:Layla3G,0,2" 1000
>    buffer_size=32768 period_size=256

This is caused by the preallocation policy I applied. Since those cards
have a lot of channels I though it is a waste of non-swappable
kernel memory to preallocate memory for each one. So the driver preallocates
128KiB for the first two channels of each device only, which are by far the
most used ones (see echoaudio.c::snd_echo_preallocate_pages()). ALSA does
not allow apps to use buffers bigger than the preallocated memory. In your
test: buffer_size=16384*2 channels*4 bytes/channel = 128KiB.

For channels >=2 the memory hasn't been preallocated, thus it is allocated
upon request. Its limit is 256KiB (see echo3g.c), so your test program gets
proportionally longer buffers.

You can set the amount of preallocated memory from userspace by writing
into the files listed by:

find /proc/asound/ -name prealloc\*


> If I try other buffer sizes, I can see is a limit to buffer size of 16384
> samples on the ,0 subdevice, which is also affecting the chosen period
> size. But only on the first subdevice. Is there a reason, or is this a
> bug?

All periods must have the same length and, on Echoaudio cards, it must be a
multiple of 32. ALSA computes the nearest buffer length to the requested
value and chooses the period length as it prefers because your program
doesn't set it.


> Also, there seem to be failures at certain buffer sizes:
>
>    $ ./test_buffers "hw:Layla3G,0,2" 429
>    buffer_size=18912 period_size=96
>
>    $ ./test_buffers "hw:Layla3G,0,2" 430
>    set_buffer_time_near: Invalid argument
>
>    $ ./test_buffers "hw:Layla3G,0,2" 431
>    buffer_size=19008 period_size=96

This shouldn't happen. I'll give it a look.


> The overall problem I'm investigating is snd_pcm_readi() returning
> incomplete buffers after running for long periods until another
> snd_pcm_prepare(). It seems possible that this is related.

I don't think so. Btw I never really tried to record for long periods. It
may depend on the fact that the DMA counter has a limit of 4GiB and then it
overflows, but the driver should handle it nicely. Do you know after how
many bytes of audio data it fails ?



--
Giuliano.

Re: Buffer size/periods (Layla3G)

[Mark Hills]

Hi Guiliano,

Thanks for the quick reply.

On Sun, 16 Mar 2008, Giuliano Pochini wrote:

> This is caused by the preallocation policy I applied. Since those cards 
> have a lot of channels I though it is a waste of non-swappable kernel 
> memory to preallocate memory for each one. So the driver preallocates 
> 128KiB for the first two channels of each device only, which are by far 
> the most used ones (see echoaudio.c::snd_echo_preallocate_pages()). ALSA 
> does not allow apps to use buffers bigger than the preallocated memory. 
> In your test: buffer_size=16384*2 channels*4 bytes/channel = 128KiB.
>
> For channels >=2 the memory hasn't been preallocated, thus it is 
> allocated upon request. Its limit is 256KiB (see echo3g.c), so your test 
> program gets proportionally longer buffers.

Thanks for the explanation. I'm glad that there is good reason and that 
it's not a bug.

>> If I try other buffer sizes, I can see is a limit to buffer size of 
>> 16384 samples on the ,0 subdevice, which is also affecting the chosen 
>> period size. But only on the first subdevice. Is there a reason, or is 
>> this a bug?
>
> All periods must have the same length and, on Echoaudio cards, it must 
> be a multiple of 32. ALSA computes the nearest buffer length to the 
> requested value and chooses the period length as it prefers because your 
> program doesn't set it.

When I do set it in my program, it is using the requested size in all 
cases. So I've found the period size to be working fine.

>> Also, there seem to be failures at certain buffer sizes:
>>
>>    $ ./test_buffers "hw:Layla3G,0,2" 429
>>    buffer_size=18912 period_size=96
>>
>>    $ ./test_buffers "hw:Layla3G,0,2" 430
>>    set_buffer_time_near: Invalid argument
>>
>>    $ ./test_buffers "hw:Layla3G,0,2" 431
>>    buffer_size=19008 period_size=96
>
> This shouldn't happen. I'll give it a look.

Thanks! I can do any testing you might need -- at the moment I have access 
to two Layla cards in different machines. I've had similar problems 
previously with allocating a buffer of 256 frames, but these problems 
mysteriously disappeared before I was able to produce a meaningful bug 
report, so perhaps they are intermittent.

>> The overall problem I'm investigating is snd_pcm_readi() returning 
>> incomplete buffers after running for long periods until another 
>> snd_pcm_prepare(). It seems possible that this is related.
>
> I don't think so. Btw I never really tried to record for long periods. 
> It may depend on the fact that the DMA counter has a limit of 4GiB and 
> then it overflows, but the driver should handle it nicely. Do you know 
> after how many bytes of audio data it fails ?

I don't, but I've noticed the problems take days to show themselves which 
is a lot larger than 4Gb. I'll do some more detailed investigation and let 
you know.

Thanks for the help, it's greatly appreciated.

Mark

Re: Buffer size/periods (Layla3G)

[Giuliano Pochini]

On Sun, 16 Mar 2008 22:12:39 +0000
Giuliano Pochini <pochini@shiny.it> wrote:

> > Also, there seem to be failures at certain buffer sizes:
> >
> >    $ ./test_buffers "hw:Layla3G,0,2" 429
> >    buffer_size=18912 period_size=96
> >
> >    $ ./test_buffers "hw:Layla3G,0,2" 430
> >    set_buffer_time_near: Invalid argument
> >
> >    $ ./test_buffers "hw:Layla3G,0,2" 431
> >    buffer_size=19008 period_size=96
> 
> This shouldn't happen. I'll give it a look.

Still no luck on this issue. ioctl() called from pmc_hw.c::hw_refine_call()
fails. I'll look at the kernel part tomorrow.


--
Giuliano.

Re: Buffer size/periods (Layla3G)

[Giuliano Pochini]

On Sun, 16 Mar 2008 22:12:39 +0000
Giuliano Pochini <pochini@shiny.it> wrote:

> > Also, there seem to be failures at certain buffer sizes:
> >
> >    $ ./test_buffers "hw:Layla3G,0,2" 429
> >    buffer_size=18912 period_size=96
> >
> >    $ ./test_buffers "hw:Layla3G,0,2" 430
> >    set_buffer_time_near: Invalid argument
> >
> >    $ ./test_buffers "hw:Layla3G,0,2" 431
> >    buffer_size=19008 period_size=96
> 
> This shouldn't happen. I'll give it a look.

It seems that ALSA can't manage to find a working hwparams combo. The card
has the following constraints:

buffer size:	64-32768 frames
period size:	multiple of 32 frames
periods:	2-220

It happens that ALSA restricts the allowable buffer size range to
18976-18976 which is very close to the requested 430ms. This is bad because
the biggest multiple of 32 divisor of 18976 is 32. 18976/32 = 593 > maximum
number of periods. return -EINVAL.

BUFFER_TIME = (430294 430295) -> (430294 430295)
Rule 8 [e20b3944]: RATE = [44100 44100] -> [44100 44100]
Rule 15 [e20b38d0]: BUFFER_SIZE = [18976 32768] -> [18976 18976]
Rule 17 [e20b38d0]: BUFFER_BYTES = [151808 262144] -> [151808 151808]
Rule 19 [e20b3944]: BUFFER_TIME = (430294 430295) -> (430294 430295)

Note that if you change the order of the hw_params_*() calls the problem
goes away. It might show up again for some other values though.

I don't know how to fix it. Any clue ??


--
Giuliano.