Stereo Tool

Some things (Jack among others) are a bit in flux at the moment and might be unstable, but aside from that I'm not aware of any issues. If you do get crashes and it's not with Jack (052 did have some stability issues that were solved in 053), it might be a settings problem - we've seen that before with the Linux builds. So in that case:
- Which exact binary are you running?
- Please rename the .rc file to something else, then check if it still crashes. If not, it must have been a settings issue - please send me the old .rc file in that case.

Ugh. I have a version with Jack/non-Jack combined now, but if Jack is opened (which is needed to fetch the names of the input and output channels) it seems to block access to some of the other sound cards, causing sound card errors and hangups when trying to access them. So I'll need to change the behavior to only open Jack if it's explicitly requested.

It probably opens jackd too early, i think that's what i meant in that last screenshot. Try to check vice versa as well when only jack is used to turn off the alsa ports, some systems have either the loopback driver enabled (modprobe snd-aloop) or hooks in some programs and can become weird.

Can you add a null input to jack?

What do you mean by a null input? About the opening, I'm now opening Jack after ALSA and now I at least see all the ALSA ports. It could be that there's a bug in the Linux version that I'm using for testing Ubuntu 16.04, so it's 7 years old - I'm using that version to avoid GLIBC errors between versions).

On this system, I'm getting serious issues as soon as I start to use non-Jack sound cards. It's so bad that I'm considering completely disabling the ALSA inputs and outputs, but if this is only an issue on my system I shouldn't do that.

To verify: The issues that you saw, were you at any time using ALSA inputs/outputs? Because if you did, that might explain things.

Anyway, I want more feedback first - if this problem only affects my test system it doesn't matter. I'll run a new build tonight.

I've spent most of the day on making it possible to update the Jack input/output lists after restarting, I'm running into some issues so I'm not going to enable that in the beta yet. But it should be possible to support that, later. If it works, I can also decide whether to load Jack after starting instead of at startup - that would really help to work around any conflicts between Jack and ALSA.

The new version that I'll post tonight will always load Jack, so if that does cause issues for anyone we'll know pretty soon...

Path to seg fault on my freshly installed Ubnutu Desktop 22.04:

Download latest beta (52)
Right-click > Properties > Permissions > Allow executing file as program

Attempt1

1. Double click to load from GUI
2. [stereo tool GUI loads]
3. Enable webserver
4. >>> CRASH

Attempt2

1. sudo ./Downloads/stereo_tool_gui_64_BETA1002-052
2. [stereo tool GUI loads]
3. Enable webserver
4. [Warning Message about white list, GUI shows enabled]
5. Webserver does not respond on default port on localhost, I do not see any evidence that the webserver is running (using ss command). But program does not crash. Changing port or whitelist has no discernable effect.
6. Quit GUI
7. sudo ./Downloads/stereo_tool_gui_64_BETA1002-052
8. segmentation fault

I do not see a .rc file. There is a hidden preset directory up one level in my users directory. Playing with the Enterprise version does result in a .rc file there. Enterprise appears to have the same basic problems, but I wasn't as careful documenting my steps.

If I don't use sudo I get this error "Warning: Cannot set realtime priority, run with sudo for realtime control." So I assume sudo is the way. What is the right way to handle this for production?

@coxwal: That first one reproduces! Great, now I can investigate what's happening.

Edit: Oops! This broke quite a while ago. Maybe even before the previous release. In some cases, it tries to set a CPU affinity on a non-existing thread (in some versions). And that was a thread in the web server. I have added an assert, that way I will always get notified if this fails, not just on Linux but also on Windows and Mac.

I have posted BETA054. We now have combined ALSA/Jack build for Linux, please let me know if this version works! On my end it's not working well, so I might need to split it up again, unfortunately. It would be nice to be able to combine Jack with ALSA, and also to have fewer different binaries.

(No ARM binaries unfortunately, the network connection in our office acted up last night, which stopped the ARM builds).

Did some Googling (and asked ChatGPT) about Jack vs ALSA, and it looks like using both at the same time is at the very least problematic. Jack claims the ALSA device, making it inaccessible. (Other ALSA devices might still be usable at that point, but if you attempt to use the ALSA device that Jack uses, everything locks up completely - that's not something I want to support without a user explicitly choosing that). So the next best solution is to have a selection between ALSA and Jack - still using a single binary.

That's what the next build will do. For now, instead of making it selectable on the fly, I've made something that checks the file name - if it contains "jack" you get the Jack version, otherwise ALSA. So at least from our perspective it's a single binary now.

Just tried 054 and for me the Jack and ALSA outputs are working correctly together if on a different device, they don't longer deduplicate too! i'm able to capture ALSA and output Jack and vice versa.

I'm sure that a filtering/checking system can solve the conflicts of ALSA device being occupied when the native jackd tries to hook into it, probably it works correctly for me thanks to PipeWire. i'll try and check these days on a different system where i'll make a native jackd server and report back.

/////
Sample rate will still refuse to go above 48, but now it fails silently rather than try fallback 44,1 and crash.
Everything else works good.

/////
When Stereo Tool is used as a sink i connect it's inputs to an unused output like _fm (i think it does that by default even when there's no other source). It's apparently fine, but I asked because i'm thinking it might help a potential conflict when testing.

And yeah GLIBC is a pain for proprietary programs, luckily i had no such issue with Stereo Tool (it even works in musl distros like Alpine with the gcompat package), goes to show the great coding sir!
This got solved in 054, check above. My eastern european English is a bit rough around the corners, my excuses for that

Ok! Please let me know. For now, 055 will have either ALSA or Jack, not both. But it's just a single line in the code to turn that on or off.

Most important question: What happens on your system if you do select an ALSA device that's used in Jack? On my (16.04) test system, Stereo Tool basically does nothing for about 1 minute before it shown an error message - the sound card call appears to block for that long. And that makes it really hard to use.

If that doesn't happen on newer systems anymore, then I can enable both at the same time again - that would be the ideal solution. But only if it doesn't cause the aforementioned blocking.


About the order of opening things: If I open Jack first and then check ALSA, some sound cards (the ones that Jack uses, I assume) are not listed anymore. (But some duplicates of those still are, and those are the ones that cause long hangups when I select them). If I open ALSA first, and then Jack, then all the sound cards are visible in both, but if I try to open the ones that are used in Jack that fails immediately.


About the sample rate issue: Which sample rate is displayed in Stereo Tool when you select a higher one in Jack? For example if you select 88.2, does it show 88.2, or 44.1, or even 48? I have seen it work at 192 on my pc, but that was in Windows (with Jack for Windows - yes, that's a thing!).