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.
Børge
On Sun, Mar 20, 2016 at 1:15 PM, Børge Strand-Bergesen
<borge.strand@xxxxxxxxx> wrote:
Hi Clemens,******************
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
0x0000.
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
0x0000.
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
volume down.
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?
Thanks,
Børge
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> wrote:
Børge Strand-Bergesen wrote:
What I see in the Device firmware debug terminal is get_min value of
0x8000
This would be valid only for GET_CUR.
Pardon?
The value 0x8000 is not allowed for GET_MIN. See table 5-8 in section
5.2.2.2.3.
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.
Regards,
Clemens
******************
WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/
