[linux-audio-dev] jack.udp issues

Robert Jonsson rj at spamatica.se
Mon Mar 21 19:48:06 UTC 2005

Hi Antonio,

On Monday 21 Mar 2005 05:48, Antonio "Willy" Malara wrote:
> jack.udp for me means many underrun in this configuration:
> x86 pc
> jackd -d alsa -d hw:0
> jack.udp recv
>      ^
>      |  (FastEthernet network (100mbps))
> powerpc pc
> jackd -d dummy
> jack.udp -r IP send
> the first thing that came in my mind was some network troubles like
> mtu.. further investigation (like involving two x86 hosts, or working
> directly without the switch, working with 802.11b networks...) made me
> think that jack.udp uses the audiocard driver for some kind of timing.
> now, i've some troubles running an audiocard with jack in the powerpc
> (my main computer) there is a way to make this system usable with dummy
> driver? i've noticed that this dummy driver has a "delay in microsecs"
> parameter, now i think if i can calculate the right number the problem
> will fade away, but i dont know how to do the math :(
> some one has an idea on this? or has solved a similar trouble?

I have no real answers but as I've been thinking about using jack.udp (in 
exactly this setup) in a while I realize I'm up for the same problems.

I think Jack uses the sound card as timing source and that is the pipe that 
all other apps have to dance to.
With two different computers with two different jack instances, both operating 
with this precondition, I can't see how it can possibly work... Is anyone 
successfully using two jack instances like this?

One use case I've been thinking about myself is offloading for example 
linuxsampler and brutefir (or the other IR reverb wosname) to a second 
computer. In case of the reverb I'd like to send data both ways.

Would it be possible to change something in jack to allow one of the instances 
to "slave" from the other? 

Interesting stuff, thanks for the heads up!


> another question out of this trouble: someone knows how to raise the IRQ
> priority of the USB controller to an usable value? possibly not
> involving the use of the realtime patch, inusable on ppc-powermac,
> thanks for attention and eventual replies, and keep the good work on
> this audio software :)
> willy


More information about the Linux-audio-dev mailing list