Getting Less Crashes in Radium

[brandflake11]

Ooooohhhh, maybe it's because I am using jack 0.125.0-9. Shoot, I forgot arch defaults to giving you jack instead of jack2 in its pro-audio group.

I replaced jack with jack2, and surprise, surprise, I can load multiple redux plugins in radium now! This makes me extremely happy! (I have been running jack1 for the whole week, and didn't even notice!)

Kjetil, I have to say, thank you. Your help has been so awesome.

[kjetil]

Can you run

Code: Select all

gstack `pidof radium_linux.bin`

too? Maybe the audio thread is displayed then.

[kjetil]

Ooooohhhh, maybe it's because I am using jack 0.125.0-9. Shoot, I forgot arch defaults to giving you jack instead of jack2 in its pro-audio group.

I replaced jack with jack2, and surprise, surprise, I can load multiple redux plugins in radium now! This makes me extremely happy! (I have been running jack1 for the whole week, and didn't even notice!)

Kjetil, I have to say, thank you. Your help has been so awesome.

That's good news. It should work with jack 1 though, but I'll probably show a warning if the user is running Jack 1.

[brandflake11]

Can you run

Code: Select all

gstack `pidof radium_linux.bin`

too? Maybe the audio thread is displayed then.

Do you want me to run this with jack 1, or is jack2 okay?

EDIT: I know this might sound crazy, but it even seems Radium stops and starts faster in playback too with jack2 (maybe this is in my head)

[kjetil]

Can you run

Code: Select all

gstack `pidof radium_linux.bin`

too? Maybe the audio thread is displayed then.

Do you want me to run this with jack 1, or is jack2 okay?

EDIT: I know this might sound crazy, but it even seems Radium stops and starts faster in playback too with jack2 (maybe this is in my head)

No, it's fine. I'm pretty confident that the freeze was caused by Jack 1 killing the Radium client because it spent too much time. I think jack 1 does that sort of thing unfortunately. This again caused a deadlock since the main thread was waiting indefinitely for the audio thread to finish. I also guess that Redux spends a little bit time in the audio thread in the first cycle when two instances are running, for some reason, and that's why Jack 1 killed the audio thread.

Anyway, I'll definitely show a warning if Jack 1 is running instead of Jack 2. Thanks for the help!

[brandflake11]

If you come to find that you need it later, just send me a message. It is trivial to reinstall jack for me.

[teteros]

No, it's fine. I'm pretty confident that the freeze was caused by Jack 1 killing the Radium client because it spent too much time. I think jack 1 does that sort of thing unfortunately.

Even the official docs mention this might happen in jack1 as it's single-threaded

Jack 2 is more forgiving of misbehaving audio apps, whereas Jack 1 is not very tolerant (zombifying the client). (This behavior can be configured for both, but this is the default behavior.)

I wonder if you tried tweaking these two options on jack1, if you'd have a different result:

Code: Select all

-Z, --nozombies
       Prevent JACK from ever kicking out  clients  because  they  were  too  slow.
       This cancels the effect any specified timeout value.

-C, --timeout-thres time
       Stop  processing  clients  if  JACK  cannot  complete  the  process  cycle  in time
       (typically caused by CPU overloading or  misbehaved  clients).  The  optional  time
       argument  specifies  the  number  of miliseconds, during which consectutive process
       cycles must fail before JACK gives up (if the argument is not given, it defaults to
       250).  Processing  will resume on the next change to the port graph (i.e. a port is
       added, removed, connected or disconnected)

I know this might sound crazy, but it even seems Radium stops and starts faster in playback too with jack2 (maybe this is in my head)

jack2 is multi-threaded unlike jack1, new plugins use seperate threads IIRC, at cost of more memory usage so this isn't that surprising if that might be the case. Of course there's also the possibility your jack2 server ran at a lower buffer or different scheduling priority etc.

Anyway, I'll definitely show a warning if Jack 1 is running instead of Jack 2. Thanks for the help!

I'll put a hard dependency on jack2 for the AUR package as well in next release, like brandflake11 said, jack1 and jack2 packages are interchangeable on Arch distros unless you're explicitly depending on jack2.