ALSA recording unreliable with Envy24 cards

[GoogleCodeExporter]

When using the ALSA source with an Envy24-bases sound card, there are
dropouts and noise in the data.

The reason is that this hardware has a strict limitation on the buffer size
(1/4th of a second at 22 kHz), so the period size that is chosen is almost
as big as the actual buffer size, i.e., the application has almost no
opportunity to read data before an overrun occurs.

This can be solved by not trying to set a fixed period size; see the patch.

Original issue reported on code.google.com by cladisch@googlemail.com on 25 Nov 2009 at 12:01

Attachments:

• alsa-periods.diff

[GoogleCodeExporter]

Can you please explain me why do you use other alsa function, and if this patch 
may
put other soundcards recording under any risk of malfunctioning?
If it offer no risk, I can apply the patch to trunk.

Original comment by rafael2k...@gmail.com on 30 Nov 2009 at 11:01

[GoogleCodeExporter]

Hardware parameters are set and fixed in the order in which the various
snd_pcm_hw_param_set_xxx functions are called.

So, if set_period_time_near set the period time to one quarter of the _desired_
buffer size, but if the _actual_ buffer size set by set_buffer_time_near is 
smaller
due to hardware limitations, the goal of having four periods per buffer is not 
met.

Calling set_periods_near sets only the ratio between period time and buffer 
time.
This means that the period time is set at the same time with the buffer time 
(when
set_buffer_time_near is called), and that the period time is one fourth of the
_actual_ buffer time.

(The same effect could by accomplished by moving the call of 
set_period_time_near
after the buffer_time call and using the actual buffer time returned by that, 
but
using set_periods_near better expresses the intention.)

The only difference between old and new code is on hardware that does not 
support the
desired buffer size. In this case, the old code would try to use a fixed period 
size,
which would result in less or more than four periods per buffer, while the new 
code
always tries to use four periods, which results in shorter or longer periods.

Original comment by cladisch@googlemail.com on 1 Dec 2009 at 8:27

[GoogleCodeExporter]

Patch applied in r461.

Original comment by rafael2k...@gmail.com on 1 Dec 2009 at 12:58

• Changed state: Fixed