Comment by theamk
5 months ago
Not sure if that's related to Apple's original problem, but in the scenario you are describing, the fix is trivial: detect when level commands are dropped and retry (up to N times / for up to X milliseconds). And don't forget to check existing volume between steps 1 and 2, so you can be made sure what the previous state was.
I don't think the "fighting" will be a problem at all - you'd have to to press volume control on device and on Mac at the same time, within milliseconds. And in the worst case, you'll run out of retries, and it will be no worse than situation today.
Who should detect, who should retry, and how?
I don’t know the macOS audio stack in detail, but I work on state synchronization problems in distributed systems and my intuition for problems like this is that the “why not just” solution almost never solves such a bug completely.
This is not a distributed system though, it's a local device, attached by USB or on some bus. So: who should detect? device driver. Who should retry? also device driver. How? by re-issuing the same request.
I've made drivers for badly designed hardware, and it's really not not that hard when you control the pieces. I mean, if it was Windows with all that backwards compatibility stuff and drivers written by 3rd party manufacturer than sure, it could be hard.. but Apple controls entire software stack, so they have no such excuse.
And the most important part is that the problem is very error-tolerant. Sure, having random balance change once per day is super annoying. But instead, imagine having one random volume change command per day be ignored.. People would not even notice, it would be a great improvement.
> This is not a distributed system though
Are you sure? Audio volume is usually not (only) controlled in the device driver. Modern OSes usually have some type of audio mixer, often in user space. I'm pretty sure that this is actually where the problem lies, not in the hardware driver (given that it also persists across reboots).
This means you need IPC, and depending on how your API looks like, that's not that trivial to do right for inherently non-atomic operations.
A proper fix could be e.g. moving to a system where the IPC call is of the form "decrease global audio volume by 10%" and is executed atomically by the OS audio mixer, but that could well require backwards-incompatible changes. And...
> Apple controls entire software stack, so they have no such excuse.
Even Apple can't break backwards compatibility with all existing audio applications.