Subject: Re: [linux-audio-dev] analog latency
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sun Jun 11 2000 - 02:50:44 EEST
On Sun, 11 Jun 2000, Paul Barton-Davis wrote:
> just a quick little FYI:
>
> i was reading the "manual" that came with some new Tannoy monitors I
> got a few weeks ago. there is a comment in the back to the effect
> that:
>
> * the filters on almost every analog EQ have a delay time of
> 25usec
> * with only a few exceptions, all equalizers run the filters
> in series.
>
> So much for the naive belief that analog systems have no latency.
>
> OK, not much :)
>
> --p
"in series ..." = In practice ?
Does that mean a 16band EQ = 16 x 25usec = 400usec = 0.4msec ?
Anyway I've noticed that when reading windows-software (softsynths
sequencers etc) specs on magazines and on online pubilications,
they almost always seem to refer to the latency of the single buffer.
For example some say: ASIO latency down to 7msec , but looking
at the screenshot the latency is per buffer.
That means you have to multiply this value at least by 2 when doing
input-->output processing,
and by 1.5 (in average) when talking about softsynths.
The fun thing is that when you browse windows sequencer newgroups
you hear: my SBLive! has 50-100ms latency, and others reply
buy a faster card like the Motu2048.
That is just silly: I get 2.1ms using a SBLive, a Tropez and an AWE64.
They are so foolish to throw away the SBLive because the card
does not deliver good latencies , let's say on Cubase.
They do not understand that the _ONLY_ thing to blame is
the Windows OS. (and perhaps optimized ASIO drivers which come
with certain soundcards)
I saw so many misleading information like this.
And even commercial audio software vendors are following the same
stupid line: throw away your soundcard (which is fully suitable for
realtime stuff from a HW point of view ) and buy another if you want
good latencies.
If I were a soundcard manufacturer I would be very upset
hearing stuff like this.
I think we sould write an article about the PC-soundcard latency myths / truth.
Some interesting quotes from the Gigasampler FAQ:
--- Our background is in embedded real-time DSP disciplines - where hard real-time operating systems are absolutely essential. Since the necessary driver interface did not exist for Windows®, we used our DSP OS experience to create GSIF. Though the development process took several years, the resulting drivers are what place GigaSampler and GSIF at the top of reviewers' picks. ---Notice the TOOK YEARS part ....
"years of work" can be invested in something more useful , than just being able to get a bit better latency from the OS.
Plus Windows is a black OS, there is no written guarantee that a part of the kernel will not block for more than a certain amount of time, plus there is no source code to inspect. From an engineer POV ... frustrating.
--- About GSIF GSIF (GigaSampler Interface) is the fastest PC audio hardware interface available today. Our ultra-advanced driver technology has been a core component of GigaSampler[tm] from the start, as existing APIs are simply not fast enough for a professional sampler. In music-critical situations, latency (the amount of time that passes from when a key is pressed and a sound is heard) is everything. This is why so many of today's software-based synthesis tools are pattern-based instead of playable in real-time. The MIDI-to-trigger latencies are simply not available without a properly engineered interface. ------
our "proper engineered" interface (a simple userspace app which delivers HW sampler-like response times) looks as follows:
audio thread: (runnig with higher priority than the MIDI thread) while(1) { read_midi_message_from_lockfree_FIFO(); do_dsp_processing(); (render audio) write_audio_fragment() } MIDI thread while(1) { wait_for_MIDI_messages() ( select() ) read_MIDI_messages_and_put_the_result_in_the_FIFO() }
Should not be too hard to understand ... :-)
GSIF the fastest ? Notice that they work 100% in kernel mode. (with the nice sideeffect that if something goes wrong sh*t happens, plus heavy kernel dependency, a new version of the OS might break the app completely) While my ALSA 2.1ms latency tests are 100% userspace based
Benno.
This archive was generated by hypermail 2b28 : Sun Jun 11 2000 - 03:02:37 EEST