On Wed, 2001-11-28 at 05:47, Paul Davis wrote:
<cut>
>
> do you think this is possible/likely? if it is, do you think that its
> the job of the low level driver(s) to handle this? otherwise, its hard
> for me to see how an application (or library) can handle this
> efficiently in any full-duplex situations.
>
> i say this because even if we poll on both stream descriptors, if one
> of them is out-of-step by 1 (or lets just say some very small number
> of frames), we have to go back into poll immediately, which will
> return immediately, and we end up busy waiting, which is not good at all.
> i don't see any other way to handle that situation. do you?
>
> i'm going to add some debugging to check on the "pointers-not-in-sync
> theory", and i'll let you know what i find. since very few programs do
> full duplex operation, this may be a rather hidden problem.
>
This sounds very similar to what I was trying to explain a few times on
alsa-devel with full duplex operation. I created a (rather broken) ALSA
full duplex test program, which Jaroslav changed to work better. But the
problem that I was running into still exists (although it takes much
longer to occur). Over time clicks and pops will start and increase in
amplitude. If I wait long enough the amplitude of the clicks will
decrease and synchronization will return. If an overrun occurs while
clicks and pops are being heard, the stream will re-synchronize (no more
clicks).
The clicks seem to be affected by the fragment size. It takes less time
for the clicks to start occuring the smaller the fragment, and the
frequency with which they occur is related indirectly to the fragment
size. Leading me to believe there is a problem surrounding the
boundaries of the fragment. Anyways. I haven't tested this in a while,
but I'll try again with current CVS. This is with an SB Live! card by
the way. IIRC the problem was on the playback portion of the stream, as
the record data was correct. I'll verify this though.
--
Josh Green
Smurf Sound Font Editor (http://smurf.sourceforge.net)
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
