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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio