Client getting rudely closed?

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Client getting rudely closed?

Ed Wildgoose-2
Hi, I am rewriting the jack audio output layer for a multimedia
application.  For various reasons (that I can't immediately eliminate)
it appears that the process callback is not running realtime and we are
occasionally causing an xrun.  The "problem" though is that the effect
of this is that jack drops the client connections and then forces closed
the client?

What I would like is if the callback fails to return in time that jack
reports an xrun, sends silence to the output and tries very hard to
continue normally without dropping the client from the graph?  I
experimented with the "-Z" flag since this appeared to be relevant, but
it didn't appear to make any difference?

Is this the intended behaviour?  Is there any way to get the behaviour I
desire, ie graph stays connected solidly and is tolerant of overruns no
matter how bad?

I am experimenting with two client side solutions.  One is to use a
separate thread to monitor the jack client and restart it if desired.  
However, this seems extremely nasty and would not be an option in say
the mplayer code (threadless).  Alternatively I have experimented with
using the on_shutdown callback and using that to recreate the jack
client - however, this leaves me with a stale jack client that I need to
clean up later (not neat), probably this is best done in the next
process callback (feels horribly hacky).


Additionally while debugging this I noticed that if I use
jack_set_xrun_callback then I sometimes get xrun notifications in my app
(instead of being dropped), BUT after the xrun callback my client is
apparently active, but it's had it's output connection (to Brutefir in
this case) closed.  It appears that by NOT setting an xrun callback then
I no longer get my connections dropped?  Is this behaviour intended?

Can anyone shine some light on this please?

Thanks

Ed W
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

Ed Wildgoose-2
On 15/04/2010 09:23, Ed W wrote:
> I am experimenting with two client side solutions.  One is to use a
> separate thread to monitor the jack client and restart it if desired.  
> However, this seems extremely nasty and would not be an option in say
> the mplayer code (threadless).  Alternatively I have experimented with
> using the on_shutdown callback and using that to recreate the jack
> client - however, this leaves me with a stale jack client that I need
> to clean up later (not neat), probably this is best done in the next
> process callback (feels horribly hacky).

After some experimentation it seems that it's unreliable to use the
on_shutdown callback to restart the jack_client.  Usually after a couple
such events I get an error where jack_get_ports doesn't return me
anything...

I'm really stumped how I can get my app to reliably output audio over a
long period of time, whilst assuming that I need to tolerate the
occasional xrun?  It seems like I need a whole chunk of code to babysit
the audio output layer and keep restarting it if it falls over?  This
doesn't feel right - how can I get to the desired end result?

Forgot to add previously:
Running on gentoo, using jack 0.118.0.  Command line to start jackd is:
     nice -n -10 jackd -R -v -d alsa -d rme9632 -r 44100 -p 512

Grateful for any help?

Ed W

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

Paul Davis
On Thu, Apr 15, 2010 at 5:56 AM, Ed W <[hidden email]> wrote:

> I'm really stumped how I can get my app to reliably output audio over a long
> period of time, whilst assuming that I need to tolerate the occasional xrun?
>  It seems like I need a whole chunk of code to babysit the audio output
> layer and keep restarting it if it falls over?  This doesn't feel right -
> how can I get to the desired end result?

(1) by writing your app correctly
(2) by making sure that you either have a properly tuned system OR
(3) use generous amounts of buffering (large period sizes and/or lots
of periods)

> Forgot to add previously:
> Running on gentoo, using jack 0.118.0.  Command line to start jackd is:
>    nice -n -10 jackd -R -v -d alsa -d rme9632 -r 44100 -p 512

arrgh! do not use nice for this! nice is totally irrelevant to what
you are doing. you may have discovered this idea by googling. forget
it. you're already running jackd in realtime mode - this makes nice
even more irrelevant than it would be otherwise.

JACK evicts your client because your client was too slow. JACK is for
realtime audio - if your client cannot keep up, then the audio stream
will be glitchy. Ergo, something has to give: either JACK evicts your
client or the audio is glitchy. There are plenty of JACK clients that
never get evicted even under heavy load on a well tuned system.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

Ed Wildgoose-2

>> I'm really stumped how I can get my app to reliably output audio over a long
>> period of time, whilst assuming that I need to tolerate the occasional xrun?
>>   It seems like I need a whole chunk of code to babysit the audio output
>> layer and keep restarting it if it falls over?  This doesn't feel right -
>> how can I get to the desired end result?
>>      
> (1) by writing your app correctly
> (2) by making sure that you either have a properly tuned system OR
> (3) use generous amounts of buffering (large period sizes and/or lots
> of periods)
>    

All of these are bandaids to preventing the issue happening *as
frequently*, but my point is really that I have a need for a *reliable*
sound server, even in the face of events outside of my control.  Jack is
apparently not able to offer me that reliability from what you say, but
equally it doesn't seem horrendously unreasonable to try and support my
use case since it appears to be only marginally outside of the normal
situation?

If we could please avoid discussing ways to lower the input latency - I
understand the issues here, but not all of them are under my control, or
can be solved immediately. They are being worked on separately though!

I'm not quite sure what you are arguing against though.  It's pure
statistics now.  Given a typical queuing distribution you can tweak your
parameters as much as you like, but all you are doing is improving the
average situation, there must by definition be outliers!  All I'm asking
is that Jack can be made robust in the situation that something goes
wrong briefly and intermittently?

I'm actually struggling to understand that the average user of Jack in
the case of a system experiencing a brief latency glitch prefering:
a) Kick the entire client out of the graph, meaning no further audio output
vs
b) Continuing on as best we can on the next cycle

(Yes I realise that there are some people running large re-inforced
sound installations, but even then does the client dropping out
completely actually make things better?)

>> Forgot to add previously:
>> Running on gentoo, using jack 0.118.0.  Command line to start jackd is:
>>     nice -n -10 jackd -R -v -d alsa -d rme9632 -r 44100 -p 512
>>      
> arrgh! do not use nice for this! nice is totally irrelevant to what
> you are doing. you may have discovered this idea by googling. forget
> it. you're already running jackd in realtime mode - this makes nice
> even more irrelevant than it would be otherwise.
>    

I don't think nice is related to the issues I'm experiencing here?  I
will defer to your greater experience, but I believe there are
priorities even amongst realtime processes? I forget the exact
reasoning, but I have a bunch of realtime processes running and I think
I initially added this on a much older kernel to try and hint that I
wanted jack serviced at a high priority even amongst other realtime
processes?  (It's been untouched for some 5+ years now)

If there is some documentation on how modern 2.6 handles process
priority then I would be grateful to be educated?

> JACK evicts your client because your client was too slow. JACK is for
> realtime audio - if your client cannot keep up, then the audio stream
> will be glitchy. Ergo, something has to give: either JACK evicts your
> client or the audio is glitchy.


OK, I'm just stating an opinion that I would prefer one minor glitch
while watching a DVD than to have my audio interrrupted halfway through,
have to stop the DVD player, restart it, skip back to find out where I
was, etc....

As for how audible the glitches are, I already stated that I have tried
some bandaids around jack to restart it when it falls over and given
roughly 1 period xruns of 512 samples (at 44K) I'm noticing only a very
slight nick as I restart the client - often it's inaudible (I'm
provoking it every few seconds for testing).  My setup uses around 1KW
of amps connected directly to speakers without pre-amps, so yes I do
care about audible gremlins

Right now I loose sound perhaps once a day due to bad latency.  
Personally I would rather trade one minor tick in the sound (once a day)
to having to restart my media player to fix the issue.  I hope you agree
this is not unreasonable.  I will of course also work to reduce the
frequency of the gremlin at all, but we are already at the point of
seriously diminishing returns...

Therefore yes I would prefer the "glitchy" audio as you put it so
provocatively.  One small "tick" during 1/44th of a second every 24
hours would suit me much better than loosing the audio completely.

>   There are plenty of JACK clients that
> never get evicted even under heavy load on a well tuned system.
>    

OK, lets get specific.  For me mplayer will occasionally loose it's Jack
client connection due to xruns on a fairly low loaded core2 3Ghz machine
on a kernel of 2.6.27-2.6.32 vintage (1,000Hz, tickless, no other RT
patches).

Mplayer is perhaps not a showcase of modern programming, but it is
pretty fast and lean and its jack output loop seems fairly sane.


Anyway, this is all prevaricating around the proverbial bush.  If you
say that Jack prefers to drop dead rather than carry on in the face of
xruns then that's understood here loud and clear.  My question is
whether it can be adjusted to support at least the ability to try and
continue in the case of minimal xruns without falling on it's face and
requiring some external babysitting thread to monitor and restart the
client? This doesn't seem like an unreasonable feature request despite
some people perhaps needing the opposite?

Incidently, I was working towards trying to use netjack to do some
output across multiple machines, however, your insistence that it's
better jack die than carry on in the face of unexpected latency is
rather shooting that idea dead before it's even got off the ground...
Shame though I had some fun ideas here...

Regards

Ed W
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

Gabriel M. Beddingfield-2


On Thu, 15 Apr 2010, Ed W wrote:

>> (1) by writing your app correctly
[snip]
>
> All of these are bandaids to preventing the issue happening *as frequently*,
> but my point is really that I have a need for a *reliable* sound server, even
> in the face of events outside of my control.  Jack is apparently not able to

#1 is not a band-aid.  It's fundamental to the API.

<documentation>
int jack_set_process_callback (jack_client_t  *client,
                                JackProcessCallback process_callback,
                                void * arg )

Tell the Jack server to call process_callback whenever there
is work be done, passing arg as the second argument.

The code in the supplied function must be suitable for
real-time execution. That means that it cannot call
functions that might block for a long time. This includes
malloc, free, printf, pthread_mutex_lock, sleep, wait, poll,
select, pthread_join, pthread_cond_wait, etc, etc.
</documentation>

That is to say:  If there are events outside your control...
then you need to get them under your control.

A typical way to get them under your control is to put your
audio processing on a worker thread and copy the data over
with a ring buffer (a.k.a. circular buffer).  This allows
your application to handle the issue gracefully in the event
that it can't keep up.

-gabriel


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

Paul Davis
In reply to this post by Ed Wildgoose-2
On Thu, Apr 15, 2010 at 9:39 AM, Ed W <[hidden email]> wrote:

>
>>> I'm really stumped how I can get my app to reliably output audio over a
>>> long
>>> period of time, whilst assuming that I need to tolerate the occasional
>>> xrun?
>>>  It seems like I need a whole chunk of code to babysit the audio output
>>> layer and keep restarting it if it falls over?  This doesn't feel right -
>>> how can I get to the desired end result?
>>>
>>
>> (1) by writing your app correctly
>> (2) by making sure that you either have a properly tuned system OR
>> (3) use generous amounts of buffering (large period sizes and/or lots
>> of periods)
>>
>
> All of these are bandaids to preventing the issue happening *as frequently*,

None them are bandaids. If you want to do realtime audio, you need to
understand this very clearly. There are 2 approaches to realtime
audio: buffering and/or correct design. The problem with the second is
that it has to extend from the bottom fo the stack (hardware design)
all the way to the top (application architecture), which is why most
people who do this sort of thing tend to rely on buffering.

I suggest you try using the client timeout parameter (-t) to increase
the time that JACK will grant to clients to complete. By default, its
set to an approximation of the period size (there is a limit to the
resolution of the wait timers on linux and other systems). There are
xruns, which you can hear, and there are client timeouts which you can
hear and will cause your client to be evicted from the graph. If the
client timeout is large enough, no client will ever be evicted (as
evidenced by using it with a debugger in which case a client can
simply stop for minutes at a time).

> I don't think nice is related to the issues I'm experiencing here?  I will
> defer to your greater experience, but I believe there are priorities even
> amongst realtime processes?

nice does not control SCHED_FIFO or SCHED_RR scheduling. moreover, the
scheduling class that it does affect (SCHED_OTHER) is inherently
unsuited for realtime audio unless you use lots of buffering. if you
want to modify the SCHED_FIFO priority that JACK uses, then use the -P
parameter to JACK, but this rarely a necessary or wise thing to do.

> OK, I'm just stating an opinion that I would prefer one minor glitch while
> watching a DVD than to have my audio interrrupted halfway through, have to
> stop the DVD player, restart it, skip back to find out where I was, etc....

JACK isn't designed for "watching DVD's" . If you want to do this kind
of audio, then you can use lots of buffering to reduce the chance of
audio glitches to an absolute minimum. The libraries/layers that
typically glue non-RT apps into JACK (like the one used by mplayer or
xine) typically add quite a bit of buffering precisely for this
reason.

> Anyway, this is all prevaricating around the proverbial bush.  If you say
> that Jack prefers to drop dead rather than carry on in the face of xruns
> then that's understood here loud and clear.

I didn't say that. JACK doesn't do anything to clients when there is
an xrun. It kicks out clients that demonstrate that they cannot meet
the timing deadlines required for realtime audio. As mentioned, try
using the -t argument to adjust its idea of "timing deadlines".
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

Fons Adriaensen-2
In reply to this post by Ed Wildgoose-2
On Thu, Apr 15, 2010 at 02:39:16PM +0100, Ed W wrote:

>
> >>I'm really stumped how I can get my app to reliably output audio over a long
> >>period of time, whilst assuming that I need to tolerate the occasional xrun?
> >>  It seems like I need a whole chunk of code to babysit the audio output
> >>layer and keep restarting it if it falls over?  This doesn't feel right -
> >>how can I get to the desired end result?
> >(1) by writing your app correctly
> >(2) by making sure that you either have a properly tuned system OR
> >(3) use generous amounts of buffering (large period sizes and/or lots
> >of periods)
>
> All of these are bandaids to preventing the issue happening *as
> frequently*, but my point is really that I have a need for a
> *reliable* sound server, even in the face of events outside of my
> control.  Jack is apparently not able to offer me that reliability
> from what you say, but equally it doesn't seem horrendously
> unreasonable to try and support my use case since it appears to be
> only marginally outside of the normal situation?

If you arrive too late at the airport and your plane
is gone, or you are not allowed to board, is that a
'bandaid' to make air traffic run smoothly ?
I'd say it's an essential rule. You being late out
of bed should not affect the rest of the world.

If your app every now and then can't keep up, it
should handle that problem internally, for example
by outputting silence, or doing whatever makes sense
in such conditions, and not by making the whole audio
system wait and ultimately fail.

Actually Jack could/should even be more strict than
it currectly is - when your app is kicked out it is
in fact already too late, damage has been done, and
the main purpose of removing the client is to avoid
constant repetition of the same.

Jack is being used to do things that are with very
high probably some orders of magnitude more complex
than what you want to achieve. Such as computing a
few hundred audio channels in real time. I'm running
such systems, and I've *never* seem any of the Jack
clients being kicked out. Things run here for months
without a single xrun. The key to that is to design
them correctly.

Ciao,

--
FA

O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

Ed Wildgoose-2
In reply to this post by Paul Davis

> I suggest you try using the client timeout parameter (-t) to increase
> the time that JACK will grant to clients to complete. By default, its
> set to an approximation of the period size (there is a limit to the
> resolution of the wait timers on linux and other systems).

Aha, ha!  Changed it to the value that it says it defaults to in the man
page (500ms) and now I cannot repro these disconnections! Hopefully this
is success!

OK, this is super - thanks for your answer.  Can I request the man pages
are updated to show this please?  I had looked at this parameter, but
then completely overlooked it because the man pages (at least on my
installation) are claiming it defaults to 500ms which is way above what
I need.  I was poking through the jack code, but hadn't even tried to
consider it was this straightforward

>   There are
> xruns, which you can hear, and there are client timeouts which you can
> hear and will cause your client to be evicted from the graph. If the
> client timeout is large enough, no client will ever be evicted (as
> evidenced by using it with a debugger in which case a client can
> simply stop for minutes at a time).
>    

Can you please clarify what is *supposed* to happen when an xrun event
is triggered please?

What I observe empirically (hard to repro this without some coding
changes) is that it doesn't disconnect my client (ie no client
disconnect callback), but it DOES seem to disconnect my output ports
(which were previously connected to Brutefir in case it's relevant).

Now this could of course be Brutefir which is disconnecting me, hence
the request for clarification?

Additionally since changing the timeout values as per above I haven't
seen this happen - however, this could easily be coincidence (I very
rarely see xruns and I would need to provoke them with some code changes
to be sure)

>> I don't think nice is related to the issues I'm experiencing here?  I will
>> defer to your greater experience, but I believe there are priorities even
>> amongst realtime processes?
>>      
> nice does not control SCHED_FIFO or SCHED_RR scheduling. moreover, the
> scheduling class that it does affect (SCHED_OTHER) is inherently
> unsuited for realtime audio unless you use lots of buffering. if you
> want to modify the SCHED_FIFO priority that JACK uses, then use the -P
> parameter to JACK, but this rarely a necessary or wise thing to do.
>    

OK. Just to confirm though - does using nice cause me any harm if I also
specify -R to jack?

I believe that I don't have realtime priority correctly enabled on this
system.  I will need to read-up to figure out what I'm doing wrong
though.  At the moment "ulimit -r" shows correct priorities available at
a bash prompt, but I start Jack using sudo to a non root user and chrt
is showing that Jack isn't running RT?  Anyway, will solve that
separately... (Previously I used realtime-lsm successfully, but it's not
available on modern kernels)


> JACK isn't designed for "watching DVD's" . If you want to do this kind
> of audio, then you can use lots of buffering to reduce the chance of
> audio glitches to an absolute minimum. The libraries/layers that
> typically glue non-RT apps into JACK (like the one used by mplayer or
> xine) typically add quite a bit of buffering precisely for this
> reason.
>    

You say "library", but perhaps you haven't looked at the code recently?  
Both mplayer and xine simply spool a chunk of decoded audio to a
lockless ringbuffer.  Then the jack process callback is basically just a
memcpy to the correct buffer.

This seems like a pretty textbook implementation of a simple and
straightforward Jack client to be honest?  I'm not quite sure why you
think this is outside of scope?

Perhaps you forget now, but I'm the idiot who, with your previous help,
initially implemented the Jack output layer on Xine, mplayer and mythtv
(thankfully some of that dire code rewritten by other smarter folks than
me since).  My current work is to improve the audio output layer on
mythtv - however, improving the latency involves fixing code on linux,
windows and osx, so I just need to make this a patchwork of simple
improvements to get it upstream. The big latency issues will get fixed
eventually

> I didn't say that. JACK doesn't do anything to clients when there is
> an xrun. It kicks out clients that demonstrate that they cannot meet
> the timing deadlines required for realtime audio. As mentioned, try
> using the -t argument to adjust its idea of "timing deadlines".
>    

Apologies for the mis-interpretation then.  In fact "-t" appears to
offer exactly what I need.  Please consider updating the man pages for
that param though?  I'm happy to submit a patch, but it seems almost too
trivial a patch?

Thanks for your help

Ed W
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

Ed Wildgoose-2
In reply to this post by Gabriel M. Beddingfield-2
On 15/04/2010 14:53, Gabriel M. Beddingfield wrote:

>
>
> On Thu, 15 Apr 2010, Ed W wrote:
>
>>> (1) by writing your app correctly
> [snip]
>>
>> All of these are bandaids to preventing the issue happening *as
>> frequently*, but my point is really that I have a need for a
>> *reliable* sound server, even in the face of events outside of my
>> control.  Jack is apparently not able to
>
> #1 is not a band-aid.  It's fundamental to the API.

Now you are being flippant in response to my flippant comment...


> A typical way to get them under your control is to put your audio
> processing on a worker thread and copy the data over with a ring
> buffer (a.k.a. circular buffer).  This allows your application to
> handle the issue gracefully in the event that it can't keep up.

Read the mplayer code - you just described it...

However, I am running my system at a moderately low latency (around
11ms) and it would appear that it sneezes from time to time, leading to
the undesirable effects I described previously.

Bear in mind that my requirement is to survive months or years without
such an overrun condition using generic x86 hardware, so I'm really
trying to tackle it from the point of view of recovering from failure as
well as preventing failure in the first place

Thanks

Ed W
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

Gabriel M. Beddingfield-2


On Thu, 15 Apr 2010, Ed W wrote:

>> #1 is not a band-aid.  It's fundamental to the API.
>
> Now you are being flippant in response to my flippant comment...

:-)  Actually, I wasn't being flippant.  It was a response
to your rant.

>> A typical way to get them under your control is to put your audio
>> processing on a worker thread and copy the data over with a ring buffer
>> (a.k.a. circular buffer).  This allows your application to handle the issue
>> gracefully in the event that it can't keep up.
>
> Read the mplayer code - you just described it...
>
> However, I am running my system at a moderately low latency (around 11ms) and
> it would appear that it sneezes from time to time, leading to the undesirable
> effects I described previously.

OK.  But if you really have a lock-free ringbuffer you're
reading from... how can it ever stall?  Are you actually
battling kernel scheduling jitter?  (I.e. the kernel
thread-switching sometimes delays your code until after the
timeout has expired.)

-gabriel

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

Ed Wildgoose-2

> :-)  Actually, I wasn't being flippant.  It was a response to your rant.

Agreed - but without going too far off topic, buffering IS just a way to
try and match the impedence of a system which prefers to do jobs in
"chunks" versus our desire to have a long pipeline of stuff 1 bit wide.  
At best you just isolate the problem to a smaller chunk of code, but at
some point you need to face up to scheduling issues on that final chunk
of code

> OK.  But if you really have a lock-free ringbuffer you're reading
> from... how can it ever stall?  Are you actually battling kernel
> scheduling jitter?  (I.e. the kernel thread-switching sometimes delays
> your code until after the timeout has expired.)

Actually I'm not too sure - I started working on the mythtv code because
I was fed up with the current dropouts (actually it's probably slightly
more than once a day on that code), but I am also getting some kind of
client dropout using xine/mplayer around every 10-30 hours of playback
(not monitored it that precisely).  Given that the mplayer/xine output
code is quite simple in those apps and really my scheduling requirements
are reasonably modest at 11ms ish I'm genuinely not quite sure what is
causing mplayer to suffer getting dropped by jack...

My schedule of debugging is basically to fixup the mythtv code which is
what I use most frequently and debug from there.  I have to assume some
kind of kernel scheduling problem, but the machine is moderately ok for
the job (fast processor, reasonable MB, 1,000Hz low latency, CFQ
scheduler, recent kernel).  The video is streamed via the gigabit to
some nasty onboard atl1 based thing, so quite possibly something bogging
down there...?

Having looked again my RT threads do seem to be RT.  I just hadn't used
the thread option to ps so I couldn't see them.


Anyway thanks - I think I can take it from here now

Cheers

Ed W
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

John Rigg-16
In reply to this post by Ed Wildgoose-2
On Thu, Apr 15, 2010 at 04:54:09PM +0100, Ed W wrote:
> I believe that I don't have realtime priority correctly enabled on this  
> system.  I will need to read-up to figure out what I'm doing wrong  
> though.  At the moment "ulimit -r" shows correct priorities available at  
> a bash prompt, but I start Jack using sudo to a non root user and chrt  
> is showing that Jack isn't running RT?  Anyway, will solve that  
> separately... (Previously I used realtime-lsm successfully, but it's not  
> available on modern kernels)

Since 2.6.13 (released in 2005) the linux kernel has used rlimits for setting
RT priorities. You need to edit /etc/security/limits.conf to set it up.
I'm not on my audio system now so I can't copy the lines you need to add,
but a couple of minutes on google should find them. This isn't a band-aid
BTW - it's not unreasonable to expect the system to be configured for RT
if you want to run RT processes correctly.

I might be missing something here, but is low latency necessary for
playing DVDs? As long as picture and sound are reasonably synchronised,
does it matter if both are using large buffers?

John
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

John Rigg-16
On Fri, Apr 16, 2010 at 09:37:02AM +0000, John Rigg wrote:
> Since 2.6.13 (released in 2005) the linux kernel has used rlimits for setting
> RT priorities. You need to edit /etc/security/limits.conf to set it up.
> I'm not on my audio system now so I can't copy the lines you need to add,
> but a couple of minutes on google should find them. This isn't a band-aid
> BTW - it's not unreasonable to expect the system to be configured for RT
> if you want to run RT processes correctly.

/etc/security/limits.conf on one of my DAWs:

* hard rtprio 0
* soft rtprio 0
@audio hard rtprio 95
@audio soft rtprio 90
@audio - memlock 2000000

This allows members of the audio group to use SCHED_FIFO and SCHED_RR.
This is on a system with 2GB RAM. You can set the memlock limit to
unlimited.

Note that it isn't necessary to use an -rt patched kernel to do this,
but it's a good idea to at least have preemption enabled in the kernel
config.

Robert Love's book "Linux Kernel Development" contains a nice readable
explanation of scheduling policies, although it predates rlimits.

John
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

Ralf Mardorf
John Rigg wrote:

> On Fri, Apr 16, 2010 at 09:37:02AM +0000, John Rigg wrote:
>  
>> Since 2.6.13 (released in 2005) the linux kernel has used rlimits for setting
>> RT priorities. You need to edit /etc/security/limits.conf to set it up.
>> I'm not on my audio system now so I can't copy the lines you need to add,
>> but a couple of minutes on google should find them. This isn't a band-aid
>> BTW - it's not unreasonable to expect the system to be configured for RT
>> if you want to run RT processes correctly.
>>    
>
> /etc/security/limits.conf on one of my DAWs:
>
> * hard rtprio 0
> * soft rtprio 0
> @audio hard rtprio 95
> @audio soft rtprio 90
> @audio - memlock 2000000
>
> This allows members of the audio group to use SCHED_FIFO and SCHED_RR.
> This is on a system with 2GB RAM. You can set the memlock limit to
> unlimited.
>
> Note that it isn't necessary to use an -rt patched kernel to do this,
> but it's a good idea to at least have preemption enabled in the kernel
> config.
>
> Robert Love's book "Linux Kernel Development" contains a nice readable
> explanation of scheduling policies, although it predates rlimits.
>
> John
>  

@audio - rtprio 99
@audio -  memlock unlimited

http://www.rncbc.org/jack/rtirq-20090920.tar.gz
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

Ed Wildgoose-2
In reply to this post by Fons Adriaensen-2
On 15/04/2010 16:22, [hidden email] wrote:
>
> If you arrive too late at the airport and your plane
> is gone, or you are not allowed to board, is that a
> 'bandaid' to make air traffic run smoothly ?
> I'd say it's an essential rule. You being late out
> of bed should not affect the rest of the world.
>
>    

Yes, but the analogy is somewhat closer to:

"If you arrive late at the airport then you are never, ever, ever,
allowed to board another plane (until you go down to the office and
resign all the paperwork to be allowed near a plane again)"

I don't dispute that this is useful for some people, I'm just
highlighting that some others of us have different requirements.  In my
case I just want the audio to carry on after it's minor glitch and not
completely stop.  However, the timeout param appears to make that
possible so I am now content

Thanks

Ed W

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

Ed Wildgoose-2
In reply to this post by Ralf Mardorf
On 16/04/2010 14:01, Ralf Mardorf wrote:
> John Rigg wrote:
>> On Fri, Apr 16, 2010 at 09:37:02AM +0000, John Rigg wrote:
>>> Since 2.6.13 (released in 2005) the linux kernel has used rlimits
>>> for setting
>>> RT priorities. You need to edit /etc/security/limits.conf to set it up.

Thanks to all who responded here.  Actually after looking closer I *was*
actually all setup correctly to allow realtime prio and it's covered
nicely in the wiki.  However, you should have also pointed out that
kernels with cgroups configured have some extra configuration needed - I
don't recall without looking if the wiki covers this either?

Probably a more useful note here would have been that the default "ps"
process at least on my gentoo system does not show individual threads by
default and you need to see these if you want to check you really are
running at realtime prio

Just for the sake of the archives I found the following ps command helpful:

     ps H -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm

Thanks

Ed W
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

Ed Wildgoose-2
In reply to this post by Fons Adriaensen-2
On 15/04/2010 16:22, [hidden email] wrote:

> Jack is being used to do things that are with very
> high probably some orders of magnitude more complex
> than what you want to achieve. Such as computing a
> few hundred audio channels in real time. I'm running
> such systems, and I've *never* seem any of the Jack
> clients being kicked out. Things run here for months
> without a single xrun. The key to that is to design
> them correctly.
>
>    

Go on then - I'm a sucker for punishment so I'll take the bait...

So lets assume after say "three months" of flawless running your setup
suffers some unusual circumstance where (say) the system drops some huge
coredump onto some filesystem which turns out to have unexpected kernel
locking, just as the network driver decides it needs some love and for
various unimportant reasons the system goes out to lunch for the length
of one audio fragment....

Now the question is are you a) happy with a single fragment glitch every
3 months, or would you prefer b) for the system to kick you off
completely and you need to restart your clients?

If you prefer b) then I have no disagreement with that, but I am curious
what kind of real life situations make that preferably to say a)  ?

(Lets label a) as "carry on regardless", and b) "fail safe and
disconnect clients")

I really don't quite understand why people have such a problem with a)
being valid for some purposes, but I'm also intrigued as to why people
seem to have such a strong desire to label b) as the only correct
solution?  Please stay away from the "I don't get overruns" argument,
remember the point of this question is to assume that this hypothetical
circumstance HAS already occurred (for some reason outside our control),
the question is "what should we do next"?

Thanks

Ed W

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

Fons Adriaensen-2
In reply to this post by Ed Wildgoose-2
On Mon, Apr 19, 2010 at 08:56:38PM +0100, Ed W wrote:

> On 15/04/2010 16:22, [hidden email] wrote:
> >
> >If you arrive too late at the airport and your plane
> >is gone, or you are not allowed to board, is that a
> >'bandaid' to make air traffic run smoothly ?
> >I'd say it's an essential rule. You being late out
> >of bed should not affect the rest of the world.
> >
>
> Yes, but the analogy is somewhat closer to:
>
> "If you arrive late at the airport then you are never, ever, ever,
> allowed to board another plane (until you go down to the office and
> resign all the paperwork to be allowed near a plane again)"

Given the security paranonia surrounding airplanes I wouldn't
be surprised if such a rule would emerge some day - being late
being interpreted as an indication you wanted to do something
malicious. And after that the UN security council will have
to vote to allow you to use a plane ever again... It's not
really more stupid than not allowing a bottle of water unless
you buy it at five times the normal price after the security
checkpoint.

But at least in most of Europe it doesn't matter if you turn
up late these days... :-)

> I don't dispute that this is useful for some people, I'm just
> highlighting that some others of us have different requirements.  In
> my case I just want the audio to carry on after it's minor glitch
> and not completely stop.  However, the timeout param appears to make
> that possible so I am now content

Yes, but it does allow you to be late at the expense of the
rest of the system. Which really can't be called recommended
behaviour for any Jack client. A really 'decent' client should
take care of that itself - if it can't deliver the data on time
it should at least provide a substitute but not delay the whole
system. If you use buffering that is actually quite easy.

Ciao,

--
FA

O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

Fons Adriaensen-2
In reply to this post by Ed Wildgoose-2
On Mon, Apr 19, 2010 at 09:12:12PM +0100, Ed W wrote:

> On 15/04/2010 16:22, [hidden email] wrote:
> >Jack is being used to do things that are with very
> >high probably some orders of magnitude more complex
> >than what you want to achieve. Such as computing a
> >few hundred audio channels in real time. I'm running
> >such systems, and I've *never* seem any of the Jack
> >clients being kicked out. Things run here for months
> >without a single xrun. The key to that is to design
> >them correctly.
> >
>
> Go on then - I'm a sucker for punishment so I'll take the bait...

Don't put me into temptation... :-)
 
> So lets assume after say "three months" of flawless running your
> setup suffers some unusual circumstance where (say) the system drops
> some huge coredump onto some filesystem which turns out to have
> unexpected kernel locking, just as the network driver decides it
> needs some love and for various unimportant reasons the system goes
> out to lunch for the length of one audio fragment....

Well any 'act of God' you can't plan for. If the hardware
breaks down, if an application has a fatal flaw that makes
it turn all four legs up, there is little that can be done.

These are really things that are part of life anyway and you
probably can't avoid them unless you are designing a system
to such high security standards that it would imply it becomes
single-use and you can and should remove everything that is not
essential for that single function.

Apart from that, on the systems I referred to people have been
watching YouTube, others have run build scripts that take half
an hour, I've been copying 300 Gbytes of audio files to and from
USB disks, etc. all without any ill consequences.
 
> Now the question is are you a) happy with a single fragment glitch
> every 3 months, or would you prefer b) for the system to kick you
> off completely and you need to restart your clients?

It depends. If your application is the only one running it
very probably doesn't matter at all whatever happens.
OTOH, if a glitch has lasting effects, e.g. if it leads to
desynchronisation of things that must remain synchronised
then b) is the only acceptable way.

Ciao,

--
FA

O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Client getting rudely closed?

Fons Adriaensen-2
In reply to this post by Ed Wildgoose-2
On Mon, Apr 19, 2010 at 09:12:12PM +0100, Ed W wrote:

> Please stay away from the "I don't get overruns"
> argument

If your app gets kicked out that means it didn't meet
its deadline (it could be another one as well, Jack
doesn't really do justice in those cases, it doesn't
even try to find the 'most probable' suspect).

Xruns are a different matter, they mean something has
gone wrong in the backend, usually at the ALSA level.
There's nothing your app or any other could do about
that, and it can't be blamed for them.

But the existence of xruns which are out of your control
isn't an excuse your app being late. There are really two
very separate issues.

Ciao,

--
FA

O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
12