I wanted to use the ADCMD_LOCK command with audio.device but I couldn't get it to work. I use the audio.device open allocation feature. Then send the lock command. According to the docs a successful ADCMD_LOCK command won't reply unless the channels are stolen. But in my testing it replied straight away with a zero error.
My intent was to use the lock feature to be notified of stolen channels. As I wanted to be notified of what clients allocated and freed audio. This looked like a clean solution but I've been unable to get it working and don't know of any example code.
This is on my X1000 where it's faulty. But I tested audio.device from OS3 and OS4 classic via emulation and they work as expected. As in the lock doesn't reply back. So it looks it may only affect the AHI based audio.device but it is in DEVS so I would have expected a shared version.
So, unless someone can demonstrate how to get the OS4 version working, I'll be forced to hack the audio.device. I was avoiding patching it but I see no other choice than to play dirty. :-)
After finding out the answer, the answer is no. The OS4 audio.device has a permanent bug because ADCMD_LOCK just politely replies right back and then does nothing. Being the audio.device was last updated in 2014 and I'm the only person I know who had a problem with it I don't expect it to be fixed anytime soon. I'll be unable to use audio.device to manage clients then. If need be I'll write a patch that will keep track of audio.device clients.
THX. Added BZ entry #10472 so it doesn't get into oblivion.
Thanks for noticing. Also see BZ #10411. :-)