Closed GoogleCodeExporter closed 9 years ago
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
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
Patch applied in r461.
Original comment by rafael2k...@gmail.com
on 1 Dec 2009 at 12:58
Original issue reported on code.google.com by
cladisch@googlemail.com
on 25 Nov 2009 at 12:01Attachments: