Clemens and Matthew,
thank you very much for your help! After a reboot I now have the
expected behaviour on Windows. In the meantime I've got improved
descriptors and a significant knowledge boost.
I'll now move on with the UAC2 volume control protocol and then the
actual DSP implementation.
On Sun, Mar 20, 2016 at 1:59 PM, Børge Strand-Bergesen
Things just got strange....******************
I tried on a different and rather Win7 machine and got the expected
behaviour from set_cur.
So this means the trouble probably isn't in the firmware but in my
computer. It is pretty loaded with audio and debug stuff, and I'm
running Tidal in Chrome (WASAPI exclusive) as the audio source. That
may be why it's sending out 0000.
On Sun, Mar 20, 2016 at 1:15 PM, Børge Strand-Bergesen
I may have come to some realization here, see below.
I've implemented your suggestions with bDeviceClass = 0 and a
realistic dB range. Endpoint 0 I have left as-is because I believe it
is needed for a legacy control interface in the firmware.
With min=0xC400 (-60dB), max=0x00 (0dB), res=0x00A0 (0.5dB) I get
spot-on behavior from iOS, OS X and Linux. But Windows keeps giving me
All three are able to send the mute control.
I've toyed around with some settings and it seems my Windows system
does set_cur_volume according to:
if (min > max) send 8000
elseif (max > 0000) send 0000
else send max
I have attached updated descriptor files, captured on Linux and with tdd.exe.
I've tried to correlate this with the wValue contents for the
different channels. Setting the volume from the keyboard of my Mac, OS
X sends individual L and R volume data with lsB(wValue) set to 1 and
then 2. It sends 16 bits of proper volume control data each time. I
can also adjust L and R individually, which also works as expected.
OS X and iOS both do get_min, get_res, set_cur on L and then on R.
Both volume control data within range.
Linux and Windows don't seem to do any get_* operation before set_cur.
Both send L first and then R. Linux with expected data, Windows with
Now, when I click the bottom-right speaker icon in Windows and pull
the slide up and down, the slide moves while Windows sends L0000 and
R0000. The slide will remain where I released it the next time I open
the same control. BUT when I use the volume up and down buttons on my
keyboard, Windows keeps sending L0000 and R0000 whenever I click
volume down, but the bar doesn't move! The bar remains at its maximum
position, and there is no response in the firmware to volume up, only
This makes me wonder: Is there a missing get_cur somewhere? iOS and OS
X clearly do get_cur for each volume setting. I don't see Windows
attempting any get_cur, but it may very well be that such an action
isn't detected by the firmware. I was able to get quite a couple bugs
out of the code before I mailed the list in the first place, but don't
rule out that there are more.
So if someone here knows the volume control routine in detail, can it
be expected of Windows to do get_cur_volume for each set_cur_volume?
If so, how does it request that?
On Sat, Mar 19, 2016 at 2:06 PM, Clemens Ladisch <clemens@xxxxxxxxxx> wrote:
Børge Strand-Bergesen wrote:
On Sat, Mar 19, 2016 at 1:33 PM, Clemens Ladisch <clemens@xxxxxxxxxx>
Børge Strand-Bergesen wrote:
What I see in the Device firmware debug terminal is get_min value of
This would be valid only for GET_CUR.
The value 0x8000 is not allowed for GET_MIN. See table 5-8 in section
Use the actual capabilities of your hardware. If the volume is
implemented in software (DSP), use a reasonable range, e.g., from
-60 dB to 0 dB.
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
URL to WDMAUDIODEV page: