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