Subject: Re: [linux-audio-dev] lowish-latency patch and toolchain
From: Juhana Sadeharju (kouhia_AT_nic.funet.fi)
Date: Mon Jul 10 2000 - 12:26:40 EEST
>From: Tom Pincince <stillone_AT_snowcrest.net>
>
>This is *the* key issue here. Simply saying that audio apps require an
>OS with sub 5 ms latency is incomplete and potentially misleading.
We are talking about proaudio here. 5 ms is fine for me, but some
disk based systems at 1982 (20 years ago!) had 1.5 ms latency which
need was properly justified.
>feel that pro quality audio on regular Linux is achievable, combined
Pro audio as defined by MS Windows?
>The way we accomplish this is by
>dedicating the box to audio, disabling all non-essensial background
>tasks, and generally avoiding anything that might cause the OS to become
>too busy while we are actually recording.
Why would we want to avoid anything like that? It is possible to make it
reliable so that no reading docs or any other normal activity disturb the
latency. While recording, I could use a software synth to generate new
samples files or let the FFT convolver to add sampled reverbs to audio clips.
Why would I need to wait for a suitable time to do those, or to stop
any background jobs to be able to record or use the Linux as low-latency
effect box?
>are truly impressive. I have gone *years* without a single dropout on a
>68040 mac running system 7.5.1.
How do you know this? Do you have a dropout counter in your applications?
>be deleted, it is not true that file deletion and recording must happen
>simultaniously.
Why in earth would you stop doing anything else while recording? That was
the Mac and MS Windows era. Now we have Linux with proven capability
to allow other jobs during recording. I'm just waiting those quaranted
bandwidth filesystems to arrive to Linux, but much can be done without them
if we get the proper lowlatency support.
>useless files, and it seems easy enough to design a recording app that
>only allows file deletes when the app is not actively recording.
We have also many other applications want to use. For example, patch
processing may take a lot of time, even days, and I want to be able
to record at any time without killing those background jobs.
>recording app only needs guaranteed minimum latency while it is actively
>recording. Latency is a non-issue at all other times.
Don't forget audio engines such as used in games or in Gigasampler
(a sampling synth reading samples directly from the disk).
-*-
I think 4 ms could be better. If we don't get any agreement we really
should go for the old 2 ms lowlatency patch and forget any new compromized
kludge.
It would be nice if Linus would allow keeping this kludge patch as
compilation option in Linux source tree, so that it comes with every
Linux distribution. That would be __a real compromize__!
Regards,
Juhana
This archive was generated by hypermail 2b28 : Mon Jul 10 2000 - 12:59:18 EEST