David Olofson is actually designing an killer audio-engine,
but I plan to implement some demo code to show to vendors, the
TRUE audio capabilities of Linux.
My plan is to develop a demo app, which opens the soundcard in R/W mode,
plays let's say 20-30 .wav files from disk , mix them together ,
maybe with a little Qt app which allows changing volume + applying a
lowpassfilter (parameters adjustable in real-time) of each track,
emulates a simple MIDI sampler (just interpolate a .wav file to the frequency
according to received note-on events) , recording the soundcard's input
and mix together all sources and write the result to 10 wav files,
just to simulate a complex load on a harddisk recording system +
software-synth,
of course with max 5-6ms input-to-output latency and 5-6ms MIDI to audio
latency.
I'm pretty confident that my box is able to handle this load.
I think I will use about 3 threads.
One for pure audio I/O, one for MIDI I/O , since it seems that I'm unable to
open the MIDI device in non-blocking mode, or maybe I could use select()
to see if data is available, but since I must read 1 byte at time,
to avoid blocking, I must do multiple select() iterations in my DSP cycle,
and I don't like to issue that many syscalls in the same cycle.
The third thread is the disk I/O thread, will run at lowest priority, but still
higher than normal tasks, to avoid interferences.
Anyone got better ideas ?
>
> But loading large buffers blocks the disk usage from other audio streams?
> What about making the large buffers fragmented so that fragments of different
> buffers are interleaved in loading/writing? Using small buffers might
> increase the load of the audio engine and thus fragmented large buffers
> might be a good compromise.
Sorry, I meant sum of all buffers = large , of course you may buffer about
1-2sec per track, and therefore when you do miltitrack playback you read
one buffer at time in an interleaved fashion.
>
> I think that is a bit incorrect. I suspect large buffers blocks the system
> from reading multiple files simultaneously. Latency is increased by
> preloading the audio. Preloading is possible if we have a sequence data or
> an editlist, but if we get a MIDI note, then preloading is not possible
> unless we preload a bit about every possible audiofile the MIDI instrument
> might use. If we allow MIDI instruments to use audiofiles on disk, we should
> use the same latency in any audiofile instruments -- and more, in any
> instrument even if they don't use disk -- so that we don't get jitter between
> instruments. This sequencing latency naturally lessens the performance
> requirements, I guess.
This concept called sample-streaming directly from disk is pretty new,
and the only example I know is Nemesystech's Gigasampler (
http://www.nemesystech.com ) ,a windoze app which allows you to play MIDI
samples in the GByte range.
Of course to ensure fast Note-on response, you must
buffer the first part of the sample ( let's say again 0.5 - 2 sec) , and load
from HD dinamically until you release the key.
But this case is more complicated than regular multitrack playback since you
have dynamically triggered playback, and to increase performance you have to
use smart caching algorithms.
>
> >You should always use mlockall() for realtime processes.
>
> I see a slight misunderstanding here and there. I mean, if some non-audio
> software starts to swap or to read disk, then it might block the RT audio
> disk readings/writings. I cannot lock those third party processes but the
> kernel could freeze their disk usage if my RT audio software wants to use
> disk. Prioriticing disk usage and making it preemptive would help. But can
> a DMA transfer be interrupted? Kernel would stop the current disk read (by
> non-RT process) and give the DMA to RT process.
>
> The disk and the audio RT process would sleep when they wait data and
> at that time, could any other process start some large disk reading.
> That disk reading should be interrupted as soon as possible.
I think that actually this problem is almost unavoidable,
but if you dedicate a separate disk to audio stuff, the system should be quite
stable , since swapping and general purpose disk I/O goes to the other disk.
I read something that the QLinux folks are developing a bandwidth allocating
disk scheduling algorithm , so that you could request
guaranteed 2MB/sec for your app, without the risk of an "overbooked" disk.
Hopefully it will will get usable soon.
But in the mantime you have only to worry about very high disk I/O in
background IF you use more than 70% of the theoretical disk bandwidth in
your audio-recording app.
My goal was that linux should provide a good and stable platform, for
high perfromance/realtime audio, and it seems that things looks very good now.
Of course since there is no I/O prioritization in Linux, a background
running task making heavy disk I/O requests could lower the number of tracks
which we are able to play simultaneously, but will not be able to generate
drop outs in the pure audio process.
The old problem was that disk I/O increased scheduling latencies of ALL
processes, including non-disk related processes.
Therefore a background kernel compilation caused audio drop outs, even in an
app playing audio data from RAM.
Now our problem will be: a task doing heavy disk I/O in background will
decrease the I/O perfromance of our harddisk recording app,
I have no numbers yet, but a little test which writes 2 files of 600MB each with
a blocksize of 1MB
dd if=/dev/zero of=tmpfile1 bs=1000000 count=600 running at priority -20
and
dd if=/dev/zero of=tmpfile2 bs=1000000 count=600 running at priority 0
shows me that the higher priority (nice -20) "dd" writes the data to the disk
about 2-2.5 times faster than the "dd" running at normal priority.
Therefore if you plan to run other I/O intensive tasks, just leave some 30-40%
headroom when doing audio-from/to-disk stuff,
(this means if theoretically the disk is able to deliver 80 track playback,
just don't use more than 50-60)
or use a separate disk for audio, or use Linux software RAID code an make a
RAID0 array with up to n-fold disk bandwidth.
IMHO a powerful PII box, with 3-4 UDMA EIDE disks
(like my nice IBM 16GB -:) ), combined with the soft-RAID features of Linux
could deliver so many tracks that even the most demanding audio-recording folks,
even David. :-)
To do some comparison on the Windoze side: Gigasampler will not deliver many
from-disk-streaming voices, if you run a harddisk recording app in background.
regards,
Benno.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/