[linux-audio-user] emu10k1 and jack

Robert Jonsson robert.jonsson at dataductus.se
Wed Feb 4 02:31:42 EST 2004

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 

> 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


More information about the linux-audio-user mailing list