3 Feb
2004
3 Feb
'04
9:22 p.m.
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?) which means a pretty low latency for me.
On the other side I can run jack (jackstart works fine) with a period
not less than 512, 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
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?)
- 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?
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?
Ok, I stop to bother anymore you with my (maybe stupid) doubts...
Thanks for the attention, every answer will be greatly apprecciated.
Ciao, Antonio
4 Feb
4 Feb
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
7:25 a.m.
Robert Jonsson wrote:
[snip]
I've done the question because I noticed that jamin increase the latency
much more then other apps (like ardour or jack-rack). For example the
with the setup:
midi -> ZynAddSubFX -> jack-rack -> ardour -> alsa out
(5.3 ms)
I have no (at least easily) audible delay when I play (using 2 periods
of 512 frames), while with:
midi -> ZynAddSubFX -> jamin -> alsa out
I have a strong delay of (I estimate) about 0.1 ~ 0.2 secs, which means
no realtime response. So I understand that I don't understand something
about how jack works :-)
Anyway, there is a way to mesure the global in-out latency? (I've tried
the Benno's latency test, it does the benchmark but does not produce any
png result, and I think is only a kernel-related test)
[snip]
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.
You are right! Forcing jack to open alsa in plaback only mode I can set
a period 256 frames with 2 periods of buffer. I play via midi so I don't
need the capture the most of times. So playng with ZynAddSubFX I can
get a latency of 10 ms! This isn't just a "pretty low latency" but a
_very_ low latency for me :-). Thanks.
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.
But it's a sad closed (I think almost) personal project. Personally I
apprecciate a lot those ideas about drivers policy:
http://www.gnu.org/brave-gnu-world/issue-51.en.html
don't you?
[snip]
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.
ok, I understand
[snip]
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 :) Not stupid at all. I hope my answers where correct and
satisfactory.
Fully satisfactory, you fullfilled all (well quite all ;) my doubts in
one time! Thanks a lot.
/Robert
Antonio
7:37 a.m.
On Wed, Feb 04, 2004 at 12:24:48 +0100, Antonio wrote:
I've done the question because I noticed that
jamin increase the latency
much more then other apps (like ardour or jack-rack). For example the
with the setup:
midi -> ZynAddSubFX -> jack-rack -> ardour -> alsa out
(5.3 ms)
I have no (at least easily) audible delay when I play (using 2 periods
of 512 frames), while with:
midi -> ZynAddSubFX -> jamin -> alsa out
Thats because the processing in jamin is high latency - jack itsself
doesnt add any latency, no matter how many apps you connect.
Well, actually thats not true - it will add latency if you have a jack
feedback loop, but only 1 buffers worth. With trees and chains you dont
get any additional lantecy over what the app adds.
- Steve
3:17 p.m.
Steve Harris wrote:
[cut]
# Thats because the processing in jamin is high latency - jack itsself
# doesnt add any latency, no matter how many apps you connect.
#
# Well, actually thats not true - it will add latency if you have a jack
# feedback loop, but only 1 buffers worth. With trees and chains you dont
# get any additional lantecy over what the app adds.
So if I understand, we have the alsa input latency plus the latency of
each app that elaborate the audio stream, while jack doesnt introduce
any latency (unless there is a loop).
Is there also an additional latency for the alsa out?
If not, playng via midi, I have only the soft-synth related latency (it
seems strange to me)?
Thanks for the answer (and much more the software too ;-)
Antonio
3:33 p.m.
On Wed, Feb 04, 2004 at 08:16:20 +0100, Antonio wrote:
Steve Harris wrote:
[cut]
# Thats because the processing in jamin is high latency - jack itsself
# doesnt add any latency, no matter how many apps you connect.
#
# Well, actually thats not true - it will add latency if you have a jack
# feedback loop, but only 1 buffers worth. With trees and chains you dont
# get any additional lantecy over what the app adds.
So if I understand, we have the alsa input latency plus the latency of
each app that elaborate the audio stream, while jack doesnt introduce
any latency (unless there is a loop).
Yes.
Is there also an additional latency for the alsa out?
If not, playng via midi, I have only the soft-synth related latency (it
seems strange to me)?
Yes, there is both a delay in alsa copying data to the card (up to 2x
buffer size, IIUC), and in the card doing its DA conversion. The DA
conversion will take something like 2ms.
- Steve
7600
days inactive
7601
days old
linux-audio-user@lists.linuxaudio.org
5 comments
3 participants
participants (3)
-
Antonio -
Robert Jonsson -
Steve Harris