1 Nov
2003
1 Nov
'03
4:54 p.m.
Hi,
I regularly read the german "Keyboards" magazine and in some
occasions they tested some Windows softsynths/HDR apps and measured
voicecount/number of parallel instances of plugins.
They usually talk about "3 msec latency" case but in one occasion
I've seen they talked about "1.5msec latency" too.
I could be wrong but I assume they are misinterpreting "fragment
latency" and total latency, fooling users into believing that the
latency numbers they gave refered to the total latency.
My question is: since the Hammerfall cards always use two fragments,
are the buffer size (latency) figures shown in the diagram below:
http://www.rme-audio.de/images/hdsp/mf_set.gif
refered to the whole buffer or to a single fragment.
for example take the 1.5msec (64 samples) case.
Does that mean 64 samples in total (32samples/fragment = 0.75msec per
fragment) or 64 samples per fragment (1.5msec per fragment thus a total
3msec).
I'm sure Paul D. and other Hammerfall experts will be able to enlighten me.
Sorry for the question but I just wanted to be sure that it's not the
case where per-fragment latencies as sold as total latencies since lower
latency numbers are always cool :-)
cheers,
Benno
http://www.linuxsampler.org
1 Nov
1 Nov
5:07 p.m.
New subject: [linux-audio-dev] Re: Hammerfall latency confusion in german "Keyboards" articles ?
hmmm, I'll try to respond to my own question:
(hoping having done the math correctly):
alsa-kernel/pci/rme9652/hdsp.c:
hdsp->period_bytes = 1 << ((hdsp_decode_latency(hdsp->control_register)
+ 8));
latency register is 3 bit long, set all 3 bit to 0 and you get the
lowest possible latency:
period_bytes=1 << (0+8) = 256
we are talking about 32bit words (24bit audio embedded in 32bit words)
thus we need to divide bytes / 4
we get 64.
one period = one fragment thus I assume the minimum buffer size = 2 x 64
= 128 samples which
at 44100 = 3msec. (the keyboards test were done at 44.1kHz).
So basically my assumption seems to be correct (I hope so :-) ).
Perhaps these "latency" journalists are exactly those that say that
Linux audio is not a reality
and will have no future anyway :-)
cheers,
Benno.
Benno Senoner wrote:
Hi,
I regularly read the german "Keyboards" magazine and in some
occasions they tested some Windows softsynths/HDR apps and measured
voicecount/number of parallel instances of plugins.
They usually talk about "3 msec latency" case but in one occasion
I've seen they talked about "1.5msec latency" too.
I could be wrong but I assume they are misinterpreting "fragment
latency" and total latency, fooling users into believing that the
latency numbers they gave refered to the total latency.
My question is: since the Hammerfall cards always use two fragments,
are the buffer size (latency) figures shown in the diagram below:
http://www.rme-audio.de/images/hdsp/mf_set.gif
refered to the whole buffer or to a single fragment.
for example take the 1.5msec (64 samples) case.
Does that mean 64 samples in total (32samples/fragment = 0.75msec per
fragment) or 64 samples per fragment (1.5msec per fragment thus a total
3msec).
I'm sure Paul D. and other Hammerfall experts will be able to
enlighten me.
Sorry for the question but I just wanted to be sure that it's not the
case where per-fragment latencies as sold as total latencies since lower
latency numbers are always cool :-)
cheers,
Benno
http://www.linuxsampler.org
6:12 p.m.
New subject: [linux-audio-dev] Re: Hammerfall latency confusion in german "Keyboards" articles ?
Hallo,
Benno Senoner hat gesagt: // Benno Senoner wrote:
Perhaps these "latency" journalists are
exactly those that say that
Linux audio is not a reality and will have no future anyway :-)
Write them about the latency figures. I'm constantly confused by the
numbers in "Keyboards", they really should define what kind of latency
they use.
ciao
--
Frank Barknecht _ ______footils.org__
8:38 p.m.
New subject: [linux-audio-dev] Re: Hammerfall latency confusion in german "Keyboards" articles ?
Frank Barknecht wrote:
Hallo,
Benno Senoner hat gesagt: // Benno Senoner wrote:
I've got a better idea: organize a commando that kidnaps their whole
staff and chain them
on a chair for the whole duration of the next ZKM while they will be
hammered 8-10 hours a day
with technical talks and linux audio aplication demonstrations.
I guess that move would eliminate both the confusions about latency and
will certainly
prevent future spreading of misinformation about Linux audio. :-)
Zwei fliegen mit einer Klappe wie man so sagt :-)
Benno
http://www.linuxsampler.org
Perhaps these "latency" journalists are
exactly those that say that
Linux audio is not a reality and will have no future anyway :-)
Write them about the latency figures. I'm constantly confused by the
numbers in "Keyboards", they really should define what kind of latency
they use.
ciao
9:30 p.m.
New subject: [linux-audio-dev] Re: Hammerfall latency confusion in german"Keyboards" articles ?
-----Original Message-----
From: linux-audio-dev-bounces(a)music.columbia.edu
[mailto:linux-audio-dev-
bounces(a)music.columbia.edu] On Behalf Of Benno
Senoner
Sent: Saturday, November 01, 2003 5:03 PM
To: linux-audio-dev(a)music.columbia.edu
Subject: [linux-audio-dev] Re: Hammerfall latency confusion in
german"Keyboards" articles ?
hmmm, I'll try to respond to my own question:
(hoping having done the math correctly):
alsa-kernel/pci/rme9652/hdsp.c:
hdsp->period_bytes = 1 <<
((hdsp_decode_latency(hdsp->control_register)
+ 8));
latency register is 3 bit long, set all 3 bit to 0 and you get the
lowest possible latency:
period_bytes=1 << (0+8) = 256
we are talking about 32bit words (24bit audio embedded in 32bit words)
thus we need to divide bytes / 4
we get 64.
one period = one fragment thus I assume the minimum buffer size = 2 x
64
= 128 samples which
at 44100 = 3msec. (the keyboards test were done at 44.1kHz).
All that seems to be correct. However AFAIK, the higher the sampling
rate the lesser amount of time do those 128 samples encompass. Hence if
you have double the sampling rate 88200Hz, then 128 samples ends up
being only ~1.5ms. Of course you could go really crazy and do 192000, in
which case latencies would be sub-millisecond. 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...
Ico
11:21 p.m.
New subject: [linux-audio-dev] Re: Hammerfall latency confusion in german"Keyboards" articles ?
On Sunday 02 November 2003 02.30, Ivica Bukvic wrote:
[...]
All that seems to be correct. However AFAIK, the
higher the
sampling rate the lesser amount of time do those 128 samples
encompass. Hence if you have double the sampling rate 88200Hz, then
128 samples ends up being only ~1.5ms. Of course you could go
really crazy and do 192000, in which case latencies would be
sub-millisecond.
But the sample rate *was* specified to 44.1 kHz in this case, wasn't
it...?
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...
You can process one sample at a time at 44.1 kHz on most decent PCs
running RT-Linux, RTAI or some other "industrial strength" RTOS.
Those get the latencies practically all the way down to the hardware
limits, meaning worst case latencies of less than 10 microseconds on
well built Celeron or better systems. Also note that the x86 arch
sucks at this pretty much by design. Alpha, PPC and others can get
even lower latencies.
Of course, you can't use normal PCI busmaster DMA for that, since
there's a minimum burst size limit at 64 bytes or something. (Though
you could most probably get around that if the sound card is designed
for it, and/or does DMA with a fully programmable chip.) PIO or ISA
DMA works just fine, but that's generally only available on old ISA
sound cards.
//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 ---
2 Nov
2 Nov
2:09 a.m.
New subject: [linux-audio-dev] Re: Hammerfall latency confusion ingerman"Keyboards" articles ?
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. 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...
> 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. 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).
Ico
10:23 a.m.
New subject: [linux-audio-dev] Re: Hammerfall latency confusion ingerman"Keyboards" articles ?
Ivica Bukvic wrote:
The Keyboards magazine talked about 44.1kHz so my assumptions do seem
correct.
Of course if you increase the sample frequency the latency decreases
accordingly but
My question was whether or not Keyboards used the correct terminology.
Anyway I think they are probably fooled by RME itself because on their site
when they talk about latency they mean per-fragment latency while
probably people reading
the pages assume they talk about the total latency.
I think RME should be more specific on their pages in order to avoid
confusion.
Of course 1.5msec latency has a bigger marketing impact than 3msec, but
if afterwards
users figure out that the latency is twice the one they thought they
will not be that happy.
A simple "3msec total latency" or "3msec per fragment latency" would
clear up any doubts
and probably avoid the spreading of misinformation by keyboard magazines
journalists too.
If the RME's HDSP control does not correct the latency values when you
increase the sampling rate
I simply consider it a bug, users should report that to RME.
refering to "the best achievable latency" is crap and totally
unscientific and should be fixed
in the Windows GUI.
BTW: Is there a linux GUI too ? (I seem to remember that Paul D. once wrote
one for the old Hammerfall that looked like the Windows counterpart).
I hope that the Linux GUI displays the correct values.
Benno
http://www.linuxsampler.org
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. 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...
3 Nov
3 Nov
1:50 p.m.
New subject: [linux-audio-dev] Re: Hammerfall latency confusion ingerman"Keyboards" articles ?
Hallo,
Benno Senoner hat gesagt: // Benno Senoner wrote:
BTW: Is there a linux GUI too ? (I seem to remember
that Paul D. once wrote
one for the old Hammerfall that looked like the Windows counterpart).
I hope that the Linux GUI displays the correct values.
I think, hdspmixer in the alsa-tools archive is what you want.
ciao
--
Frank Barknecht _ ______footils.org__
5:42 p.m.
New subject: [linux-audio-dev] Re: Hammerfall latency confusion ingerman"Keyboards" articles ?
On Sunday 02 November 2003 07.09, Ivica Bukvic wrote:
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.
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.
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. 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. 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 ---
7682
days inactive
7684
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
4 participants
participants (4)
-
Benno Senoner -
David Olofson -
Frank Barknecht -
Ivica Bukvic