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
