Closed gchilds closed 3 years ago
Yes, Proxy Audio Device is breaking some rules and doing some hacky things. I went out of my way to have any calls to the HAL API happen in a separate thread, with my thinking being that it's a similar circumstance to calling them from another process. So far it seems to prevent deadlocks and hasn't caused any issues. Hopefully it stays that way. If something goes wrong then what happens is coreaudiod deadlocks, which of course is not great, but not the end of the world either. I did it several times in the course of developing the plugin.
The benefit is that this doesn't require a separate process to do the actual proxying of audio from one device to another. And doing so would require another buffer (I think), introducing further latency, and I wanted to keep latency as low as possible.
(If you want to see a total hack, check out the way the configuration app passes data to the driver. I know I could've done it the right way by having an intermediate launch daemon, but it seemed like so much work and boilerplate just to be able to pass a simple configuration to the driver.)
The strings? I saw! I think the whole thing is fantastic! Best AudioServerPlugin I’ve seen yet.
Building play through into the audio server plugin is incredibly convenient... but isn't HAL access from the plugin unsupported?
From
AudioServerPlugin.h
:This document says "HAL" includes anything in
AudioHardware.h
, e.g.AudioDeviceStart
: https://developer.apple.com/library/archive/documentation/MusicAudio/Conceptual/CoreAudioOverview/WhatsinCoreAudio/WhatsinCoreAudio.html So technicallyproxy-audio-device
should expect this "generally bad, undefined" behaviour. Yet it in practice it seems to work fine. Is the only danger the occasional deadlock?