Author Topic: violation for host to open audio endpoint w/o explicitly setting sampling rate?  (Read 6059 times)

rebar

  • Member
  • ***
  • Posts: 17
I have never seen this on windows systems, but I am witnessing on linux systems that the host opens audio endpoints (spkr/mic) w/o explicitly setting sampling rate?

Is there such a thing as a default sample rate or is the OS in violation for not setting the rate?

thx for any help with this,
rob

Tsuneo

  • Frequent Contributor
  • ****
  • Posts: 145
Quote
Is there such a thing as a default sample rate or is the OS in violation for not setting the rate?
On USB Audio 1.0 spec, which is popular on the current scene, I believe neither, default sampling frequency nor requirement of explicit sampling frequency control, is referred.

On the device side, there are a couple of ways to provide sampling frequency options.

1) Sampling Frequency Control
- The capability of sampling frequency control is declared at D0 bit of bmAttributes on Class-Specific AS Isochronous Audio Data Endpoint Descriptor of the current alternate AS interface, set by Set_Interface.
- Options of sampling frequencies are provided at Type I/II/III Format Type Descriptor of the current alternate AS interface
- Using Endpoint Control request, host gets/sets current/minimum/maximum/resolution of sampling frequency

2) One sampling frequency per each alternate AS interface
Single sampling frequency option is provided at Format Type Descriptor of each alternate AS interface. In this case, this sampling frequency is considered as the default of each alternate AS interface. The device may expect that just Set_Interface determines the sampling frequency.

Tsuneo

rebar

  • Member
  • ***
  • Posts: 17
thx for your comments Tsuneo - Windows uses the 1st case that you listed (and I think the best way to do it), with a "set". Although I do agree that case #2 might work, the fact that linux already has this problem of not setting the rate, I feel like linux might not even honor the sample rates of the different interfaces. I don't know. But it seems to me that the best solution is to fix the "problem" in linux. I don't see why the usb spec doesn't force setting the sample rate when an interface supports more than one sample rate. And why wouldn't linux want to take advantage of this ability to add robustness to the OS.

rob