Subject: Re: [linux-audio-dev] Re: Hammerfall latency confusion ingerman"Keyboards" articles ?
From: David Olofson (david_AT_olofson.net)
Date: Mon Nov 03 2003 - 23:41:35 EET
On Sunday 02 November 2003 07.09, Ivica Bukvic wrote:
> > But the sample rate *was* specified to 44.1 kHz in this case,
> > wasn't it...?
>
> Well if you wanna get *technical* about it, the hdsp tools (which
> was in the screenshot) on Windows reflects the same latency values
> regardless of what sampling rate you use (they do not change their
> ms rating in order to adjust to the changes in sampling rate -- see
> http://meowing.ccm.uc.edu/~ico/hdsp.jpg), and the original
> question, even though pointing at that particular screenshot did
> not necessarily refer only to the 44.1kHz sampling rate, but rather
> to the best achievable latency.
But the radio buttons list both buffer size and latency, so either one
column of values has to change if you change the sample rate, or
something is wrong... Or was that the whole point?
Never mind - I jumped in and probably missed the point. Sorry 'bout
the wasted bandwidth.
> In his case the original poster was
> right in both assumptions: 128 bits x 2 could be either 1.5ms or
> 3ms depending upon the sampling rate...
Yes, of course.
> > > There is obviously still a question whether any
> > > kernel on the face of earth would be able to provide soundcard
> > > with data in time in order to avoid dropouts...
>
> <snip>
>
> > Also note that the x86 arch
> > sucks at this pretty much by design. Alpha, PPC and others can
> > get even lower latencies.
>
> Although this used to be the case, I tend to disagree, because
> where x86 architecture is lacking in design, it compensates with
> the increased clock speeds and various add-ons (i.e.
> hyper-threading). Even with a branch mis-prediction in a lengthy
> pipeline, these chips pump-out enough cycles/second to be able to
> withstand such penalties without much, if any performance loss when
> compared to their competition.
Good point, and most relevant when it comes to audio. It's still
pretty much moot in control engineering, where "real" RTOSes are
normally used and 486 and Pentium class hardware is still common.
However, that kind of hardware can't do all that much in terms of
audio processing in a studio anyway.
> This furthermore is a mute point
> with the 64-bit Intel's and AMD's offering as well as the upcoming
> Prescott (if the rumors are to be trusted).
It would be interesting to see some real figures with RTAI or RTL on
such hardware. (For CPU intensive control engineering stuff mostly.
For audio, I'd consider RTL or RTAI only if the requirements are
extreme and/or the lowlatency stuff won't work for some reason.)
Unfortunately, I don't seem to get along with Google right now, so I
don't know for sure if RTL and/or RTAI has been ported yet. Seems
like RTL *might* have IA64 support (the pro version...?), but I can't
find anything on RTAI.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
This archive was generated by hypermail 2b28 : Mon Nov 03 2003 - 23:46:31 EET
