Thanks Paul, I just observed that the behavior became more hindering over the last weeks and was wondering about possible reasons. I am trying to avoid pipewire to keep the overall complexity of my audio system low, but thanks for the recommendation. Will try other USB cards next. Such a pity, these Edirol UA-25 are great cards, all controls available as hardware switches, USB class compliant and very cheap on the 2nd hand market. Using them since 10+ years now. Thanks again, Peter * Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> [2025-01-20 19:21]: > I would be surprised if this has ever worked with any degree of > reliability. ALSA has long had lots of issues with suspend/resume, some > significant, some insignificant. And JACK1 in particular has no support for > suspend/resume at all - it just looks like a weird hardware condition that > it probably cannot recover from. It has no idea that a suspend/resume has > happened, which is really required to recover properly. > > Pipewire's JACK implementation likely does much better. > > On Mon, Jan 20, 2025 at 10:11 AM Peter P. <peterparker@xxxxxxxxxxxx> wrote: > > > Hi list, > > > > Since a while (recent kernel or other package upgrades?) I am > > experiencing serious problems with jackd after resuming from suspend. > > > > Eg. trying to play back audio files via mpv yields > > mpv somefile.flac (+) Audio --aid=1 (flac 2ch 44100Hz) > > Cannot read socket fd = 13 err = Success > > CheckRes error > > JackSocketClientChannel read fail > > Cannot open mpv client > > JackShmReadWritePtr1::~JackShmReadWritePtr1 - Init not done for -1, > > skipping unlock > > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping > > unlock > > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping > > unlock > > > > At which point the command hangs. The card used is an Edirol UA-25 > > connected via usb. > > > > I can quit the hanging mpv with Ctl-c, upon another invocation the error > > persisits but mpv gracefully attempts alsa this time. > > > > Qjackctl, which was used to start jackd in the first hand place, is > > unresponsive as well. I for now kill jackd as root three times to regain > > control over it after every resume. > > > > How can I go about to debug this further? > > > > The above problem is with jackd2. Switching to jackd1 will show a > > slightly different problem upon resume: Using 100% CPU and being > > unresponsive either. I posted about this in jan/feb 2024 > > > > By the way: I can't search in the mailing list archives as the search > > engine on linuxaudio.org throws a lot of "502 bad gateway" or "504 > > Gateway Time-out" errors at least for lac and jackd lists: > > > > https://lists.linuxaudio.org/hyperkitty/search?mlist=linux-audio-user%40lists.linuxaudio.org&q=resume > > > > Thanks! > > Peter > > _______________________________________________ > > Linux-audio-user mailing list -- linux-audio-user@xxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to > > linux-audio-user-leave@xxxxxxxxxxxxxxxxxxxx > > _______________________________________________ Linux-audio-user mailing list -- linux-audio-user@xxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to linux-audio-user-leave@xxxxxxxxxxxxxxxxxxxx
