I simplified the descriptor to only supporting 44.1 and 48. Mac OS has no
problem with interpreting it and presenting the valid rates.
Win10 reads the descriptor but does not give me a choice of sample rate. It
stays fixed at 44.1. It asks for 0x0100 bytes or descriptor, and I send it
0x0E. That transaction looks perfectly fine. (Any attempts with funny
descriptor lengths failed, as expected, but I had to try.)
So the story remains the same. Something prevents Win10 C.U. from
attempting to change my sample rate. The frequency rate descriptor looks
Is the UAC2 driver code available? Or are there people here who could help
me access a verbose log from it?
On Wed, Jul 5, 2017 at 9:29 AM, Tim Roberts <timr@xxxxxxxxx> wrote:
On Jul 4, 2017, at 12:24 PM, Børge Strand-Bergesen <borge.strand@xxxxxxxxx>
bytes. That doesn't seem to make the driver very happy.
Yes, the Device code looks at the 16 bit value and tries to serve up 256
You don't actually have 256 bytes of descriptor, do you?
I don't know why the driver requests 0x0100 bytes of frequencydefinition. For flesh-and-blood beings it would however make sense to first
ask for one bytes and use that to determine the number of triplets.
Although the number of triplets, too, is a 16-bit number.
It's an optimization. You assume the descriptor will not be more than 256
bytes, so you allocate 256 and try that. If it fails, you allocate larger
and try again. Same way you fetch the configuration descriptor.
Now, I'm not saying there is a bug in the driver. I'd just very muchlike to know what I should give it when it asks for 0x0100 bytes. And I'd
like to know if it asks for that because of some other bug in my
You deliver min( actual descriptor length, what they asked for ).
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.