Re: [linux-audio-dev] Re: desktop and multimedia as an afterthought? - Linux-audio-dev

13 Jul 2004

From: "Bill Huey (hui)" &lt;bhuey(a)lnxw.com&gt;
...
  On Tue, Jul 13, 2004 at 01:09:28PM +0100, Martijn
Sipkema wrote:
  [...]
  Please double-check that there are no priority
inversion problems and that
 the application is correctly setting the scheduling policy and that it is
 mlocking everything appropriately.  
 I don't think it is currently possible to have cooperating threads with
 different priorities without priority inversion when using a mutex to
 serialize access to shared data; and using a mutex is in fact the only portable
 way to do that...

 Thus, the fact that Linux does not support protocols to prevent priority
 inversion (please correct me if I am wrong) kind of suggests that supporting
 realtime applications is not considered very important.  
 Any use of an explicit or implied blocking mutex across threads with differing
 priorities can results in priority inversion problems. The real problem, however,
 is contention. If you get rid of the contention in a certain critical section,
 you then also get rid of latency in the system. They are one and the same problem.

The worst case latency is the one that counts and that is the contended case. If
you could guarantee no contention then the worst case latency would be the
very fast uncontended case, but I doubt there are many (any?) examples of this in
practice. There are valid uses of mutexes with priority inheritance/ceiling protocol;
the poeple making the POSIX standard aren't stupid...

...
   It is often
heard in the Linux audio community that mutexes are not realtime
 safe and a lock-free ringbuffer should be used instead. Using such a lock-free
 ringbuffer requires non-standard atomic integer operations and does not
 guarantee memory synchronization (and should probably not perform
 significantly better than a decent mutex implementation) and is thus not
 portable.  
 It's to decouple the system from various time related problems with jitter.
 It's critical to use this since the nature of Linus is so temporally coarse
 that these techniques must be used to "smooth" over latency problems in the
 Linux kernel. 
Either use mutexes or POSIX message queues... the latter also are not
intended for realtime use under Linux (though they are meant for it in
POSIX), since they don't allocate memory on creation.

...
  I personally would love to see these audio
applications run on a first-class
 basis under Linux. Unfortunately, that won't happen until it gets near real
 time support prevasively through the kernel just like in SGI's IRIX. Multimedia
 applications really need to be under a hard real time system with special
 scheduler support so that CPU resources, IO channels can be throttled.

 The techniques Linux media folks are using now are basically a coarse hack
 to get things basically working. This won't change unless some fundamental
 concurrency issues (moving to a preemptive kernel with interrupt threads, etc..)
 change in Linux. Scattering preemption points manually over 2.6 is starting to
 look unmanable from all of the stack traces I've been reading in these latency
 related threads. 
Improving the mutex and mqueue implementations to better support realtime
use would be a significant improvement I think, making Linux quite suitable
for realtime audio use.

--ms