Oleh Derevenko(deleted)
|
Playing several tracks with mixing on 6.3.x
|
Oleh Derevenko(deleted)
06/12/2009 3:14 PM
post31662
|
Playing several tracks with mixing on 6.3.x
Hi everyone,
I have a problem mixing several PCM streams on different channels in 6.3.0SP3. That is, the mixing works but here it is
from the beginning...
There are threads that read data from wav files (one thread per file) and there is a single thread that feeds PCM data
to the audio driver. While only one channel is playing everything seemd to be fine. However, if to add playback for the
second channel it becomes underrun from time to time and playback goes with breaks as it is necessary to prepare the
channel during playback before write.
The analysys by logs shows that the audio driver has a queue of three 4k buffers (12k total). Naturally when one buffer
is played it signals the channel write-readiness and continues to play next buffer. It takes some time while client code
takes action and feeds next block, but normally write only consumes 4 k of data (obviously driver accepts data in whole
buffer sizes only). It takes approximately 0.02 seconds to play 4k of PCM data and usually channel handle signals write
-readiness once this period. But from time to time the driver signals readiness only after 0.04 seconds and accepts 8 kb
at once. That could be fine, but even though it has been fed enough data it is still not able to use that data and
becomes underrun in 0.02 seconds after that, after the last 3rd block of queue is exhausted. So it looks like when the
last block in queue starts to be played the driver is unable to rejoin the data that has additionally been written to
the end of it and falls in underrun state anyway.
Then, after preparing the channel it continues playing normally (with noticeable playback break of course).
The problem only happens on channel that was started second. I've tried i8x0 and via686 drivers with ac97 mixer.
Is it a known problem?
Note: While preparing this post I've found that flags_max field of snd_pcm_channel_params_t structure defines the length
of PCM queue (the description is very unclear and confusing for this field, I must say, - that's why I have not
understood what's the meaning of that field from the very beginning). I was setting it to 1 and my queue was only 3
buffers long (an obvious minimum). But when I increased this field to 5 the playback has become smooth. This solves my
problem but the issue with incorrect behavior while three buffers only are used for the queue still needs to be checked.
|
|
|