new patch to help jackd along

[Stéphane Letz]

Le 10 mai 08 à 19:39, Jacob Meuser a écrit :

> On Sat, May 10, 2008 at 09:52:35AM -0400, Paul Davis wrote:
>>
>> On Sat, 2008-05-10 at 07:39 +0000, Mikael Bouillot wrote:
>>> On Thu, May 08, 2008 at 10:24:16PM -0400, Paul Davis wrote:
>>>> I would commit this directly, but I'm trying to be cautious for  
>>>> once. It
>>>> works much better for me now.
>>>
>>>   Same thing here, it seems to take care of my problem. But as this
>>> particular problem happens only once or twice a day with my normal
>>> setup, I'll test for a few more days before concluding.
>>
>>
>> We have substantial evidence that the problems people are  
>> experiencing
>> with JACK are actually issues with the Linux kernel. The problems are
>> not replicable on OS X (with the same codebase and test clients), and
>> appear to be related to JACK clients being preempted incorrectly  
>> and for
>> absurdly long periods of time. We are discussing the issue with the
>> people involved in Linux-RT work. This seems to be the result of  
>> changes
>> made to the kernel at some point in the last several months (as  
>> in, 3-8
>> months).
>
> that's definitely not the cause of my problems.
>
> I'm seeing problems on OpenBSD, which has no preemption mechanism.
> it doesn't have realtime scheduling either.  I see the problem
> even when jack is running in non-realtime mode.
>
> OS X is not involved because it doesn't poll() the wait_fd:
>
> #ifndef JACK_USE_MACH_THREADS
> client->pollfd[WAIT_POLL_INDEX].events =
> POLLIN|POLLERR|POLLHUP|POLLNVAL;
> #endif
>
> and of course in jack_client_core_wait(), everything with the wait_fd
> is in '#ifndef JACK_USE_MACH_THREADS ... #endif'
>
>

Yes OSX uses low-level Mach messaging system to suspend/resume clients.

Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Jussi Laako-2]

Stéphane Letz wrote:
> Yes OSX uses low-level Mach messaging system to suspend/resume clients.

I'm wondering if it would make sense to try out similar on Linux using
POSIX message queues... I haven't compared the performance to FIFOs, but
compared to local (unix domain) sockets, round trip latency is about
half... And IMO, the thread callback delivery mechanism is nice...


        - Jussi

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Sat, 2008-05-10 at 15:26 +0000, Mikael Bouillot wrote:
> > We have substantial evidence that the problems people are experiencing
> > with JACK are actually issues with the Linux kernel.
>
>   On the other hand, with the same 2.6.22.6 kernel, jackd 0.103 did work
> for me whereas 0.109 doesn't.

There were errors in 0.109 that i have fixed in the patch i posted and
have now applied to svn. These would tend to cause the wrong (or extra)
clients to be ejected from the graph when a client quits or does
something bad. These are now fixed.

However, running a debug version of JACK makes it *absolutely* clear
that the current Linux kernels (say, 2.6.23 - 2.6.24 at least) are
preempting JACK clients for periods of up to 10msec, which will cause
the problems that have been reported where JACK says "subgraph starting
at foobar timed out ..."

I have dozens of traces showing this, and I have received copies of such
traces from Pieter, from Mike Taht and even from members of the Linux-RT
community.

--p


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Mikael Bouillot-3]

On Sat, May 10, 2008 at 07:39:48AM +0000, Mikael Bouillot wrote:
> On Thu, May 08, 2008 at 10:24:16PM -0400, Paul Davis wrote:
> > I would commit this directly, but I'm trying to be cautious for once. It
> > works much better for me now.
>
>   Same thing here, it seems to take care of my problem. But as this
> particular problem happens only once or twice a day with my normal
> setup, I'll test for a few more days before concluding.

  Well it works. Once all ports are setup, my clients are happily
making noise again without dying. I still see dying clients upon
vigorous port (de)connection, but that isn't a problem on my setup.

  Thanks for the patch, and keep us posted about the linux preemption
problem.


  Mikael
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org