Re: [Discuss-gnuradio] SCHED_FIFO and NPTL

[Frank Brickle]

Eric Blossom wrote:

> Using LD_ASSUME_KERNEL=2.4.19 effectively forces the old (pre-NPTL)
> behavior, which means that acquiring an uncontested mutex requires a
> trip to the kernel.  I believe it also means that mutexes won't work
> in shared memory across process boundaries.  Those seem like total
> losers to me...

This adds up to: futexes don't work (yet). Is that right?

I'm still confused about a couple of things. On one hand the holy grail 
appears to be getting the number of frames in a jack buffer down to 64 
so as to minimize the roundtrip latency. On the other hand you want to 
eliminate xruns. They aren't the same by any means.

It's not clear that minimizing roundtrip latency means much when you're 
using DSP buffers of 512 frames or more. By the same token, in what I've 
observed, the chief culprit for the xruns is the X window system. There 
is a very delicate balancing act going on in the process priorities 
between the audio subsystem and the video subsystem. I'm not convinced 
that running SCHED_FIFO is going to routinely enable the audio subsystem 
to slide in under the video action under all circumstances.

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.

73
Frank
AB2KT