[rtl] Re: preempting I/O (audio latency + making X more responsive)

[Benno Senoner <sbenno@gardena.net>]

On Thu, 19 Aug 1999, Juhana Sadeharju wrote:
> Hello. I have a question related to audio latency. It looks Benno
> measured the latency with an audio program which doesn't use the disk. 
> But still many audio programs use the disk and I see only problems
> in it. My questions follows.

my approach is the following:
use two threads: 
one SCHED_FIFO max priority thread which does only audio I/O , no disk I/O,
the other maybe SCHED_RR min priority or SCHED_OTHER  nice -10 or so
which does only disk I/O and communicates via shared memory with the audio
thread.

Mingo demonstrated that it's possible to achieve <4.3ms audio latency on a PII
box, on high disk I/O load.
( Will post soon nice large GIFs on my page to show the exciting results)

Therefore IMHO the best solution is to have some disk I/O thread which
does the I/O for the audio thread using large buffers. 
That's why you need quite large amounts of memory on commercial harddisk
recording software on Windoze like Emagic Logic, Cubase, Cakewalk etc.
To be safe you should buffer from .5 to a few seconds of audio.
2 sec of audio = about 350kb/sec
32 tracks x 350 kb = 10MB
I see it as a bad idea to perform disk I/O in the main dsp thread, since if you
have a slow disk you can't control latency fully.
With the 2 threads method, the only concern is I/O bandwidth, the latency
problems are solved by the large buffers.
( David, or are there better methods around ? :-) )
  > 
> If both RT priority and user priority process makes a read() to the disk
> while disk is still serving a previous read/write, what happens?

I think it gets preempted but not as fine-grained as you want.
> 
> If previous read was done by user priority process, will it be killed
> and RT process's read serviced immediately?

I don't know but I might suspect that since your RT scheduled thread
sleeps while the read() call blocks, and therefore other processes are run,
it will ruin completely your realtime performance. 
> 
> Will RT process read get the turn before the user process read independing
> on which order the reads were done?
>> 
> I hope I got all important to those questions.
>> 
> Somehow the kernel's page swapping should co-work with this system because
> it would not be good if RT process is freezed by heavy swapping of lower
> priority process.

Seems that mingo's patches do handle swapping as well, but I can't confirm this
(not tested yet).
You should always use mlockall() for realtime processes.

> 
> If kernel's page swapping is prioriticed, it might happen that X server
> freezes. But that is okay, because realtime audio system should take
> its all inputs from realtime devices such as MIDI controller. Of course,
> it would be great if X windows would have a priority system allowing
> a synth GUI to get its events processed before any other X clients.

I had the same idea: mingo's patches do have additional benefits:
a process which does graphics only output, achieves the same low latencies
than audio apps , therefore since the X-server is a process,
one solution could be to run the X-server process at SCHED_RR min priority,
so that it gets preempted when audio apps need the CPU,
plus it would be useful to have some X queue prioritization,
so that RT threads could get faster response when sending/receiving X11 events
over normal  scheduled processes.
Or are there better methods around ?
Is a similar event-queue prioritization already included in the X11 protocol ?
Or is some work in this direction already underway ?
Low scheduling latencies do allow smooth video playback on a highly loaded
system, and this is a big advantage for video capturing/editing, especially
on software only system (not hardware assisted)

It would be nice to hear some comments from the XFree86 people. 


regards,
Benno.

--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail majordomo@rtlinux.cs.nmt.edu OR
echo "unsubscribe rtl <Your_email>" | mail majordomo@rtlinux.cs.nmt.edu
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/