Dnia 2008-11-09, o godz. 11:03:06 Fernando Lopez-Lezcano <nando@xxxxxxxxxxxxxxxxxx> napisał(a): > On Sun, 2008-11-09 at 14:40 +0100, Leszek Matok wrote: > If disconnecting means "unplugging" it from sources/sinks in qjackctl > then no jack application should notice (not even as an error or warning > - it is _not_ an error). In my Planet CCRMA packaged version nothing > happens if I connect or disconnect ports from rakarrack. I call this "connecting" and "disconnecting" because qjackctl uses this convention. Connecting/disconnecting when "FX on" can make rakarrack die yelling: cannot complete execution of the processing graph (Resource temporarily unavailable) zombified - calling shutdown handler rakarrack: xcb_lock.c:77: _XGetXCBBuffer: Assertion `((int) ((xcb_req) - (dpy->request)) >= 0)' failed. cannot read event response from client [rakarrack] (Connection reset by peer) bad status for client event handling (type = 5) Abort I've noticed that in such situations, after rakarrack quiets down (which, depending on an effect, can take few seconds), there are many jackd errors like: subgraph starting at qjackctl timed out (subgraph_wait_fd=12, status = 0, state = Running) and: **** alsa_pcm: xrun of at least 1226244972609.536 msecs (check out the number of msecs, this is BS and there are no xruns when it's actualy playing sound) Maybe I'm triggering some jackd bugs somehow and they propagate to rakarrack which doesn't expect talking to buggy server? :) > My personal take on this is that jack applications should not connect by > themselves to anything unless you tell them to do so. Having a default connection that I myself configure in application's GUI is different from application doing things by itself. Cheers, Lam
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Fedora-music-list mailing list Fedora-music-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-music-list
