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