Ports and Interfaces > USB

UAC 1.0 Record/Playback sample rate conflict

(1/3) > >>

jb:
Our project is USB Audio Class 1.0 Full Speed with playback and recording interfaces which can be used at the same time, and should work with the OS built-in drivers.

Our CODEC only supports a single sample rate for both input and output (which is the most common way these are used).

There are only 3 alt settings for each interface: 0 bandwidth, 16-bit, and 24-bit.  It's asynchronous in and out with explicit feedback.

In Mac OS X, changing the sample rate of input also changes output, so there is no problem, but in Windows it can be set to record and play at different rates.  Our hardware doesn't support this, and our firmware fails in this case.

The manufacturer's suggested solution is to ignore input alt setting changes while the output is playing and vice versa.  (The ignored endpoint sends NAKs, if I understand correctly.  Bus analyzer shows "periodic timeout" and recording software just stalls, for instance.)   

This doesn't seem like the best method, though, since it will also ignore a good change by the user, too (correcting the sample rate of one interface to match the other during playback) and some OSes send all zeros on the endpoints continuously even when you're not actively playing or recording, which prevents anything from being changed.

(Also, the alt setting change and sample rate request are technically independent, right?  Though it seems every OS sends both at the same time, even if the alt setting has not been changed.)

Any suggestions on how to handle this better?

(I think UAC 2.0's clock descriptors would prevent the computer from requesting this?  But Windows doesn't support UAC 2.0 yet.)

Also we aren't technically required to honor a Set sampling rate request (5.2.3.2.3.1 Sampling Frequency Control), but Windows and OS X both assume that we have, and never send a Get sample rate request to confirm that it was changed, so they send the wrong rate of data.

jb:
Hmm..  USB Complete says


--- Quote ---Isochronous transactions don’t use NAK because they have no handshake packet for returning a NAK. If a device or the host doesn’t receive transmitted isochronous data, it’s lost.
--- End quote ---

Yet ours seems to be sending NAKs, but maybe I'm reading the bus analyzer incorrectly.


Anyway, it also says


--- Quote ---On receiving an unsupported control-transfer request, the device returns
STALL in the Data or Status stage. The device also returns STALL if the device
supports the request but for some reason can’t take the requested action. For
example, if the host sends a Set Configuration request to set the device configuration
to 2, and the device supports only configuration 1, the device returns STALL.
--- End quote ---

So if we support sample rate requests, but not the particular sample rate that was requested at that time, we should return STALL to indicate this?

jb:
Seems like this is the right thing to do.  UAC1.0 says:


--- Quote ---In principle, all requests are optional. If an audio function does not support a certain request, it must
indicate this by stalling the control pipe when that request is issued to the function.
--- End quote ---

When I do this, the OS gives up and switches the interface back to zero bandwidth setting, which seems ok.

Jan Axelson:
I agree this sounds like a reasonable way to handle it. Thanks for reporting what you tried.

jb:
Does this implementation look right?

Playback is already active.  Computer turns on recording interface, then does a set sample rate request.  Setup stage completes, then Data stage (which contains the requested sample rate), at which point the device decides that the requested sample rate conflicts with the already active stream, so it STALLs during the Status stage.  The computer then gives up and turns the recording interface back to zero bandwidth.

Navigation

[0] Message Index

[#] Next page