Re: [linux-audio-dev] jack newbie question

From: Florian Schmidt <mista.tapas@email-addr-hidden>
Date: Sat Apr 09 2005 - 00:35:08 EEST

On Fri, 8 Apr 2005 23:15:31 +0200
Tim Blechmann <TimBlechmann@email-addr-hidden> wrote:

> hi all ...
>
> another jack newbie question ...
>
> sometimes jacks kicks out my application, since the subgraph times out

Assuming that other jack clients work without problems, then this
problem description really means (with a pretty high probability) that
your app is violating the RT constraints jack imposes on its clients..
Namely to return as fast as possible from and never ever block in the
process callback.

"Never ever block" pretty much means that you are not allowed to do
anything besides some calculations and usage of lock free datastructures
for communication with your other threads :)

Does your app meet this requirements? Among the definitive nono's are:

- mutex locking (trying it is ok i _think_) or any other synchronisation
mechanisms which might be contended..

- sleeping

- filesystem access

- network access

- UI (be it writing to the console or driving a GUI)

The list surely goes on and on..

> ...
> basically i have two questions about that:
>
> - is there an api function, that tells jack not to kick the application
> or a callback that tells the application that it has been kicked out?

As a workaround (dirty) you can tell jack to use a longer timeout (see
the manpage or the qjackctl setup dialog)..

>
> - is it possible to query the time out so that i can adapt the callback
> that it finished before this time out?

If your periodsize is 1024 frames at a samplerate of 48000hz, then your
process callback (if it's the only client) needs to finish in less time
than ((1024/48000) - overhead) seconds. Otherwise you'll get an xrun,
which is almost just as bad as a timeout..

Flo

-- 
Palimm Palimm!
http://affenbande.org/~tapas/
Received on Sat Apr 9 04:15:10 2005

This archive was generated by hypermail 2.1.8 : Sat Apr 09 2005 - 04:15:10 EEST