Answering to my own mail...
> 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:
[...]
> if (avail > pcm->buffer_size)
> return -EPIPE;
This seems to be the case. It does look very unlikely that an xrun
could go unnoticed. It would take quite a latency spike to
allow hw_ptr to wrap around pcm->boundary. :)
I guess more probable explanation is something like:
loop:
start = timer()
poll()
<interrupt -> hw_ptr += period_size>
snd_pcm_avail_update()
snd_pcm_mmap_begin()
...
snd_pcm_mmap_commit()
<interrupt -> hw_ptr += period_size>
stop = timer()
If the interrupts occur at the right time, 'stop-start'
might exceed 'period_time * period_count' even though
snd_pcm_avail_update() never returns EPIPE. This is
probably what I saw when debugging jackd (and is, of
course, perfectly legal).
--
http://www.eca.cx
Audio software for Linux!
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
