Quote:
@Hitman: I can confirm that I have an issue with setting Jack > 48 kHz on my Linux system (on Windows it works fine, so it cannot really be something in our code). I just went back to an older version (9.92 release) it does the same thing, so I think this is a Jack issue, not a Stereo Tool issue. Can you check if you also have the same issue with older versions? In both cases, the jackd-logging states that it's running at those higher sample rates.
I have not yet checked what it does with a HifiBerry, the older version definitely did run at 192 but I have to change some cables here to verify that it still does - it does handle any other frequencies so I don't expect it to be any different.
I got now to check it sir and indeed it's a problem with recent versions of Jack/related libraries. I tried with a 2 year old distro that has (native) jack and both 9.92 and 10.01b work at 96/192khz, with sound good and everything. So yeah that's what you get for using too up to date distros, hehe.
The fallback when killing the jack server is still finnicky, as in ST still freezes showing 44/48, but upon restarting the jack server the ST instance unfreezes and shows again 96/192, working fine. It seems that i was only half right in my initial report, sorry about that.
I tried to check the alsa+jack combined version 0.54 but is not on the server, 0.51 and 0.56 only seem to list jack as available, they do connect right away when selecting so that's not the problem with them.
Can you make the build recognize a new filename flag of "_alsa+jack" or something like that, so that both can work together again like 0.54 did? I'd try that with the bugfixes after that version.