Audio Device Detection¶

Introduction¶

The idea behind audio device detection is to allow SIP users to switch headphones, speakers or microphones as they are plugged or unplugged from the computer.

Many SIP applications allow this. Some require to restart the application, while others can detect it while running. SIP SIMPLE client can currently detect hotplugged devices in Mac OS X platforms.

Goal¶

The ultimate goal is to enable SIP SIMPLE client applications to detect audio device changes on the fly in all currently supported platforms, with the most immediate priority being Windows platform.

Schematic Overview¶

Required Modifications¶

After a first analysis of the SIP SIMPLE client SDK and dependencies, these are the necessary PortAudio code modifications:

First, it's necessary to hook up into the host OS multimedia system in order to get notified when new devices are added or old ones removed. If the OS doesn't provide a notification API, a poll loop with sensible frequency settings will need to be used.

• Currently, this is already achieved in Mac OS X through the AudioHardwareAddPropertyListener function in Core Audio API.
• In Windows platforms (under WMME hostapi), WM_DEVICECHANGE OS messages are used.
• Each of the rest of platforms (or corresponding hostapis) will need their own implementations too.

Second, the hostapi needs to react to the DevicesChanged notification, by updating the internal audio devices data (after which PortAudio will proceed to notify upper layers about the availability of a new devices list). This is achieved through the RescanDevices function.

• Mac OS X hostapi, Core Audio, already updates its internal devices list with RescanDevices().
• Windows WMME hostapi includes its own RescanDevices() function, based on the implementation provided in PortAudio mailing list.
• The rest of platforms and hostapis will need their own implementations.

To Be Improved¶

• Get notified and synced to system devices list when "default device" is changed in Windows control panel.
• 5% left in tweaking hardware/driver settling times. Basically, taking different audio hardware, and calculating how much time it takes to settle in the worst case. This would allow badly designed hardware/drivers (those that don't notify when device has finished being detected by OS) to be detected in all cases.
• 10% left if the processing of OS messages is parallelized. Currently, messages are enqueued one after another, instead of being processed as they come (which parallelizing would allow). End user would not see any improvement at all, but it would be slightly cleaner from a coding perspective
• 10% left in treating a rare case: current code remakes the devices list only if the number of devices has changed. It would in theory be possible to very quickly replace an audio device (or add/remove in different ports), so that the number of devices remains the same. It's very unlikely a regular user will ever encounter it. I've tried to trigger the bug on purpose, in order to know what the consequences would be, but I haven't been able to (who knows, it may even continue working correctly, except for minor details like old device names being shown in the UI instead of new device names, etc).