Re: [Discuss-gnuradio] SCHED_FIFO and NPTL

[Frank Brickle]

Eric Blossom wrote:

> > Bottom line, it hasn't actually been proved that running SCHED_FIFO will 
> > squash the existing latency and continuity problems, so I'm not at all 
> > sure much is missing without that capability.
>
>
> Frank, is this a statement or a question?

It's a statement. I don't have any real proof at the moment but I 
suspect SCHED_FIFO is a bit of a red herring. I haven't got proof 
because the couple of times I tried to actually measure a difference I 
tripped over additional activity that needed to be accounted for, like, 
for example, periodic journaling filesystem updates.

The other unfortunate consequence was that some kinds of X action on the 
desktop, like switching between multiple desktops, would get deferred -- 
 it got real sluggish -- and then all the display activity would happen 
in a burst. Sometimes that would choke the audio worse than an 
occasional xrun. Oh, and the interaction with audio subsystem buffer 
sizes was unpredictable.

I'm suggesting that the current non-RT scheduling is very delicately 
balanced and there's no single, universal fix. What's more, I conjecture 
that the worst culprit is disk activity, specifically paging, and that 
the cost/benefit fix for that is running off ramdisk :-)

It would be *wonderful* to be wrong about this. As I said, it's just a 
strong hunch.

> I'm not sure if the JACK FAQ is up to date or not.

Usually not :-)

> Do you have data
> on the success or failure of folks running JACK on ALSA using NPTL and
> if they are able to get sufficiently good performance?  I guess Ardour
> users would be a good test case.  How about the dttsp stuff under Linux?

Again, it ain't conclusive, but it looks like xruns are not a problem 
with DttSP under Linux. You're absolutely right, Ardour users are the 
ones to ask. I finally have it installed here and can check it out first 
hand, at long last.

Frank