Is the volume control being presented by usbaudio.sys to Windows at all? If
not, Windows will inject a volume APO in software.
Please run the devicetopology.exe attached this blog post and send the output:
https://blogs.msdn.microsoft.com/matthew_van_eerde/2014/11/20/walking-the-idevicetopology-tree-to-see-audio-driver-settings/
Alternatively, a screenshot from KS Studio would work.
Or you can go into the Levels tab for the device in the Sound control panel;
right-click the slider; choose “decibels”; then drag it all the way to the left
and the right to discover the minimum and maximum decibel values for the slider.
From: Børge Strand-Bergesen<mailto:borge.strand@xxxxxxxxx>
Sent: Friday, March 18, 2016 4:43 PM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] UAC1 driver sends volume:0000
Hi guys,
I'm debugging a UAC1 interface to make the Device respond to volume
control signals from the Host. Could you help me figure out why
Windows doesn't seem to alter the volume setting it sends out? Beside
the volume control issue the Device is a fully functional DAC.
Mute control works in Windows. The device receives 0x01 for mute on,
0x00 for mute off. But for the volume setting I keep receiving 0x0000
from Windows 7 when I pull the volume control bar for the device up
and down. Windows is clearly conveying a volume setting for each user
interaction, just not the right one. I'm trying to figure out why.
Repeating a similar action on iOS and Linux I receive a variable
volume setting into the device. iOS does give out a variable volume
setting, it just does not seem to be in accordance with the min and
max values. So Windows and iOS are confused in different ways by what
is perhaps the same bug.
Linux is the most forgiving of the three and gives out variable volume
within the min and max bonds. I haven't yet tested with OS X.
The volume control system is based on Atmel mcu code which responds to
such things as
#define BR_REQUEST_GET_CUR 0x81
#define BR_REQUEST_GET_MIN 0x82
#define BR_REQUEST_GET_MAX 0x83
#define BR_REQUEST_GET_RES 0x84
#define BR_REQUEST_SET_CUR 0x01
#define BR_REQUEST_SET_MIN 0x02
#define BR_REQUEST_SET_MAX 0x03
#define BR_REQUEST_SET_RES 0x04
With a debug terminal in place it's clear Win7 connects to the Device
with a sequence of get_cur_mute, get_cur_volume, get_min, get_max,
get_res, get_cur_volume, get_min, get_max, get_res, set_res,
set_cur_vol, set_cur_vol etc. From what I can see in the debug
terminal the Device seems to be outputting reasonable values.
Importantly, Windows doesn't attempt any set_min, set_max or set_res.
When I pull the volume slide up and down in Windows there is no
get_cur, only a lot of set_cur_volume with a parameter stuck at
0x0000. Pulling the slide in Linux produces a lot of set_cur_volume
with a variable parameter. For each volume change with the button of
an iPhone, iOS performs a sequence of get_min, get_res,
set_cur_volume.
Thanks,
Børge
Thanks,
Borge
******************
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/
