On Sun, December 30, 2012 6:22 am, Ben Bell wrote:
> On Sat, Dec 29, 2012 at 01:28:47PM -0500, drew Roberts wrote:
That seems pretty good actually. Using pulseaudio for the same job pretty
much triples the cpu load. That is, if jack is using 10% on it's own,
bridging pulse to jack raises CPU to about 28%. (over using pulse and jack
separately, don't bother ranting about pulse please, I am NOT suggesting
it's use in this case... or any other, just relating my experience) If you
think about it at all though, connected or not, each port/channel needs to
be fed silence at 48k all the time. Jack needs alsa-in to run at the same
latency as jack is too.
In my mind, the problem is that jack only deals with one device. Jack is
for pro or semmipro IFs which do have the possibility of sync. This seems
to be a common use so Jack _should_ handle it. It would seem that if jack
was aware there were two devices it would initialize both correctly when
it started rather than initializing one and hoping the other followed.
Certainly the user would then be able to tell jack which of two devices
was the master (for example) which _should_ be able to make a more stable
system. Maybe there are other problems that I am not aware of that keeps
this from being a reality as audio signal coding is not something I have
dealt with... or maybe in jackd3?
Really, Jackd is a great tool that just works for me. I am glad we have it.
BTW one more thing with the "multi" setup from before. If you are using
the setup from J Rigg's page. hw0 should be the clock master, I think. If
hw1 is the clock master then the:
(and similar section in capture) should reflect that, would be my guess.
Linux-audio-user mailing list