The OS send the volume range request one time on enumeration. I even tried
to use the audiocontrol interrupt endpoint to request OS to grab one more
time. It did come, but now the sound control now shows the 2nd range that I
gave. The OS does not seems to accept multiple volume ranges.
My device have hardware buttons to control volume which have its own range
and resolution. Currently I always use the audiocontrol interrupt endpoint
to ask the Os to snap to our device volume. Only recently found a bug which
only happen on MacOS, the current volume will keeps reducing due to the
volume correction on every start/stop audio playback stream. Therefore
volume snapping on our part introduce the bug, but then we can't
synchronize the device volume and the PC sound control volume if we remove
On Thu, Dec 6, 2018 at 5:28 AM Børge Strand-Bergesen <borge.strand@xxxxxxxxx>
I see multiple OSes request 0x10 bytes for volume range.
This sounds like something that has to be tested in detail on all relevant
operating systems. What is so special that you can’t use one range and work
it out in firmware?
On Wednesday, December 5, 2018, Tim Roberts <timr@xxxxxxxxx> wrote:
Kevin Ng wrote:
Hi, I am new here. Tried searching through the list and unable to find
some similar to the above.
So I am trying to specify a multiple volume range control with different
volume resolution for each volume range.
I understand what is required to send back the feature unit volume range
request command from the host PC (Windows 10/MacOS). But the problem is the
host PC only allow 8 bytes of data length to be sent back for the volume
range command. Anyone have any idea how to implement this?
Interesting. I would expect it to make one request of 8 bytes, then make
another request based on the wNumSubRanges you returned. That's the usual
protocol for variable-length layouts. Do you not see the second request?
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
URL to WDMAUDIODEV page: