The missing volume control protocol was what kept it from working on iOS and UAC1. Now both protocols work on all OSes. In the fw it was quite tricky to come up with the casting notation which compiled into a 32x32=64 mult. Don't touch that code without verifying it in the list file.
On my Mint 17 box with mpd UAC1 has true volume control in the DAC but UAC2 has digital volume control in the host. (Not that the effect is much different, but the principle surely is.) I seem to remember more or less the same being the case on Android. I haven't yet tested volume with the preliminary Windows UAC2 driver.
The way to test this is to compare the volume control fw to the 0dB file of the same date. Both use the same volume protocol interaction with the Host, but the 0dB file doesn't perform any volume multiplication. So if the computer's volume slide influences the output on the 0dB file, this means it is the computer doing the volume change. Mind that on some systems pulling the slide all the way down will evoke mute, something the fw handles separately from the volume control multiplication.
I have a feeling Linux implements volume differently in UAC1&2. But I haven't yet told any kernel people.
UAC1 uses primitive dithering after volume multiplication. On 192 the present RNG uses too many CPU cycles, so I bluntly disabled dithering in UAC2 for now. A faster RNG could do the trick. I just pulled one off the net more or less at random :-)
Børge