AudioDeviceDetection

Version 14 (Anonymous, 08/24/2010 09:34 am)

1 1 Adrian Georgescu
2 14 Adrian Georgescu
h1. Audio Device Detection
3 1 Adrian Georgescu
4 1 Adrian Georgescu
5 14 Adrian Georgescu
6 14 Adrian Georgescu
7 14 Adrian Georgescu
8 14 Adrian Georgescu
h2. Introduction
9 14 Adrian Georgescu
10 14 Adrian Georgescu
11 4 Adrian Georgescu
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.
12 1 Adrian Georgescu
13 4 Adrian Georgescu
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.
14 1 Adrian Georgescu
15 4 Adrian Georgescu
16 1 Adrian Georgescu
17 14 Adrian Georgescu
h2. Goal
18 1 Adrian Georgescu
19 1 Adrian Georgescu
20 14 Adrian Georgescu
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":/issues/show/117.
21 1 Adrian Georgescu
22 1 Adrian Georgescu
23 1 Adrian Georgescu
24 14 Adrian Georgescu
h2. Schematic Overview
25 1 Adrian Georgescu
26 14 Adrian Georgescu
27 14 Adrian Georgescu
!{ width:102px4}wiki:AudioDeviceDetection:SipSimpleAudioDevicesChange.png!
28 14 Adrian Georgescu
29 14 Adrian Georgescu
30 14 Adrian Georgescu
31 14 Adrian Georgescu
h2. Required Modifications
32 14 Adrian Georgescu
33 14 Adrian Georgescu
34 11 Adrian Georgescu
After a first analysis of the SIP SIMPLE client SDK and dependencies, these are the necessary PortAudio code modifications:
35 4 Adrian Georgescu
36 4 Adrian Georgescu
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.
37 14 Adrian Georgescu
* Currently, this is already achieved in Mac OS X through the @AudioHardwareAddPropertyListener@ function in Core Audio API.
38 14 Adrian Georgescu
* In Windows platforms (under @WMME@ hostapi), @WM_DEVICECHANGE@ OS messages are used.
39 14 Adrian Georgescu
* Each of the rest of platforms (or corresponding hostapis) will need their own implementations too.
40 11 Adrian Georgescu
41 14 Adrian Georgescu
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.
42 14 Adrian Georgescu
* Mac OS X hostapi, Core Audio, already updates its internal devices list with @RescanDevices()@.
43 14 Adrian Georgescu
* Windows WMME hostapi includes its own @RescanDevices()@ function, based on the "implementation":http://osdir.com/ml/audio.portaudio.devel/2007-02/msg00094.html provided in PortAudio mailing list.
44 14 Adrian Georgescu
* The rest of platforms and hostapis will need their own implementations.
45 12 Adrian Georgescu
46 12 Adrian Georgescu
47 14 Adrian Georgescu
h2. To Be Improved
48 14 Adrian Georgescu
49 14 Adrian Georgescu
50 14 Adrian Georgescu
* Get notified and synced to system devices list when "default device" is changed in Windows control panel.
51 14 Adrian Georgescu
* 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.
52 14 Adrian Georgescu
* 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
53 14 Adrian Georgescu
* 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).