MacOS: If an audio device is no longer available, show an error rather than switching to Default

[wareynolds96]

Hi There,
Hope you are doing well. I was just wondering if anyone else has come across this?
We are using for our input channel mapping:
L: Analog 5
R: Analog 6
We are using for our output channel mapping:
L: Analog 3
R: Analog 4
We are using this via totalmix as well so we can route back audio between two computers and have multiple inputs.
The issue we are having is that when we are in the middle of a session Jamulus changes the input and output channel mapping to 1 & 2 which completely kills any signal being able to be passed through.
I am not sure if this is a new thing or a bug related to version 3.6.0. but could someone help us out? Is there a workaround or is it something we can get fixed quickly or is there something we are missing?
We are open to any ideas of help and if we are wrong that is great to know. Just want to get it sorted out really.
Thanks so much for your time!
Will

[wareynolds96]

@corrados just posting this here.

Thanks

W

[WolfganP]

This repository is rather for developers. You may be getting better help on the users forums https://sourceforge.net/p/llcon/discussion/ and https://www.facebook.com/groups/619274602254947/

[corrados]

@WolfganP There is already a discussion going on in the forums: https://sourceforge.net/p/llcon/discussion/software/thread/1e69217ce0

[corrados]

Jamulus changes the input and output channel mapping to 1 & 2 which completely kills any signal being able to be passed through

Jamulus only resets the channel mapping when a new audio device is selected.

I am not sure if this is a new thing or a bug related to version 3.6.0

There were no changes to the audio channel mapping done in 3.6.0 so I do not think this is a specific problem of that version.

From the forum discussion on Sourceforge:

What I have seen is that if Jamulus can't access the selected interface it picks 1&2 of the first interface it finds.
Could it be that your interface is having intermittent dropouts ?

Can you please answer this question?

[wareynolds96]

Hey Volker, Thanks so much for this info. To answer your question no we are not having dropouts at all. We are trying to use this in conjunction with Logic Pro X and Pro Tools 2020.11. It seems to happen intermittently when the DAW is open. Is there any way to lock the I/O or save the I/O so that it never changes? The thing that is a bit confusing is when you click on the box of the Jamulus I/O it looks as if it is still on 3&4 but has actually gone back to 1&2. Hope that helps a little. Thanks so much for your time Will

[corrados]

The thing that is a bit confusing is when you click on the box of the
Jamulus I/O it looks as if it is still on 3&4 but has actually gone back to
1&2.

Ok, that explains what's going on. As in #181, Jamulus does not recognize changes of the audio devices. So, it seems that during your session the audio driver setup in your Mac OS changes.

Is there any way to lock the I/O or save the I/O so that it never changes?

Unfortunately, I cannot answer you this since I am not a MacOS expert. Maybe anyone else can help with that?

[chrisrimple]

@corrados I think what's being suggested is that Jamulus settings do not change, even if the originally-selected audio device is no longer available. Instead, maybe show an error so the user is aware that the device is not available, rather than automatically switching to Default.

Showing an error instead of auto-switching to Default would also solve a related problem:

• Jamulus user has no audio interface and is using onboard sound card with wired headset/earbuds (headphone jack or USB) with integrated mic
• While connected to a Jamulus server, user intentionally/accidentally unplugs headset/earbuds
• Jamulus immediately switches to Default device, which for most is Internal Mic + Internal Speakers
• Because Internal Speaker volume is high, Internal Mic picks it up, sending it to Jamulus server, which then comes back to Internal Speakers, creating a feedback loop
• Other users on the server enjoy a loud squeal until the original user realizes what's happened and mutes themself

Among Jamulus users in the choral world, this is a common problem. :)

[corrados]

We already have multiple bug reports for the Mac audio interface:

• Jamulus does not always select the previous sound card MacOS: Jamulus does not always select the previous sound card #680
• If sound input/output are changed after launch, changes are not reflected in Jamulus settings MacOS: If sound input/output are changed after launch, changes are not reflected in Jamulus settings  #181
• Detect if no audio Device is selected before trying to connect a server Detect if no audio Device is selected before trying to connect a server #129

[wareynolds96]

@corrados I think what's being suggested is that Jamulus settings do not change, even if the originally-selected audio device is no longer available. Instead, maybe show an error so the user is aware that the device is not available, rather than automatically switching to Default.

Showing an error instead of auto-switching to Default would also solve a related problem:

• Jamulus user has no audio interface and is using onboard sound card with wired headset/earbuds (headphone jack or USB) with integrated mic
• While connected to a Jamulus server, user intentionally/accidentally unplugs headset/earbuds
• Jamulus immediately switches to Default device, which for most is Internal Mic + Internal Speakers
• Because Internal Speaker volume is high, Internal Mic picks it up, sending it to Jamulus server, which then comes back to Internal Speakers, creating a feedback loop
• Other users on the server enjoy a loud squeal until the original user realizes what's happened and mutes themself

Among Jamulus users in the choral world, this is a common problem. :)

Hey Chris,

Thanks for this. This is exactly what we are talking about just in a different use case as we are using large audio interfaces. An error message would be super helpful or perhaps Jamulus could just wait for 5 seconds until the audio interface re appears. I am no programmer and not sure how hard this is but would love it if it was possible.

Thank you all for your help..

Will

[wareynolds96]

We already have multiple bug reports for the Mac audio interface:

• Jamulus does not always select the previous sound card MacOS: Jamulus does not always select the previous sound card #680
• If sound input/output are changed after launch, changes are not reflected in Jamulus settings MacOS: If sound input/output are changed after launch, changes are not reflected in Jamulus settings  #181
• Detect if no audio Device is selected before trying to connect a server Detect if no audio Device is selected before trying to connect a server #129

Hey Volker,

Thanks for this. Yes totally except we aren't using the built in Mac Audio Interface but the same would apply for any interface. I think it would just be helpful to have an error message come up and have Jamulus reflect what has happened in the preferences I/O Dialogue so that you can clearly see that Jamulus has defaulted back to it's default. An error message would be super helpful too.

On a side note - is there any way to make it not default or save I/O with Jamulus?

Thanks again

W

[chrisrimple]

@corrados What I'm suggesting is that Jamulus behave similar to other apps that interact with audio sources: (1) save settings between sessions and (2) anytime the selected audio source isn't available, display an error instead of changing the setting automatically. On Mac, when I quit a DAW (Logic, GarageBand, MainStage, etc.) with my audio interface selected, then restart the DAW, I get an error if the audio interface is not available, but the DAW doesn't automatically switch to Default audio. Similarly, when a DAW is running, and I connect a new audio device, the DAW asks me if I want to switch to it, but doesn't automatically do so. It would be nice if Jamulus behaved the same, at least in the "missing device" case. :)

[wareynolds96]

Hey @corrados

I appreciate all the work etc. Would you mind changing the title back to what it was because the main goal is that it stays as the interface even if it drops so that it doesn't default to 1&2. An error message would be helpful but the main thing is for it to remember the I/O of that interface when it comes back online.

Is there any update on when this could be looked at?

Thanks

W

[corrados]

I have done some modifications to the Mac audio interface. I hope that most of the complains about the Mac audio interface implementation in Jamulus should be solved now. Here is a beta version I created from the latest code:

Jamulus-3.6.1MacBeta-installer-mac.dmg.zip

Can you please test that new version and provide feedback here how the new version works for you, if the problems are solved or if there are outstanding problems.

[kwindrem]

I see minor changes from previous versions.

If the selected sound card is no longer present when Jamulus client starts, the first interface in/out pair in the list is selected rather than the in/out pair at the same place in the list as was prevously used. This is slightly better, but not what we really need. Jamulus needs to make no automatic selection if the previous selection can't be made automatically. To make any alternate selection automatically invites feedback when a connection is made (e.g., defaulting to the computer's microphone and speakers which is likely the default and first pair in the list

If the previous interface selection can no longer be made, Jamulus needs to default to "no interface". This way, connecting to a server can't possibly create feedback. A better way to handle this is the Connect button dims and connection is not possible until an interface selection is made. A "no audio interface" warning in the main window might replace the "Server" line as additional feedback as to what to do next.

The other thing that really needs to happen is to rebuild the list when interfaces appear and disappear. If this can't happen "live" then a "Refresh List" button or list selection is needed.

I also believe separating the interface in/out selection into separate in and out lists makes things so much simpler. by reducing approximately 40 possible in/out pairs to two separate selections of 4-7 selections each.

[chrisrimple]

I haven't tested yet but like all of @kwindrem's feedback. :)

[corrados]

the main goal is that it stays as the interface even if it drops so that it doesn't default to 1&2

This should be fixed with the beta provided in the ZIP file in this Issue.

the first interface in/out pair in the list is selected rather than the in/out pair at the same place in the list as was prevously used

How can you select the same place in the list if the device is no longer present?

Jamulus needs to make no automatic selection if the previous selection can't be made automatically

What should Jamulus automatically selecting? If the selected previously selected audio interface is no longer present, the most obvious choice is to use the system default input/output device.

To make any alternate selection automatically invites feedback when a connection is made

You never know which device will give you feedback or not.

If the previous interface selection can no longer be made, Jamulus needs to default to "no interface"

This is bad because if a user starts Jamulus for the first time, he will not get any sound at all. The default behaviour should be that Jamulus picks an appropriate sound card.

The other thing that really needs to happen is to rebuild the list when interfaces appear and disappear.

This works for me for the given beta. The question is why it does not work for you.

I also believe separating the interface in/out selection into separate in and out lists makes things so much simpler.

This is a separate feature request #681 which was not addressed in that beta version.

[kwindrem]

the first interface in/out pair in the list is selected rather than the in/out pair at the same place in the list as was prevously used

How can you select the same place in the list if the device is no longer present?
The behavior prior to the beta was that an index into the device list was saved. When Jamulus starts, it selects the interface at that index even if the device list has changed.

The new behavior is that the first device in the list is selected. On the Mac, this is generally the system default in/out and that interface will most likely be microphone and speakers -- definitely not a good selection for Jamulus.

Jamulus needs to make no automatic selection if the previous selection can't be made automatically

What should Jamulus automatically selecting? If the selected previously selected audio interface is no longer present, the most obvious choice is to use the system default input/output device.

As mentioned above, the system defaults are a bad choice for Jamulus.

What I'm suggesting is that a selection of "no interface" should be made in the case where the previous device is no longer available. The previous selection would be retained and checked with the next launch (or list rebuild).

To make any alternate selection automatically invites feedback when a connection is made

You never know which device will give you feedback or not.

True, but the system defaults is the most likely candidate for feedback as mentioned above.

If the previous interface selection can no longer be made, Jamulus needs to default to "no interface"

This is bad because if a user starts Jamulus for the first time, he will not get any sound at all. The default behaviour should be that Jamulus picks an appropriate sound card.

That's why I suggest a "no audio interface" message replacing the "Server" text on the main Jamulus window.

I'd argue that the wrong interface selection is at least as bad as no interface at all - possibly worse.

The other thing that really needs to happen is to rebuild the list when interfaces appear and disappear.

This works for me for the given beta. The question is why it does not work for you.

If the selected interface disappears, the system default is selected and the list rebuilds.

However if the interface reappears, the list is not rebuilt.

If a nonexistent interface is selected, a warning dialog appears and after dismissing that, the list rebuilds.

Note that the current interface disappears, the system default interface is selected even while connected to a server ---- very bad. Another reason to select "no interface" in this condition.

[corrados]

Next try:

Jamulus-3.6.1MacBeta2-installer-mac.dmg.zip

Now you should get an error message of the previous selected audio device is no longer available. So if you start Jamulus and forgot to plug in your external audio device, you will get a clear message so that you are reminded that you have to plug in your correct audio device.

[kwindrem]

Yes, the warning dialog helps a lot.

The device list is still not being rebuilt when any interfaces are added or removed (unless the one that is removed is the one that's selected).

I'm still uncomfortable with selecting the system default interface especially when connected to a server. I just tried it and was greeted with huge feedback!!

[corrados]

I did some more modifications of the Mac OS audio interface and device management. Could you please try out this new beta version:

Jamulus-3.6.1MacBeta3-installer-mac.dmg.zip

[kwindrem]

I don't see any changes from the previous beta version. The list is rebuilt when the currently selected interface is removed from the computer but NOT when the device is connected again. You must quit Jamulus to refresh the list again. So, no change from beta2.

[corrados]

Thanks for testing.

The list is rebuilt when the currently selected interface is removed from the computer but NOT when the device is connected again.

I know. This I was not trying to fix with this new beta. This is the topic of Issue #181 and should be discussed there.

This new Beta3 trys to fix the following things (I should have written that earlier to avoid confusion, sorry):

• "when you click on the box of the Jamulus I/O it looks as if it is still on 3&4 but has actually gone back to 1&2" -> this should be fixed now
• "Jamulus settings do not change, even if the originally-selected audio device is no longer available. Instead, maybe show an error so the user is aware that the device is not available, rather than automatically switching to Default" -> this should be implemented now
• "MacOS: Jamulus does not always select the previous sound card MacOS: Jamulus does not always select the previous sound card #680" -> the previous sound card should be selected even if the number of other sound devices has changed
• "Detect if no audio Device is selected before trying to connect a server Detect if no audio Device is selected before trying to connect a server #129" -> now you should get a warning message if there is a problem with the audio device
• I found out that sometimes Jamulus crashed on shutdown on MacOS when closing the main window during a session. This should be fixed now, too.

[kwindrem]

I tested based on the above:

#1 appears fixed
#2 I get the warning but Jamulus still selects the default input/output pair even while connected to the server
#3 appars fixed
#4 that happens, but in my opinion should NOT be automatically selecting a default. The detailed warning helps

[corrados]

#2 I get the warning but Jamulus still selects the default input/output pair even while connected to the server

Ok, to really make sure that you get no feedback after switching to the default device, I now make a disconnection. So the user sees the warning message (in which it is clearly stated that you may get feedback) and he get's disconnected. So the user must explicitely reconnect. I think that makes it even safer to avoid feedback. Here is the updated beta version:

Jamulus-3.6.1MacBeta4-installer-mac.dmg.dmg.zip

[corrados]

@kwindrem I just found out that there is a workaround for your request for a "refresh" button. If you plugin a new device and the list in the combo box is not updated, simply select any sound card (you can, e.g., even select the sound card which is currently already selected) and then the list is refreshed.

[kwindrem]

The list refresh doesn't appear to be working for me on the beta 3

[corrados]

You need to use the Beta4 for this.

[kwindrem]

Thanks. That helps.

[wareynolds96]

Hey Volker, Thanks for all of your help on this. The error message is super helpful. I think the thing that would be really helpful which was in beta 3 is that you stay connected to the session but jamulus doesn't select any other audio device. Then the ideal thing would be that it just shows the interface that you were previously connected to greyed out or in italics. Once that interface is available again it reconnects automatically. Definitely useful to keep the warning message though. The other thing that would be super helpful is to have separate drop down menus for Audio Interface Input and Audio Interface Output. When you have a lot of audio interfaces the current list can be quite overwhelming visually and it is hard to find the I/O of your own interface. Thank you so much for taking the time to help us Will This e-mail is confidential and may also be privileged. If you have received it in error you are on notice of its status. It is not intended that this e-mail be relied upon without subsequent written confirmation of its contents. Please notify us immediately by reply e-mail and then delete this message from your system. You are hereby notified that any disclosure, forwarding, copying, distribution or taking action in relation to the contents of this email is strictly prohibited and may be unlawful.

…

On Sun, Dec 6, 2020 at 11:29 PM kwindrem ***@***.***> wrote: Thanks. That helps. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#727 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APFW4VYILDK5I2AIZ3KTVJTSTQHUFANCNFSM4TXBZ6WA> .

[ann0see]

Any updates on this what's the current status here? Although I can't comment on the code, is this solved now?

[ann0see]

It seems as if #796 was introduced because a change wanting to fix this on Windows. I think we must re-think this functionality again.

[gilgongo]

Closing for now as most of the issues seem to have been addressed. Please open a discussion on desired UI behaviour issues in the event of interfaces being unavailable (or see the linked PR).