Mac OS X 10.11 El Capitan: Using deprecated Carbon Component Manager

[herrbischoff]

While compiling and running cmus via homebrew on Mac OS X 10.11 GM Candidate with Xcode 7, the following notice is displayed whenever first starting playback of audio:

This application, or a library it uses, is using the deprecated Carbon Component Manager for hosting Audio Units. Support for this will be removed in a future release. Also, this makes the host incompatible with version 3 audio units. Please transition to the API's in AudioComponent.h.

I believe this should be addressed to keep compatibility with future OS releases.
Let me know if you need more details and what about.

[flyingmutant]

You are using libao (ao output plugin), right? This notice is probably about it, and there is not much we can do aside from hoping libao will update in the near future.

Can you please check if jack output plugin is OK on 10.11?

[herrbischoff]

Correct, the standard for Homebrew appears to be ao.

I tried to use the jack plugin, I remembered that from using muc
back then. Unfortunately I was not able to activate it. jack is
installed, I rebuilt cmus from the master branch afterwards with brew reinstall cmus --HEAD but when trying to set the output plugin via
:set output_plugin=jack, all I get is the following error:

Error: selecting output plugin 'jack': no such plugin

Any idea what is wrong?

On 15/09/14, Gregory Petrosyan wrote:

You are using libao (ao output plugin), right? This notice is probably about it, and there is not much we can do aside from hoping libao will update in the near future.

Can you please check if jack output plugin is OK on 10.11?

---

Reply to this email directly or view it on GitHub:
#331 (comment)

[nefthy]

The jack plugin is probably not installed. Do you have the jack header files installed?

[herrbischoff]

@nefthy: I double-checked just a minute ago. They are indeed installed in /usr/local/Cellar/jack/0.124.1/include/jack, which appear to be identical to those found here.

Interestingly, compiling by hand (not via homebrew) finds those during the ./configure run:

checking for JACK_LIBS (pkg-config)... -L/usr/local/Cellar/jack/0.124.1/lib -ljack -lpthread -framework CoreAudio -framework CoreServices -framework AudioUnit
checking for JACK_CFLAGS (pkg-config)... -I/usr/local/Cellar/jack/0.124.1/include

This does indeed result in the creation of the jack.so plugin. Manually copying it to /usr/local/Cellar/cmus/HEAD/lib/cmus/op makes it available and it runs as expected.

I should probably go though the homebrew build process to fix it and submit a pull request adding jack support.

Reading deeper into jack, I was also able to get it to run with my external USB audio interface. It requires running jackd -d coreaudio -l to get the device name. In my case it was

'AppleUSBAudioEngine:Griffin Technology, Inc:iMic USB audio system:14220000:2,1'

which results in a highly unintuitive command:

jackd -d coreaudio -d 'AppleUSBAudioEngine:Griffin Technology, Inc:iMic USB audio system:14220000:2,1'

Although running this, still yields:

This application, or a library it uses, is using the deprecated Carbon Component Manager for hosting Audio Units. Support for this will be removed in a future release. Also, this makes the host incompatible with version 3 audio units. Please transition to the API's in AudioComponent.h.

It appears that also jackd needs to be updated. However, when being run through a LaunchAgent, those warnings are essentially never output, so that's good. Hopefully this helps someone with the same issue as me.

Here's the LaunchAgent that homebrew installs, modified for my use:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>homebrew.mxcl.jack</string>
  <key>WorkingDirectory</key>
  <string>/usr/local/Cellar/jack/0.124.1</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/opt/jack/bin/jackd</string>
    <string>-d</string>
    <string>coreaudio</string>
    <string>-d</string>
    <string>'AppleUSBAudioEngine:Griffin Technology, Inc:iMic USB audio system:14220000:2,1'</string>
  </array>
  <key>RunAtLoad</key>
  <true/>
  <key>KeepAlive</key>
  <true/>
</dict>
</plist>

[flyingmutant]

@herrbischoff, thanks a lot for the detailed writeup, I am sure people will find it useful (esp. the LaunchAgent configuration). I'm closing this issue however, since there is not much cmus can do to fix it.

[herrbischoff]

@flyingmutant: Indeed. I just opened an issue in the Jack Audio repo and notified the maintainer of the libao code so they know about it.

[snide]

Hey @herrbischoff. Just wanted to say thanks for taking the time to walk through the problem above. Ran into a similar problem myself and it was super helpful.

[hanshasselberg]

I found another way to 'fix' this problem: cmus 2> /dev/null.

[klepas]

[And thus I learn about directing std-in, -out, and -err. Thanks @i0rek (: ]

[Wang-Yue]

there's a ticket in libao's bug tracker for 5+ months. seems the maintainer is not actively developing it. It's basically rewriting this function (https://github.com/timonwong/libao/blob/master/src/plugins/macosx/ao_macosx.c#L411) to use CoreAudio API, which probably would only take 1-2 hours.

[flyingmutant]

Just a friendly reminder to anybody with enough interest and free time on hands — native CoreAudio output plugin for cmus would be greatly appreciated.

[Wang-Yue]

A native CA plugin would be nice. I can help. But I don't have too much free time... It could take up 6-10 hours. I will probably do it during this new year if I have time...

[Wang-Yue]

PR #374 should solve this bug.