[linux-audio-dev] mux concept paper

mimo mimo at restoel.net
Thu Feb 17 14:00:24 UTC 2005

Paul Davis wrote:
>>complaining. But my experiences with jack are negative. First time I 
>>started looking at it I had huge expectations after all that I had read. 
>>  First problems, after a couple of second of running without any 
>>actual processing going on, strange noise artefacts kind of getting 
>>worse. I had a look at source code and realise that it bases its time 
>>calculation on cpu MHz in /proc/cpuinfo. I dont know about your machine, 
>>but on my machine(s) a) this is a float and b) it's slightly different 
>>every time I boot the machine.
> this has nothing to do with your noise. JACK uses CPU Hz to provide a
> UST value. i am puzzled by the fact you are the 2nd person to think
> that JACK's timing is somehow based on system timers and so
> forth. JACK (in regular mode, using one of the normal backends) is
> driven 100% by the interrupt from your audio interface. whether or not
> the CPU Hz value is correct has (effectively) zero impact on audio
> generation and timing.

Just out of interest, if it is dependent on the audio hardware, why do I 
get the same problems with different sounds cards on the same machine, 
and a colleague gets them with completely different hardware all the 
same. Any ideas what might be the reason? Anyone else with the same 

>>The other thing I dont understand about jack is the whole graph 
>>business. E.g. I look at the artsd in kde and plugin an effect and this 
>>is seamless, no stopping of audio. In jack, it says "recalculating 
>>graph" and get a cup of coffee :)
> good grief. that's a ludicrous comment. it takes fractions of a
> millisecond to recompute the graph.
> and yes, artsd doesn't break the audio chain because it isn't built
> around low latency - stefan has acknowledged that. there is a new
> implementation of jack for osx that also doesn't break audio
> processing during graph reorders - it uses lock free techniques. but
> guess what - it has one process-cycle worth of extra latency as a
> result. 
> so, as they say in the UK: you pays your money and you makes your
> choice. you can have absolute minimal latency, but that requires
> locking the graph against use when it is reordered.
>>Ok, enough ranting... sorry didnt want to discuss jack really.
> well, you can't go around making ill-informed comments about someone
> else's software and not expect a discussion. 

Sure, point taken.

> that being said, JACK is *not* appropriate as a replacement for the
> engine in something like Buzz. JACK does not scale well much beyond,
> well, it depends on your machine, but in general terms, on the order
> of 5-10 clients. This isn't a defect - its a reflection of what it
> designed to do. 

Good to know, so I misread the jack spec in the first place because I 
was expecting it to do what I wanted to do -- the many machines processor.

> but IMHO, you should be looking at Beast or gAlan or ALSA Modular
> Synth, or SSM or ... not starting from scratch.

One thing, I dont want to start completely from scratch. At least I'm 
going to nick some lines of code from someone elses project :)


Please note that this account is being filtered using anti UCE systems. 
If you send email to this account make sure that it could not be 
mistaken as UCE.

More information about the Linux-audio-dev mailing list