Windows: Unable to configure ASIO device (major bug)

[pgScorpio]

Describe the bug

If (a new) ASIO device is added to the system which is not yet configured correctly and this device is selected in Jamulus Jamulus will show an error message and revert to the previous device. This makes it impossible to access the ASIO settings of the new device, so you can't set the correct settings. To Reproduce

Install a ASIO device (Like Focusrite 2i2) and configure it for Jamulus and make Shure it works in Jamulus. Now install a new ASIO4ALL Beta version (which has no offline settings). Now try to use ASIO4ALL in Jamulus. Most likely you will get the error message. Jamulus will revert to the previous driver and you won't be able to configure ASIO4ALL. (Same goes for a lot of other ASIO drivers where i.e. the sample rate is set in the drivers ASIO config.)

Expected behavior

Jamulus should NEVER change any device and/or in-/output settings on it's own! Just show an error message and let the user solve the problem or revert to the other driver.

Screenshots

Operating system

Windows10, any version.

Version of Jamulus

v3.8.1

Additional context

Same problem occurs when a user forgets to plug in (or accidentally unplugs) their interface or USB device. You get an error and Jamulus changes settings, So after plugging in the device and restarting Jamulus it still doesn't work since Jamulus changed the device settings. (very annoying and confusing for a lot of users)

[ann0see]

Yes, I think this issue (better the whole set of related issues) is known (and we already tried to fix it with https://github.com/jamulussoftware/jamulus/pull/1378 https://github.com/jamulussoftware/jamulus/pull/2168#discussion_r770950691). I think we'd need someone knowing the windows audio flow in depth to fix this bug. In the meantime, I think the only way to fix this bug is to fiddle with config files...

[pgScorpio]

I think the only way to fix this bug is to fiddle with config files...

Fiddling with config files doesn't even work either in this case. You will have to uninstall all working ASIO devices to get to the configuration of the non working device! Also you can't expect the average Jamulus user to start fiddling with ini files and registry settings.

Jamulus just should NEVER change any device selection or in-/output selections automatically. What a user has selected stays selected until the user changes it himself. That solves the problem and makes everything simple and clear.

[ann0see]

The thing is that the whole code seems to be written in such a way that it always needs a working device. I doubt it just adding a few lines of code to fix that

[pgScorpio]

The thing is that the whole code seems to be written in such a way that it always needs a working device.

AFAIK that is only the case when connected to a server, so as long as the settings are incorrect just show an error when trying to connect.

I doubt it just adding a few lines of code to fix that

Probably more lines to delete than to add ;=)

[ann0see]

https://github.com/jamulussoftware/jamulus/issues/1338 you should know the issue I raised some time ago ;-). What can we do to actually move this forward? Especially move forward @npostavs PR which has the potential to fix multiple bugs at once?

[gilgongo]

Can we regard this as a duplicate?

[pgScorpio]

Can we regard this as a duplicate?

I think it's not a duplicate but just another addition to the same category of problems. (and this one can be fatal) and "Jamulus should NEVER change any device and/or in-/output settings" is more an overarching issue. Add "Jamulus crashing when changing ASIO settings while connected" to it and I guess we have all ASIO configuration issues covered.

[pgScorpio]

What can we do to actually move this forward?

Are you asking me? I would love to dig into the code myself, if I just had the time to do it.... (I haven't even got time to set up a working build environment ;-) )

[npostavs]

What can we do to actually move this forward?

I believe my PR fixes this exact problem, but it currently doesn't work on macOS. Oh, and I see it's got some conflicts again, I better go update it.

[ann0see]

@pgScorpio can you test the PR by @npostavs?

[pgScorpio]

@ann0see @npostavs Is there still a test version available? (The only one I can find is expired)

[ann0see]

This one should work: https://github.com/jamulussoftware/jamulus/actions/runs/1700022274 (but not on macOS)

[pgScorpio]

OK. I did a quick check and indeed it doesn't change device, but pressing the "ASIO Device settings" button does NOT open the ASIO settings either.... So still no way to correct the problem. Also after "Auto Select device" and then changing back to the faulty device the settings window still shows the previous drivers channel mapping.

P.S. To quickly check a faulty device I use the KoordASIO driver with a mono input device selected.

P.S.2 Why Jamulus does not accept a mono input seems a bit strange to me too, since with more than 2 inputs (also strange why not with 2 inputs) I can select the same input for both channels.

[ann0see]

Ok. So there are other bugs left... can you please report them in the PR?

Why Jamulus does not accept a mono input seems a bit strange to me too, since with more than 2 inputs (also strange why not with 2 inputs) I can select the same input for both channels.

Not sure about that. But there are various strange design decisions everywhere (which peter currently improves; I think many people don't want to touch the audio part since it's basically the heart of Jamulus)

[pgScorpio]

can you please report them in the PR?

Done.

But there are various strange design decisions everywhere

I totally agree ;=)

[pgScorpio]

@ann0see Do you know hat is the status of this bug? As I see it is not yet solved in Release 3.8.2beta1

I (and several people I know) would really love to see this bug solved in the next official release, together with the channel selection problem as also discussed in this discussion

[ann0see]

Status of this bug: Priority exists, but nobody is currently working on it.

Reason:

1. Fear of changing core code (the whole design of the audio processing is far from ideally designed). Currently it at least works so so. Changing might introduce new serious bugs
2. These bugs do exist: the mentioned PR which does have a lot fixed results in a unusable macOS version. We can not release this
3. We’re lacking someone diving into the audio code. I don’t think anyone of the main contributors has deeply analysed the audio code.
4. There is no plan on what to change (maybe you can help us making one and finding someone who works on it?)

Thr next actions would be to

1. rebase the PR by @npostavs
2. Debug audio on macOS

For 2 we need someone with macOS knowledge. Currently emlynmac, npostavs (?), ngocdh and softins have some knowledge in the Right direction. However they’re probably working on other stuff?

I still strongly believe that this should be fixed, but honestly I don’t see it being fixed soon (due to the reasons mentioned above)

What could you do in order to move this forward? Do you know people who could help out? Can you help out? I don’t think I can do much since I‘m not familiar with the sound handling.

[ann0see]

The channel detection thing should be clarified and raised as a specified feature. Ideally you’d open a PR with the code you provided.

[pgScorpio]

Status of this bug: Priority exists, but nobody is currently working on it.

That's a pity, I know some people who run into this problem regularly.

Reason:

1. Fear of changing core code (the whole design of the audio processing is far from ideally designed). Currently it at least works so so.

Yes I also noticed that the sound code is far from ideally designed. I have some ideas on improvement, but that would take some serious work.

Changing might introduce new serious bugs

That's why I think the sound framework really should be improved, and I can see why most of the developers are reluctant to dive into this. But proper OS abstraction would make changes in the future easier and less prone to OS dependent bugs since changes to client/server code should be independent from the OS dependent sound code.

2. These bugs do exist: the mentioned PR which does have a lot fixed results in a unusable macOS version. We can not release this.

Ok, that's that's really a major problem. What's the problem caused in macOS? (All people I know with the "Unable to configure ASIO device" are obviously on Windows)

3. We’re lacking someone diving into the audio code. I don’t think anyone of the main contributors has deeply analysed the audio code.

I would love to dive into it...

4. There is no plan on what to change (maybe you can help us making one and finding someone who works on it?) What could you do in order to move this forward? Do you know people who could help out? Can you help out? I don’t think I can do much since I‘m not familiar with the sound handling.

As said, I hope to get some more time soon, and would be glad to dive into the sound code and design a proper OS abstraction for sound, though this will take some time and will initially cause several issues. Perhaps we should do this on a special branch? And to get me going ASAP I would gladly accept some help to:

• Set up a working development environment for (cross) compiling and debugging ALL OS'es (currently I only manage to build the Windows release, can't get debugger to work. Just lacking the time to find out what I need and how to configure.). Is there any documentation on setting up the development environment? (more detailed than COMPILING.md)
• Get familiar with your pull/merge procedures (I never participated in a github project before.).
• Obtain proper documentation on the several OS'es and their audio interfaces.
• Get a list with all known issues related to sound code.

If you can (or know who can) get me going in a short time feel free to email me and I'll dive into it asap.

[pgScorpio]

The channel detection thing should be clarified and raised as a specified feature. Ideally you’d open a PR with the code you provided.

I'm not yet familiar with PR, so if you can give me some directions how to do that properly I will.

[hoffie]

PR creation is not really Jamulus-specific, so I think generic Github tutorials should apply: https://opensource.com/article/19/7/create-pull-request-github https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request

Does this help?

You can also edit and create PRs from the Github web page, but (at least for me) it quickly gets complicated or unnatural when performing multiple changes (it's ok for single-file changes, I guess). In general, I prefer working with git locally where I can run a build before committing, etc.

[ann0see]

Set up a working development environment for (cross) compiling and debugging ALL OS'es (currently I only manage to build the Windows release, can't get debugger to work. Just lacking the time to find out what I need and how to configure.). Is there any documentation on setting up the development environment? (more detailed than COMPILING.md)

Disclaimer: I wouldn’t focus on cross compilation since setting it up is probably a pain (especially macOS https://www.quora.com/How-can-I-deploy-a-QT-application-to-a-Mac-OS-from-my-Windows-computer?share=1)

As you already got Windows to work, you‘re in a very good position. You should work with visual studio, not Qt Creator (at least that’s my very limited experience for developing on Windows). Personally I prefer developing on Linux.

Setting up a Linux build environment: You should install WSL v2 to at least compile the headless version on Windows. Probably there’s a way to cross compile, but I doubt it’s worth it. Just install the WSL or even better, set up a USB stick/VM with Linux. There you‘d be able to really test everything. Following COMPILING.md should be sufficient then. MacOS is much more challenging. You could install a VM via OSX-KVM on Linux (in qemu), use a real mac or rely on the CI (I‘d first of all rely on the CI for macOS building and use a VM to test. To speed building up, disable CodeQL. It’s not ideal, but certainly better than buying a real mac.) Cross compiling

Android could be tested via some android emulator or via Windows Subsystem for android. But I wouldn’t waste too much time on that. First get the main builds running.

[ann0see]

Obtain proper documentation on the several OS'es and their audio interfaces.

I can only link the official docs:

macOS: https://developer.apple.com/documentation/coreaudio ASIO: should be provided as pdf in the ASIOSDK folder which gets downloaded automatically via the build script JACK: https://jackaudio.org/api/

I haven’t verified that these are the best sources but googling sometimes gives some good websites/blog posts.

[ann0see]

Get a list with all known issues related to sound code.

That’s challenging ;-). Some first ideas:

1. Jamulus relies on having a valid audio device at all times.
2. Changing devices in ASIO4ALL makes Jamulus freeze (sometimes, not reproducible)
3. If there’s no valid device Jamulus automatically chooses some device. You can’t choose another one and open ASIO settings
4. Setting the sample rate to something != 48kHz during run time might quit Jamulus.

If I were you, I‘d have a look at npostavs PR and suggest working with him.

[pgScorpio]

@ann0see Thanks for all the info. This already will keep me busy for some time ;=)

As you already got Windows to work, you‘re in a very good position. You should work with visual studio, not Qt Creator

I would love to use Visual Studio, but there are no vcproj files available in the source code!? Are they available? Currently I am using Qt Creator on Windows, since that was the fasted way to get going, But I can't get the debugger to work.

Disclaimer: I wouldn’t focus on cross compilation since setting it up is probably a pain (especially macOS

But to improve the OS independent framework it would be very useful to be able to compile the same tree for all platforms on the same system. (Just compiling, Running and debugging can eventually be done with remote debugging.) And afaik this should be possible with Visual Studio 2017, Anybody ever tried that?

@npostavs Can you tell what is the problem on MacOS?

@ann0see @npostavs Any additional hints to get me going?

[ann0see]

I think the build script deploy_windows.ps1 generates the VS files?

[pljones]

I've never used VS on Windows for Jamulus, only Qt Creator. It reads the Jamulus.pro file. You can configure Qt Creator to use your VS MS C++ install, though - you don't need (or want) a separate compiler.

[pgScorpio]

I've never used VS on Windows for Jamulus, only Qt Creator. It reads the Jamulus.pro file. You can configure Qt Creator to use your VS MS C++ install, though - you don't need (or want) a separate compiler.

I know. I'm currently using QT Creator to build the windows version, but can't get the debugger and other builds to work.

ann0see advised "You should work with visual studio, not Qt Creator" and I would love to, since I'm quite familiar with Visual Studio IDE and completely new to QT Creator. But there are no VC project files to work with.

I think the build script deploy_windows.ps1 generates the VS files?

Any hints on how to use that script? As far as I can see it generates the windows installer... not any VC files.

[softins]

I've just read through PR #1378 commit-by-commit and all together. While I understand the severity of this issue for those it affects, I think the changes in that PR are too involved and not sufficiently understood to try and get them into 3.8.2 without significant delay to the release. We should get the 3.8.2 release out and then revisit this issue in earnest.

[npostavs]

@npostavs Can you tell what is the problem on MacOS?

I can't, I don't run or develop on MacOS. I only know that ann0see reports "hangs on trying to connect and then gives back that the audio interface doesn't work".

By the way, I've used MSys2/Mingw to debug with gdb on Windows. The build procedure is basically the same as on Linux.

[pgScorpio]

@npostavs Can you tell what is the problem on MacOS?

I can't, I don't run or develop on MacOS. I only know that ann0see reports "hangs on trying to connect and then gives back that the audio interface doesn't work".

Hmmm, sounds familiar.... @ann0see what device did you use on macOS? Does this happen with any device? I know from experience that a lot of devices that work on Windows or Linux have this effect on macOS. Probably since mac/sound.cpp has a totally different approach of implementation as the other OS'es. (See also this issue )

By the way, I've used MSys2/Mingw to debug with gdb on Windows. The build procedure is basically the same as on Linux.

OK, but I would really prefer to use the Visual Studio IDE, just because I'm very familiar with building multi target software on VS. But since it is a long and tedious job to setup the VC project files for such a large project, especially when you are new to the project and you also have no experience with QT it would be nice if anybody already has VS project files for any Jamulus target build on windows, If so please let me know. (Once I have one target working in VS the other targets shouldn't be to hard to configure in VS too)

[pgScorpio]

I've just read through PR #1378 commit-by-commit and all together. While I understand the severity of this issue for those it affects, I think the changes in that PR are too involved and not sufficiently understood to try and get them into 3.8.2 without significant delay to the release. We should get the 3.8.2 release out and then revisit this issue in earnest.

What's the hurry to get 3.8.2 out? In my opinion we should solve bugs and basic functionality first, then new features.

[ann0see]

It’s the bug fix for macOS legacy.

[ann0see]

what device did you use on macOS?

I think either the internal sound card or my Behringer UMC202HD Interface.

Any hints on how to use that script? As far as I can see it generates the windows installer... not any VC files.

Either if you comment clean build environment and build installer at the end of the script it produces the files , or you need to do it with the old script. I‘m going to search it for you.

[ann0see]

Ok. Read through https://github.com/jamulussoftware/jamulus/blob/4f9d146037e35a53238f7ab37b38ae69ea3fcb56/windows/deploy_windows.bat and use the commands you need to build the files.

[hoffie]

What's the hurry to get 3.8.2 out?

The release process for 3.8.2 has already started. If we do find a simple fix for this issue which doesn't require translation changes, it could still go into 3.8.2. I've little hope for that to be true though.

We should only delay releases to avoid regressions, not, because we haven't fixed all bugs yet which should have been fixed. There will always be bugs. So, the largest benefit to users and developers (which would be blocked otherwise) is to get the things which are done and tested out of the door as quickly as possible.

In my opinion we should solve bugs and basic functionality first, then new features.

In general, I agree. However, the reason that this bug has not been fixed yet seems to be that while there is a concrete implementation which aims at fixing it, it is still not complete or bug-free (wrt macOS, it seems). Therefore, we would not benefit if people delayed other work. It looks like we'd need someone with macOS knowledge, a Mac to reproduce and time to do this work.