4 Feb
2004
4 Feb
'04
3:38 a.m.
Hi Antonio,
On Wednesday 04 February 2004 02.21, Antonio wrote:
Hi to all,
I'm tryng to tune my machine to get the lower latency I can get with my
hardware and linux of course.
I have an audigy player with a debian sarge with the audio apps take
from the unstable branch. I've recompiled the 2.4.22 kernel with
capabilities, low latency, preempted patches. I've compiled the source
packages of alsa 1.0.1 and jack 0.94.
I can obtain a clean sound playing timidity thru my midi keyboard using
3 fragments each of 256 (but only if I'm root, otherwise I get "can't
set sched_setscheduler" and the sound became dirty, maybe I have to
recompile it?)
This is normal, programs that wish to run with realtime-capabilities have to
have elevated capabilities. The easiest, and most insecure, way of achieving
this is to run the program directly as root. Another possibility to provide
this is to set the application SUID, e.g. add the +s 'bit' to the binary with
chmod. There are other (better?) ways also, using capabilities is probably
what most people suggest. I tend to stick to running the apps as root...not
the best way...
which means a pretty low latency for me.
Yep, should work pretty good.
On the other side I can run jack (jackstart works
fine) with a period
not less than 512,
The difference between the two is that timidity probably opens the soundcard
with write-only, whereas jack by default opens it read-write (full duplex).
The emu10k driver doesn't allow any setting below -p 512 if you run in full
duplex. If you change the output of jack so it only writes you could set it
lower here too.
I think this is a shortcoming of the driver. I've come to understand that the
emu10k1 is capable of much lower settings with the kx drivers in windows.
and I can't change the number of periods (neither
increase) that is 2 by default. For example:
$ jackstart -R -d alsa -d hw:0 -r 48000 -p 512 -n 1
[snip]
hw:0|hw:0|512|1|48000|0|0|nomon|swmeter|rt|32bit
control device hw:0
configuring for 48000Hz, period = 512 frames, buffer = 1 periods
Couldn't open hw:0 for 32bit samples trying 24bit instead
Couldn't open hw:0 for 24bit samples trying 16bit instead
ALSA: cannot set number of periods to 1 for capture
Very few cards/drivers support using only one buffer. If I understand things
correctly it means that whenever the buffer runs empty the program has to
rewrite the buffer _before_ the soundcard needs another single sample. Which
is a _very_ short time.
In practice this setup is unusable.
ALSA: cannot configure capture channel
cannot load driver module alsa
$
The same it is if I set number of periods higher than two (and that's
strange, can be a configuration issue?)
I routinely run with two buffers so it was a while since I tried...it should
work though...
- Is it an hardware/driver limit, can't I reach
the same latency that I
have with timidity with jack?
- Is it normal having 16 bit samples with my card?
I suppose. The original audigy was marketeded as a 24bit card in the
beginning, but I think they where forced to stop. I don't recall the
reasons... probably because it was really a marketing ploy...still a 16bit
card.
The last but not least, I have a general question about jack: if I a
stream pass twice or more times into jack (for example alsa in -> jack
rack -> ardour -> alsa out, 3 times) does the latency increases twice or
more, proportionally, or it is only related to the various apps latency?
Somebody more knowledgeable than me should answer that :)
Ok, I stop to bother anymore you with my (maybe stupid) doubts...
Not stupid at all. I hope my answers where correct and satisfactory.
Thanks for the attention, every answer will be greatly apprecciated.
Ciao, Antonio
/Robert