The old code fetched the channel name via AudioObjectGetPropertyData()
and accessed the "returned" data as a plain char buffer.
This may or may not have worked at some point according to the Apple
CFString documentation, which warns that the actual data layout is an
implementation detail and subject to change at any time.
On recent OS X versions, this behavior led to "random data" channel
names like >H��{, H��{<.
We need to actually let AudioObjectGetPropertyData() populate a CFString
struct and convert this into a plain char buffer.
The conversion function will also free the CFString if conversion to a
plain C string succeeded to not leak memory.
Signed-off-by: Mihai Moldovan <ionic at ionic.de>
---
src/modules/macosx/module-coreaudio-device.c | 47
++++++++++++++++++++++++++--
1 file changed, 45 insertions(+), 2 deletions(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-module-coreaudio-device-get-channel-name-as-CFString.patch
Type: text/x-patch
Size: 3326 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20150419/2a12bc7a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20150419/2a12bc7a/attachment.sig>
