Re: [Jack-Devel] Jack 0.120 incorrect error recovery for -n 3

PrevNext  Index
DateWed, 20 Apr 2011 09:01:27 -0400
From Paul Davis <[hidden] at linuxaudiosystems dot com>
ToFons Adriaensen <[hidden] at linuxaudio dot org>
CcJack Developers <[hidden] at lists dot jackaudio dot org>
In-Reply-ToFons Adriaensen Re: [Jack-Devel] Jack 0.120 incorrect error recovery for -n 3
On Wed, Apr 20, 2011 at 6:38 AM, Fons Adriaensen <[hidden]> wrote:

> A driver->write_zeros() would be useful anyway. When I started looking

driver->null_cycle() is close.

> I can't help but feel that the whole ALSA backend is overly complicated.
> For example I still have no idea what the 'extra_fd' stuff in wait() is
> about :-) The wait() code in libclalsadrv (which is very similar to the
> backend) doesn't have it and works OK. Same about the 'linux poll bug'.

the extra_fd stuff comes from original design where we did something a
bit closer to ASIO. when waiting on the graph, we would actually wait
on the graph AND the device. if the graph finishes first, we hear
about it on extra_fd. if the device is ready again first, we are able
to discover that we've timed out much sooner and more "efficiently"
than if we wait for the graph then check the device. i believe that
we've removed the possibility to use this from the command line. it
was a much "stricter" test of RT, and generally wasn't very useful.

the linux poll bug was a genuine bona fide error in the kernel. if you
look again, you'll see that its not part of the ALSA backend, but part
of the engine. as the comment says:

/* Linux kernels somewhere between 2.6.18 and 2.6.24 had a bug
   in poll(2) that led poll to return early. To fix it, we need
   to know that that jack_get_microseconds() is monotonic.
*/
PrevNext  Index

1303304501.10932_0.ltw:2,a <BANLkTimUdgmOX69F_+-npgeZH5DV4myuGA at mail dot gmail dot com>