Does asynchronous USB audio use src?

[usb2.0]

In asynch USB the client controls when the usb host sends data. What happens when the client wants data faster or slower than the host can send it? How is buffer underrun/overflow prevented in the USB host? Does the host use sample rate conversion to mitigate this issue?

[xhuw]

I expect different hosts will implement this in various ways. Resampling the signal would be a sensible choice.

[MaximLiadov]

>> In asynch USB the client controls when the usb host sends data

No. "When" is not controlled. How much data in the current frame is controlled instead, and the buffer underrun/overflow issue is absent. UAC2.0 asynchronous mode doesn't use SRC at all. Bit perfect. That's the point.

[usb2.0]

>> In asynch USB the client controls when the usb host sends data

No. "When" is not controlled. How much data in the current frame is controlled instead, and the buffer underrun/overflow issue is absent. UAC2.0 asynchronous mode doesn't use SRC at all. Bit perfect. That's the point.

It is an important distinction, and I would like it to be truly bit perfect. But I don't think this is the case. The clock in the client is never going to agree with the clock from the source of the data. Inevitably one will run faster than the other. Consider the client continuously sends bits to the DAC on every clock edge. What happens when it requests 48 bits but the USB host only has 47 to send it? Suppose, for instance, the host is playing a real-time stream. The host only has 47 samples in the buffer. It would have to predict the future to get a 48th bit. So where does the host come up with the 48th bit to send? Interpolation?..

[MaximLiadov]

You are wrong. Sorry. Please google USB Audio asynchronouse mode. Speed is fixed to 480 Mbit. Frame size is variable. All others nonsense. You could easily check that it's bit perfect.

Please read this article carefully
https://www.edn.com/fundamentals-of-usb-audio/

[usb2.0]

You are wrong. Sorry. Please google USB Audio asynchronouse mode. Speed is fixed to 480 Mbit. Frame size is variable. All others nonsense. You could easily check that it's bit perfect.

Please read this article carefully
https://www.edn.com/fundamentals-of-usb-audio/

I hope I am wrong. But I have expressed my doubt. You have not explained how it is wrong and the linked article makes no claims that asynchronous mode is bit-perfect. So I could just as easily say you're wrong. And the discussion goes nowhere.

So yes the frame size is variable. But again, the USB client has the clock and it is either going to be faster or slower than the real time stream. If it is slower, then the USB host must have an infinite buffer to store all the bits that slowly accumulate. If it runs faster, then the USB host must create samples out of thin air to send the client that feeds to the CODEC so you don't hear pops through the speakers. Tell me how is this issue avoided by UAC2.0 asynchronous?

[MaximLiadov]

>> Suppose, for instance, the host is playing a real-time stream.

Why do you need any fixed hardware clock on the host side at all? All modern OSes support asynchronouse USB mode. All audio data is stored on the HDD. Media player like a foobar has an adjustable memory buffer for a few second of audio data. If you are using ADC and DAC audio device, input signals are necessarily in sync with output stream. So I see no problem in any scenario. The audio device is the master clock here. The host must be able to work at a reasonable speed and put audio data from a memory into the small USB buffer just in time, based on USB feedback. If this is not the case, you will hear a problem and need to set a correct buffer size.

If you don't use ASIO or WASAPI Exclusive, it's another story. You need a software SRC inside a mixer in OS for sure to avoid a wrong pitch. It would be bit perfect anyway.

If you don't believe me, just record a bitstream and check it in a HEX editor. No any SRC is applied inside the modern USB Audio.

[MaximLiadov]

the linked article makes no claims that asynchronous mode is bit-perfect

Please, read the article (by Henk Muller, Principal Technologist XMOS) carefully:

Hence there are at least two separate clocks in the system, the USB clock with a host driven frequency of 8,000 transfers per second, and a sample clock with an externally driven sample rate of, for example, 96,000 Hz. These clocks will have subtly different frequencies, and the difference will vary slightly over time. Hence the average number of audio samples per frames will be slightly more or less than the expected rate.

So the only problem that variable frame size addresses is USB and audio clock mismatch. Not host and device clock mismatch.

I am not as qualified as Henk Muller and could be wrong about some of the details, but I am sure the article is a great source of knowledge and USB audio does not have an internal SRC.

[usb2.0]

UAC2.0.PNG

The host does not have the MCLK. The client does. With asynchronous mode, the client sends feedback to the host to receive data at the rate needed by the MCLK. We can agree on the terminology and where the clock is.

What I'm proposing we consider is not data stored on a harddrive. Think connecting to a real-time video feed like a zoom meeting or a live broadcast video. Your OS can't just move the read pointer in the file descriptor like it can when playing back an mp3. You dont have that luxury with real-time. You only have a bounded buffer of incoming data.

[MaximLiadov]

del