Does asynchronous USB audio use src?

[AlexAdvice]

You dont have that luxury with real-time. You only have a bounded buffer of incoming data.

If the host can fill the buffer (FIFO) a little faster than the client can read it, everything is fine - you will have full bitperfect. The host is only required to slow down its streaming, on feedback commands from the client, to avoid buffer overflow.
(This is a very simple explanation, without details, but this is the principle, and no src is required for this)

[Ross]

The device is the clock master and essentially dictates the speed of playback from the host. The host is required to have some sort of controller to track the rate of the device.

Using this scheme all transfers between device and host can be "bit-perfect", without SRC, and use a "high-quality" local clock, or an externally sourced clock such as one derived from a digital stream such as S/PDIF etc (you could argue this is the most important, practical usage).

That deals with the local “bit perfectness” only. Your follow up question seems to be concerned with a potential larger system context, which is something we cannot control. If playing from a streamed service (some “bit perfect” services do exist eg tidal), say, the higher level “stack” would have to maintain a full buffer for the playback app, typically large buffers are less of an issue for host pcs anyway.. It’s not really a “real time” stream, per se (depends on your definition..), just streaming from a disc that’s remote. The data is compressed - lossless in the case of services like Tidal - so the data needs to remain "perfect" otherwise large artefacts will be present. It's not really "audio" at this point, just "data".

I think the zoom example is a bit an odd one. If it’s truly peer to peer with async both ends then clearly something needs to patch up/sync those two clocks. In terms of quality you could argue that it's not a great high-level system design - something like AVB would be good here. However, for he masses and it's use case quality can be side-lined in favour of capability, availability and ease of use.

It likely uses a combination of buffering, time-stamping, and adaptive synch for the transmission between two devices - you cannot SRC compressed data. There are protocols to help with this e.g. RTP. Some "SRC" is almost certainly required in the chain somewhere - for this sync reason and also general usability issues, the two ends could be running on a different SR, maintaining compatibility, etc... In the case of Zoom, I don't know which end that would happen, receiver end seems sensible (group calls).

Regardless, in this case sample modification in this use case seems of little consequence anyway, It’s not as if there is some master source you are trying to deliver and share so being “bit perfect” has little relevance - so long as the subjective quality of the data is acceptable and compatibility between devices is maximised. However, the local async does still retain the ability to return “bit-perfectness” from what ever is received from the “far end”. Again, bear in mind, no ones streaming raw audio in these systems, it's always compressed (potentially loss-less) but there are systems for "properly" distributing timed audio over networks.

In summary, "locally", no SRC is required, in the context of some huge system, yes, it might be employed.

[Joe]

I think everyone has valid points here. We should be specific about what level of the hardware/software stack we're talking about.

In terms of usb audio, for async mode, the driver and usb architecture is such that it should be bit perfect and no SRC ever takes place.

At the higher levels of the OS, sometimes SRC (or dropping samples etc.) might have to take place to cater for certain scenarios but this would be the exception not the norm.

As mentioned an example would be a livestream to two PCs each running async USB. Eventually they will get out of step as running at slightly different rates and something in the chain will have to drop samples or SRC. This might be on the PC or from the far end.

Another example would be two async USB devices plugged into the same PC.

These are some of the reasons OS' don't particularly like async usb streams and would prefer you used adaptive to make these kind of synchronisation issues easier for the host.