I agree, on light system load the linux responsiveness is *MUCH* better than
windows.
Using very small buffers (<5ms) , it's hard to actually HEAR these drop-outs,
if you get only sporadic drop-out, let's say every 5-10 sec.
But, they are present.
The best way I found to measure these deadlines is to use the
Pentium RDTSC cycle counter , so you are sure that you don't block
during gettimeofday().
On my machine for example during heavy graphics output
(I ran "x11perf -all" in the background for about 1 hour),
you can't go below the 15ms mark if you don't want sporadic dropouts.
In this case I am pretty satisfied , because 15ms an acceptable value.
>
> It *is* true that if there is a lot of disk activity, particularly
> with IDE disks but also to a lesser extent with SCSI, then latencies
> below about 100ms lead to audio dropouts.
>
> Its also true that Windows can do 20ms latencies *with* heavy disk
> activity, but it can't do 1.3ms latency under any circumstances. So
> right now, we have to pay (or not pay) our money and take our choices.
Nemesystech ( http://www.nemesystech.com ) has a program called GIGASAMPLER,
which runs on Windows, they claim to archieve 5ms latencies,
and even stream the notes from disk (with pre-buffering the first part of the
samples in RAM), of course such a program is written in assembly and uses
dirty tricks, but I'm not sure if these values are for real.
I've read the BeOS specs, and they claim to archieve
250 usec scheduling latencies, I was wondering if BeOS is stable in a 5ms
audio-MIDI latency enviroment , during high I/O.
P.S: I'm currently enhancing my benchmark to stress the OS even more,
through wasting a considerable CPU bandwith (let's say >80%),
using loops, after each wrtite() to /dev/dsp , do simulate a CPU hungry synth,
I use now the RDTSC do do measurements, to get even more accurate results.
I will post the URL plus some benchmark results soon.
>
> Still, it would be nice, as I said above, for writes to audio devices (and
> MIDI, and serial, and all other non-disk devices) to be considered
> independent of any locking or synchronization schemes used for disk
> writes. There is no reason that I can see for their to be any
> relationship between write ("/dev/sda1", ...) and write ("/dev/dsp",
> ...), certainly not once any lookups the file descriptors are done.
fully agree, seems that ,according to Alan Cox, each device-class
( audio / MIDI / serial) has to be "decoupled" from the disk I/O locking
separately,
he said the audio part is a task for the ALSA people,
so I think we should begin to think about how to implement this.
I don't know if the serialport code has this problem too,
but if it's present, it would be nice to change this too.
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/