Event when an audio device is disconnected?

Hi,

I’d like to execute some code when an audio device is disconnected. Currently, I’m using a timer to poll the devices count, but it’s always more elegant to wait for an event.
My problem is: I can’t find any class that provides such events (I searched in the MBS plugin). Christian, do you think this is something that could be added in a future release, please?

Or I’m missing an already-existing way?

Mac? Windows? Linux?

Sorry I forgot; Mac.

1 Like

Oh, good idea. I was focused at the audio level but was not thinking out of the box (actually, it’s an HDMI device connected using an USB adaptor).
Thank you.

1 Like

I looked how to implement this, then through about adding it for you. But luckily I did a search and saw, that I have it already:

See CoreAudioListenerMBS class.

You can listen for changes to the device list.

4 Likes

Great, I’ll take a look. Thank you.
P.S.: I don’t know which answer I should mark as the solution in such cases (there are two), but it’s also bad to not mark either of them :man_shrugging:.

If you want to be sure that the thing being disconnected is an audio device, use Christian’s answer.

2 Likes

I agree - if it works, the AudioListener should be more specific than a USB notification. But make sure it works before marking it as the solution :smiley: All you get is a “Changed” event for an instance of the class, so if you’re not already using the class who knows how much effort it will take.

2 Likes

Thanks for your answers.
I used both solutions, because monitoring the HDMI display is also a nice addition to the app.
I’m marking Christian’s answer as the solution, since it’s all based on his plugin; Julia’s answer would also be a candidate, hope you don’t mind :slightly_smiling_face:.

1 Like

Not at all :slight_smile:

1 Like

Hi,
I’m sorry that I have to reopen this thread, but the provided solutions aren’t quite working each time.
I need to monitor when an HDMI device, which is used as an audio output, has been disconnected. So, the USB class won’t work in this case.
As for the other suggestion (CoreAudioListenerMBS), it works only when the default system output is the one I’d like to monitor, which is rare (but was unfortunately the case when I tried, so I thought it was just working).
The documentation about CoreAudioListenerMBS tells to see the example project, which, in turn, is monitoring the default system output only, so I’m lost.

In the example project, the object is constructed using kAudioHardwarePropertyDefaultOutputDevice, which is a specific constant. Would I need to use another constant that refers to an “HDMI” class, or what constant could be used for a non-default device?

So here is a snippet to get the list of devices:

var ids As MemoryBlock
var outSize As Integer
var deviceName As String
var outWriteable As Boolean

var c as New CoreAudioMBS
c.AudioHardwareGetPropertyInfo c.kAudioHardwarePropertyDevices, outSize, outWriteable

var numDevices as integer = outSize / 4

// Get the device IDs for each device
ids=c.AudioHardwareGetPropertyMemory(c.kAudioHardwarePropertyDevices)

For i as integer = 0 To numDevices-1
  var id as integer =ids.Long(i*4) // 4 bytes per integer
  var m as MemoryBlock = c.AudioDeviceGetPropertyMemory(id, 0, False, c.kAudioDevicePropertyDeviceName)
  
  If m<>Nil Then
    deviceName=m.CString(0)
  End If
  
  System.DebugLog str(id)+": "+deviceName
  
Next

And if you listen for devices coming and going, you may listen for changes to the Devices property:

c = new MyCoreAudioListenerMBS(kAudioObjectSystemObject, kAudioHardwarePropertyDevices, kAudioObjectPropertyScopeGlobal, kAudioObjectPropertyElementMaster)
1 Like

Thanks!
The code to gather the devices list was already working in my project.
The kAudioHardwarePropertyDevices constant seems to be the answer to my problem, and I’ll test it as soon as possible (it’s at another place where I go once or twice per week).

Would it be a good addition to list these constants in the CoreAudioListenerMBS page of the documentation, in your opinion?

Thank you; it did the trick!
I had one thing that puzzled me a bit, so I’m mentioning it here in case someone else tries the same thing: when an audio device is disconnected, the audio players (AUPlayerMBS objects) get their device ID automatically reassigned to the new device where it’s playing, so we must cache the property to know whether the output of the player is still valid (otherwise, it’s always true).