On Tue, 19 Feb 2002, Jaroslav Kysela wrote:
>> I'm still a bit puzzled why I didn't get xruns in the test case quoted
>> below, but until I can reproduce the problem, there's not much to discuss
> You posted this sw params on alsa-devel a few days ago:
[....]
> sw_params:
> stop_threshold: 4294967295
[...]
> As you can see, the stop_threshold is set to UMAX_INT. In case when
> stop_threshold is above ring buffer size, then it means for drivers: I
> don't care about xruns, don't report them. The stop threshold must be
> equal to ring buffer size to get xruns when no more frames are in ring
> buffer.
Hmm, makes sense. This raises a few new questions:
1) Is 'avail > stop_threshold' the only condition when a stream
can move from RUNNING to XRUN state? The only places I located
in the current source tree, where this state change happens, were
in alsa-kernel/core/pcm_lib.c, functions
snd_pcm_update_hw_ptr_interrupt() and snd_pcm_update_hw_ptr().
2) If (1) is true, why does runnig jack produces xruns every
now and then...? The stop_threshold is UMAX_INT for
both directions and it should never occur that over
buffer_size samples is writable to, or readable from
the pcm device.
And to save your time ;), here's one possible explanation to (2):
Looking at jackd code, one possibility is that the we are only getting an
EPIPE from snd_pcm_avail_update(), but the stream is still in RUNNING
state. At least in alsa-lib/src/pcm/pcm_hw.c:snd_pcm_hw_avail_update()
we have a test for:
--cut--
if (avail > pcm->buffer_size)
return -EPIPE;
--cut--
This would trigger jackd's xrun handling code, but leave state to RUNNING.
Am I on the right track here?
--
http://www.eca.cx
Audio software for Linux!
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
