[linux-audio-dev] mux concept paper

[mimo]

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 
experiences?


> 
>>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 :)

mimo

-- 
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.