Hell yeah man! We aint takin no more shit from GigaSampler or their
ASIO/GSIF "standards"!
-Garth
> -----Original Message-----
> From: Benno Senoner [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, June 10, 2000 7:51 PM
> To: Paul Barton-Davis; [EMAIL PROTECTED]
> Subject: Re: [linux-audio-dev] analog latency
>
>
> 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.
>
