Comment by theamk
5 months ago
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.