After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 759558 - osxaudiosrc/osaudiosink uses non-unique identifiers as device ID
osxaudiosrc/osaudiosink uses non-unique identifiers as device ID
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
Other Mac OS
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-12-16 17:30 UTC by Marcin Lewandowski
Modified: 2018-11-03 15:06 UTC
See Also:
GNOME target: ---
GNOME version: ---

WIP: Add device-uid property (6.27 KB, patch)
2016-07-04 21:30 UTC, Marcin Lewandowski
none Details | Review

Description Marcin Lewandowski 2015-12-16 17:30:52 UTC
It seems that current version of osxaudiosrc/osxaudiosink handles "device" parameter in a way that may be ambiguous in some setups.

It expects that device ID that is passed is a numeric ID, such as obtained by running "say -a ?". This is however, inaccurate, as such device ID is not Core Audio UNIQUE identifier.

In some setups that's fine, for instance my setup is like that

$ say -a ?
   50 Built-in Output
   60 Z-10 USB Speaker

However, depending to which USB port I plug my USB Speaker I get this UID from CoreAudio:

AppleUSBAudioEngine:Logitech:Z-10 USB Speaker:fd120000:1

or this

AppleUSBAudioEngine:Logitech:Z-10 USB Speaker:fa130000:1

(this is the code used to query)

CFStringRef     uid;
propertySize = sizeof(uid);
deviceAddress.mSelector = kAudioDevicePropertyDeviceUID;
deviceAddress.mScope = kAudioObjectPropertyScopeGlobal;
deviceAddress.mElement = kAudioObjectPropertyElementMaster;
if(AudioObjectGetPropertyData(deviceIDs[idx], &deviceAddress, 0, NULL, &propertySize, &uid) == noErr) {

In some setups, especially in pro audio/broadcasting environments it may be necessary to use very precise reference to avoid issues if two devices of the same type are plugged in.

To avoid API break, I suggest adding a boolean parameter "device-is-uid" that will indicate whether interpret "device" like now or with exact uid, or another string parameter "uid" that can be used in exchange of "device".
Comment 1 Marcin Lewandowski 2015-12-16 17:38:05 UTC
Moreover, this can be more dangerous.

If I unplug my Z-10 USB Speakers and plug something else, the same ID gets allocated by totally another device.

$ say -a ?
   50 Built-in Output
   60 Sennheiser USB Headset

So I you build let's say, a DAW that should remember it's audio interface routing setup (it's painful to rebuild it every time) and be smart enough that if user plugs a device during runtime it is capable of recognizing it, now you can

a) store IDs in the routing configuration but you can never be sure if they mean the same soundcard as was used before
b) rely on device names

both options are unreliable.

Moreover if I plug two of these three devices, then unplug one of them, ID of them can change in the runtime!

(plug Sennheiser USB)

$ say -a ?
   50 Built-in Output
   60 Sennheiser USB Headset

(plug Z-10 USB Speaker)

$ say -a ?
   50 Built-in Output
   68 Z-10 USB Speaker
   60 Sennheiser USB Headset

(unplug Sennheiser USB)

$ say -a ?
   50 Built-in Output
   60 Z-10 USB Speaker
Comment 2 Sebastian Dröge (slomo) 2015-12-17 09:13:01 UTC
My idea would be to just add a device-uid property additionally (that is of type string). And whenever that is set to non-NULL it would be used instead of the (integer typed!) device property.

We can't really change the type of the existing property at this point, but we could deprecate the old property to make people aware of it being a bit suboptimal.
Comment 3 Marcin Lewandowski 2015-12-17 10:07:33 UTC
Sounds perfect!
Comment 4 Marcin Lewandowski 2016-07-04 21:30:07 UTC
Created attachment 330871 [details] [review]
WIP: Add device-uid property

This is work in progress but comments are already welcome.
Comment 5 GStreamer system administrator 2018-11-03 15:06:47 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: