[ardour-users] Re: ardour-users-ardour.org Digest, Vol 14, Issue 22

[Kjetil Svalastog Matheussen]

Esben Stien:
> 
> Geoff Beasley <songshop at bizmedia.com.au> writes:
> 
> > I get no x-runs at all (except when quitting programs) [..] Maybe
> > some FC1 issues here ?
> 
> This is a design issue. For jack to not cause xruns when connecting
> and disconnecting clients, it will have to be rewritten. 

I am quite sure this is not correct. You do get a click when connecting
or disconnecting, but no xrun. An xrun is when the software, for some
reason, is unable to provide a continous data stream to the hardware.
When disconnecting and connecting, the stream to the hardware is still
maintained, but its a controlled feed of zeros.

I think so, at least, its certainly not a traditional xrun.


> Stephane Letz
> did a c++ rewrite which is able to do this at the cost of an
> additional process cycle.

No, this is not true!
The additional process cycle is there for another reason, and 
can be turned off. Stephane Letz promptly corrected, on some mailing-list,
the person that posted that claim. Please don't
further spread that misunderstanding. ;-)



> I'd sure want this feature, since I do a lot
> of jacking (no pun intended). It's super numerary the possibilities
> when having jack work this way and I'll certainly vote for it.

Me too. It seems like most people agree that this needs to be fixed.
However, jack 1.0 needs to be released first.


> A quick
> practical example is making jack instructional videos where you have
> to jack in and out several clients. It would be bad if you made a
> video with a click every time you connected a client;).
> 

Yes.


> For the current jack implementation to do this without clicks, you
> would need two processors on your motherboard, SMP.
> 

Certainly not. What you need is some sort of message queue between the
non-realtime and the realtime thread, so that instructions for  
connecting and disconnecting is sent to the realtime thread 
instead from the non-realtime thread.

You don't need more than one processor for this.

Whats happening now, is that to connecting and disconnect, you first have
to stop the realtime thread, then do the connecting/disconnecting, then 
start the realtime thread again.
 


--