I can try to shed some light on the difference between asynchronous and synchronous USB audio. In simple terms, the difference between the two modes is about who is in charge of the audio sample clock: in synchronous USB the source's sample clock is the master, whereas in asynchronous USB the sink's clock is the master.
To explain this in more detail, we have to think about the different kinds of clock that might be present in a system where a source (e.g. streamer) sends audio data over USB to a sink (e.g. a DAC, such as a Devialet amp).
First, the source will have a clock at which it naturally generates audio samples. This will probably depend on the stream it's decoding or the format of the file it's playing. For the sake of argument, let's assume it's 48 kHz.
The source has to somehow communicate to the sink that it wants to play a 48 kHz audio stream, and the sink will then know that it has to be using a 48 kHz sample clock as well. The USB audio class defines a way to do this, but exactly how it does so isn't important for understanding the difference between synchronous and asynchronous USB audio. At this point the sample size or "bit depth" (for example: 16 bits, stereo) is also agreed.
Once the sample rate is agreed, the source will start sending samples to the sink over USB. There is another clock involved here: the audio samples are not sent evenly at a rate of one every 20.8 microseconds (48 kHz), but in "bursts" (frames/micro-frames) defined by the operation of USB. These bursts are every 125 microseconds (8 kHz) on high-speed USB, which means each burst contains 6 audio samples from the original 48 kHz stream.
In synchronous USB audio, the sink locks its audio sample clock to match the rate at which USB frames arrive; in our example it "multiplies up" the 8 kHz USB frame rate to generate the 48 kHz clock it needs to "play" the audio samples. In this scheme, there could be quite a bit of jitter in the resulting audio sample clock because the USB frame clock is not especially clean.
In asynchronous USB audio, the sink generates its own audio sample clock which could be from a high-precision, low-jitter oscillator. But then the question is: how do the source and sink guarantee that their independent audio sample clocks stay in step so that they run at exactly the same rate (overall)? If they don't run at the same rate, then over a long period of time the source would be sending samples slightly faster or slower than the sink could play them, which means either samples would have to be dropped or "made up" to fill gaps.
What happens is that the sink monitors the rate at which audio samples are arriving in the USB frames, and over a period of time compares this rate to the rate it's playing them (that is, its own sample clock). If there is a difference, it sends feedback to the source telling it to slow down or speed up a bit. In this way the sample clock on the source ends up being "controlled" by the sink so that it matches the rate of the sink's sample clock. The benefit of this approach is that the sink can have a very high-quality sample clock so that samples are played back with low jitter, independently of what happens upstream.
Going back to the Devialet: I haven't used USB as an input so I'm not absolutely sure, but I'd be very surprised if it's not using the asynchronous mechanism.
One final point: you might also hear the term "isochronous transfers" used when talking about USB audio. This describes the mechanism by which audio samples are sent in bursts at a fixed rate (8 kHz for high-speed USB). Isochronous transfers are used because the audio sample data is time-critical, and needs guaranteed bandwidth on the bus; the USB specification defines isochronous transfers as the way to reserve bandwidth. Both asynchronous and synchronous USB audio is sent using isochronous transfers.
To explain this in more detail, we have to think about the different kinds of clock that might be present in a system where a source (e.g. streamer) sends audio data over USB to a sink (e.g. a DAC, such as a Devialet amp).
First, the source will have a clock at which it naturally generates audio samples. This will probably depend on the stream it's decoding or the format of the file it's playing. For the sake of argument, let's assume it's 48 kHz.
The source has to somehow communicate to the sink that it wants to play a 48 kHz audio stream, and the sink will then know that it has to be using a 48 kHz sample clock as well. The USB audio class defines a way to do this, but exactly how it does so isn't important for understanding the difference between synchronous and asynchronous USB audio. At this point the sample size or "bit depth" (for example: 16 bits, stereo) is also agreed.
Once the sample rate is agreed, the source will start sending samples to the sink over USB. There is another clock involved here: the audio samples are not sent evenly at a rate of one every 20.8 microseconds (48 kHz), but in "bursts" (frames/micro-frames) defined by the operation of USB. These bursts are every 125 microseconds (8 kHz) on high-speed USB, which means each burst contains 6 audio samples from the original 48 kHz stream.
In synchronous USB audio, the sink locks its audio sample clock to match the rate at which USB frames arrive; in our example it "multiplies up" the 8 kHz USB frame rate to generate the 48 kHz clock it needs to "play" the audio samples. In this scheme, there could be quite a bit of jitter in the resulting audio sample clock because the USB frame clock is not especially clean.
In asynchronous USB audio, the sink generates its own audio sample clock which could be from a high-precision, low-jitter oscillator. But then the question is: how do the source and sink guarantee that their independent audio sample clocks stay in step so that they run at exactly the same rate (overall)? If they don't run at the same rate, then over a long period of time the source would be sending samples slightly faster or slower than the sink could play them, which means either samples would have to be dropped or "made up" to fill gaps.
What happens is that the sink monitors the rate at which audio samples are arriving in the USB frames, and over a period of time compares this rate to the rate it's playing them (that is, its own sample clock). If there is a difference, it sends feedback to the source telling it to slow down or speed up a bit. In this way the sample clock on the source ends up being "controlled" by the sink so that it matches the rate of the sink's sample clock. The benefit of this approach is that the sink can have a very high-quality sample clock so that samples are played back with low jitter, independently of what happens upstream.
Going back to the Devialet: I haven't used USB as an input so I'm not absolutely sure, but I'd be very surprised if it's not using the asynchronous mechanism.
One final point: you might also hear the term "isochronous transfers" used when talking about USB audio. This describes the mechanism by which audio samples are sent in bursts at a fixed rate (8 kHz for high-speed USB). Isochronous transfers are used because the audio sample data is time-critical, and needs guaranteed bandwidth on the bus; the USB specification defines isochronous transfers as the way to reserve bandwidth. Both asynchronous and synchronous USB audio is sent using isochronous transfers.
Roon (Mac Mini), Wilson Benesch Full Circle, Expert 1000 Pro CI, Kaiser Chiara
Warwickshire, UK
