[LAU] question about jackdmp's ability to detect its soundcard has disconnected

Ivica Bukvic ico at vt.edu
Mon Oct 29 16:34:38 UTC 2012


Could this be the difference between 1.9.8 and git version?
On Oct 29, 2012 12:10 PM, "Robin Gareus" <robin at gareus.org> wrote:

> On 10/29/2012 03:55 PM, Ivica Ico Bukvic wrote:
> > All,
> >
> > I noticed since upgrading to Ubuntu 12.04 that the default Jack server is
> > jackdmp (v.1.9.8). Please correct me if I am wrong but my understanding
> this
> > is the smp-enabled version 2 that is being developed in parallel with 1.x
> > series of regular jack.
>
> correct. They are also API and ABI compatible.
>
> > Either way, one of my concerns is that while in the old jack when one
> > accidentally pulled the soundcard jack was trying to talk to (e.g. a USB
> > soundcard), the jack would gracefully stop.
>
> In my experience it stopped but never gracefully (ie it crashed). but
> it's been a while since I used jack1.
>
> > The new version (and this could
> > be Ubuntu quirk) instead of stopping is pegged in some kind of a spinlock
> > that often times locks up the machine (this may be in part since I am
> > running a lowlatency kernel with audio group given priority) and at times
> > keeps it operational while hogging the cpu and making the computer barely
> > responsive until jackd is killed. Apps connected to jack that I tested so
> > far are also stuck in a loop waiting for a response from jack (although
> this
> > could be the app's shortcoming)--jack never broadcasts a signal that it
> has
> > lost the soundcard (AFAICT). FWIW I am running jackdmp through
> qjackctl...
> > Any thoughts on this matter would be most appreciated.
> >
>
> I can't reproduce this. jack2 stops the backend when the device is
> disconnected. You can switch to a new backend using jack_control
> (sending some Dbus messages to jackd) without re-starting jackd. No CPU
> hogging here. - I'm running jack2 - aka 1.9.9.4 from git.
>
> robin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20121029/d7449de0/attachment.html>


More information about the Linux-audio-user mailing list