List of selectable audio devices incomplete in Jamulus preferences

[heepm]

When having a lot of audio devices connected / active on the computer, not all audio device combinations will be listed in the Jamulus drop down menu. This seems to appear when having around 10 audio devices available in system preferences. Reducing the number of audio devices connected to the computer makes the missing devices available again in the drop down menu.

Issue can be reproduced by creating several audio aggregate devices in audio midi setup.

Operating system: macOS Sonoma 14.1.2
Jamulus version: 3.10.0, downloaded from website

In addition: drop down menu which lists all possible combinations of audio input and output devices is very unhandy.

Suggestion: splitting drop down menu in 2 separate menus as every other DAW has for input and output. Then list only the devices to choose.

[ann0see]

Hi @heepm
Thanks for opening this issue.

In addition: drop down menu which lists all possible combinations of audio input and output devices is very unhandy.

I agree. Not sure why it was designed like that, but there's probably a reason. I remember that we talked about it in the past. @pljones Do you remember? Maybe some implementation thing?

I think if you have 10 devices, we just have a massive combination of devices in theory it should still show up.

Do all devices have the same sample rate and preferably the same clock source?

Related code fragment: src/sound/coreaudio-mac/sound.cpp

[ann0see]

The code says

// we add combined entries for input and output for each device so that we
// do not need two combo boxes in the GUI for input and output (therefore
// all possible combinations are required which can be a large number)

Probably the problem is that Windows and Linux use non "native" drivers (ASIO/JACK).
So we might need to sketch a working UI for that too.

[pljones]

The audio settings screen is platform dependent. I can't comment on the Mac one. Maybe we could provide a JACK build for Mac?

[ann0see]

Maybe we could provide a JACK build for Mac?

Probably yes, but not part of this issue.

Building via Xcode on macOS is currently a bit difficult. I only have access to an old machine which doesn't run Xcode too well. But we can do some sketches. The bug itself needs investigation.
@heepm Could you please take a picture when the bug occurs?

[heepm]

@ann0see yes, as far as I can investigate this, sample rate and clock source are the same and not related to the issue.

Concerning the building issue with Xcode: maybe I can support you and try to build a test build for us. I have a little bit of experience in c++ and swift.

Screenshot when the bug occurs see attached. The first pictures contains all audio drivers / devices installed on the machine. The second and third picture show the drop down menu of Jamulus. As you can see the hierarchy of the audio devices in the audio midi setup determine the drop down list in Jamulus. The devices in the lower section do not appear. If I connect additional devices being in higher hierarchy of the audio midi setup list, devices in Jamulus that were available before disappear too, I observed.

Note: I tested this issue also on a second machine running macOS 12.7.2 with different audio drivers and devices installed. Same issue occurs.

Let me know if I can contribute further.

[ann0see]

Thanks. Sorry for the delay.
I have the feeling that there could be an array out of bounds error?

[ann0see]

Do you have knowledge of macOS development? If yes, you can try compiling the app via deploy_mac.sh

[ann0see]

Wait. I forgot that there's a fix I found some time ago. #3078

[softins]

I have the feeling that there could be an array out of bounds error?

No, I don't think so. The relevant arrays are sized as MAX_NUMBER_SOUND_CARDS, which has the value 129 set in

jamulus/src/global.h

Lines 184 to 185 in 7720fcd

	// maximum number of recognized sound cards installed in the system
	#define MAX_NUMBER_SOUND_CARDS 129 // e.g. 16 inputs, 8 outputs + default entry (MacOS)

When filling the arrays for a Mac, it correctly checks against this value:

jamulus/src/sound/coreaudio-mac/sound.cpp

Lines 151 to 160 in 7720fcd

	if ( bIsInput_i && bIsOutput_j && ( lNumDevs < MAX_NUMBER_SOUND_CARDS ) )
	{
	strDriverNames[lNumDevs] = "in: " + strDeviceName_i + "/out: " + strDeviceName_j;
	// store audio device IDs
	audioInputDevice[lNumDevs] = vAudioDevices[i];
	audioOutputDevice[lNumDevs] = vAudioDevices[j];
	lNumDevs++; // next device
	}

This prevents array out of bounds, but causes all the I/O combinations beyond this number just to be ignored.

Could try compiling with a larger number for MAX_NUMBER_SOUND_CARDS.

I agree a better solution would be setting In and Out devices separately, even if just for Mac.

[ann0see]

Ok. That would also make sense. Then the problem should be clear.
But yes, preferably we'd let macOS and iOS select in/outputs manually and use an #ifdef there.

macOS/iOS (maybe also android) would show "device" -> new UI
Everything else would show "Driver" -> current UI

[ann0see]

I'd like to work on the splitting of in and out devices in the next time (but no guarantees). I might need some help for testing on macOS (only have access to older mac hardware...)

[pljones]

How about splitting out the very platform-specific settings onto a separate tab?

The audio channels and quality are actually as much network issues as anything (they affect bandwidth and server side processing).

Buffer Delay is the odd one out - it's related to the client sound I/O rather than network - it could be a fixed component on a tab extended per-platform.

[ann0see]

No. Things should still be easily visible. More tabs = more complexity => more confusion

[pljones]

Currently the tab is a bit mixed up and inconsistent between platforms. Having to explain that introduces complexity and confusion anyway. Separating out the platform-specific parts so they can be addressed separately under platform-specific headings with clear, non-confusing screenshots might reduce confusion.

[ann0see]

I haven't forgotten that, but currently a bit short on coding time. This should be done for the next release...

[ann0see]

Ok. After some more looking into the code, we may need to do some bigger refactoring with the "sound card" abstraction also.