Audio interface channel names in setup dialog

[AndersGoran]

I was hesitant if I should file this under bugs or whatever, but I see an interesting thing when I compare pre-built vs self-compiled Jamulus clients.

I use macOS (currently 12.7.6, M1 laptop). The audio interface I most often use is an old MOTU 828mk3, the firewire-only version. Not officially supported by MOTU but it actually works very well under Monterey once properly setup.

Whenever I run an official release of Jamulus, or for that matter, the build artifact from the recent --midictrlch PR, the audio setup dialog looks like this:

I.e., only generic names for all input and output channels are shown. It shows the correct number of channels, depending on whether I enable or disable ADAT and so on.

If I run a client that I compiled myself, I get this:

It is of course much nicer to see the channel names that I've configured in MOTU's setup app for the interface. I don't expect anyone to have an explanation or fix, but I find it interesting and I'll do some digging to see if I can understand it.

[ann0see]

Might be a different Qt version.

[ann0see]

Good to know. Otherwise it could have been related to signing

[AndersGoran]

Yep, I don't think the signing has to do with it. The file you indicated, coreaudio-mac/sound.cpp, it has this interesting section (or actually two of them, one for inputs, one for outputs):

AudioObjectGetPropertyData ( audioInputDevice[iDriverIdx], &stPropertyAddress, 0, NULL, &iPropertySize, &sPropertyStringValue );

// convert string
const bool bConvOK = ConvertCFStringToQString ( sPropertyStringValue, sChannelNamesInput[iCurInCH] );

// add the "[n]:" at the beginning as is in the Audio-Midi-Setup
if ( !bConvOK || ( iPropertySize == 0 ) )
{
    // use a default name in case there was an error or the name is empty
    sChannelNamesInput[iCurInCH] = QString ( "%1: Channel %1" ).arg ( iCurInCH + 1 );
}
else
{
    sChannelNamesInput[iCurInCH].prepend ( QString ( "%1: " ).arg ( iCurInCH + 1 ) );
}

This is clearly where the channel names are constructed, so I need to figure out which one of !bConvOK || ( iPropertySize == 0 ) is happening, leading to "default" names.

[AndersGoran]

// get the channel names of the output device
  for ( int iCurOutCH = 0; iCurOutCH < iNumOutChan; iCurOutCH++ )
  {
      CFStringRef sPropertyStringValue = NULL;
      stPropertyAddress.mSelector = kAudioObjectPropertyElementName;
      stPropertyAddress.mElement  = iCurOutCH + 1;
      stPropertyAddress.mScope    = kAudioObjectPropertyScopeOutput;
      iPropertySize               = sizeof ( CFStringRef );

      AudioObjectGetPropertyData ( audioOutputDevice[iDriverIdx], &stPropertyAddress, 0, NULL, &iPropertySize, &sPropertyStringValue );

A client that has been run through macdeployqt gets zero-length strings for the audio channel names in sPropertyStringValue. The string conversion in ConvertCFStringToQString fails because it has no characters to work on, hence the default names.

[ann0see]

This sounds like a sandbox issue still.

[AndersGoran]

OK... this is so strange, I've no idea what to think. Maybe the code signature has something to do with this after all.

I have figured out that if I take the official macOS client, install it from the official DMG and re-sign it, like this:

$ codesign --force --sign - /Applications/Jamulus.app
/Applications/Jamulus.app: replacing existing signature

so that it gets some kind of ad-hoc signature instead... and now I have to right-click and choose Open to launch it, as this supposedly breaks the notarization...

lo and behold, I now see the sound interface's real channel names in Settings!

At first I had the --deep option too, so I was re-signing everything in the app bundle, but that's not necessary, it turns out.