HAL virtual device: how to "proxy" microphone

Question

I`m trying to create "virtual microphone", that should work "in front" of default input device/microphone. So when user select "virtual microphone" as input (in Audacity, for example) and starts to record sound - Audacity will receive samples from virtual device driver, that was taken by driver from real/default microphone. So "virtual microphone" is a kind of proxy device for real (default/built-in/etc) one. This is needed for later processing of microphone input on-the-fly.

So far i created virtual HAL device (based on NullAudio.c driver example from Apple), i can generate procedural sound for Audacity, but i still can not figure out the way to read data from real microphone (using its deviceID) from inside driver.

Is it ok to use normal recording as in usual app (via AudioUnits/AURemoteIO/AUHAL), etc? Or something like IOServices should be used?

Documentation states that

An AudioServerPlugIn operates in a limited environment. First and foremost, an AudioServerPlugIn may not make any calls to the client HAL API in the CoreAudio.framework. This will result in undefined (but generally bad) behavior.

but it is not clear what API is "client" API and what is not, in regard of reading microphone data.

What kind of API can/should be used from virtual device driver for accessing real microphone data in realtime?

Maintenance

Do you have any sample code to look at? There are some core audio api's for combining different inputs you might be able to leverage for what you're trying to accomplish. – Taw

Hi @IPv6, I am at the same cross-roads as you were 9 months ago. I have my "Dummy Mic" device up and running in HAL (based on NullAudio.cs) and am trying to figure out how can I route Built-in Mic's stream into my "Dummy Mic". I hope you were able to find a way forward. I was thinking of building a MacOS app that runs in conjunction with the "Dummy Mic" audio driver and streams audio buffers on a port that is picked up the audio driver's thread. I hope there is a more intuitive way to achieve this. I'd appreciate it if you can share any approaches that worked for you. Thanks! – Raze

I ended up listening for Mic from inside Application itself (it just get mic audio via regular ways and conveys all the sandboxing stuff regarding audio) and then sending this audio data to driver via socket connection // So other apps that request audio from out virtual mic in fact get this audio from user-space application that listen for mic at the same time (so it should be active) – Maintenance

Hi @Maintenance I'm working on a similar project right now and got stuck at generating procedural sound. I will be grateful If you can give me a pointer or two on where/how to write my sound frames. If you prefer to jump in a chat room or answer this as a separate question on SO, I can do that too. Thanks in advance. – Diez