On Sun, December 30, 2012 6:22 am, Ben Bell wrote:
> On Sat, Dec 29, 2012 at 01:28:47PM -0500, drew Roberts wrote:
>>> Having recently acquired a second Delta 1010 for my setup I've been
>>> trying
>>> to run the two in tandem using the alsa Multi hack. I'm getting the
>>> xruns
>> Have you tried using one via jack and the other one via an alsa<->jack
>> bridge
>> and then sync the two via the wordclock?
>
> OK, well I've tried this morning and the news on this is mixed. Sitting
> idle,
> and clocked from S/PDIF everything works fine with alsa_in.
>
> Running with a more modest session hovering at 30% normally, pulling the
> alsa_in channels (just into jack -- no connections) raises the CPU to ~55%
> but there are no xruns.
>
> So it seems that the problem is most likely in the alsa multi plugin. As
> an
> aside I'm surprised at the extent of resource usage caused by simply
> having
> alsa_in running. Normal, or suspicious? jack_netsource doesn't cause this
> sort of load, and tweaking sample rate and the like doesn't seem to affect
> things. A side-effect of it expecting to need to resample everything?
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:
ctl.playback24 {
type hw
card 0
}
(and similar section in capture) should reflect that, would be my guess.
--
Len Ovens
www.OvenWerks.net
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
