USB audio transmission isn’t bit true

[mansr]

25 minutes ago, firedog said:

When did he get his degree? Maybe he never learned some of this USB stuff in school. 

I didn't either, but I've read the spec. Apparently, he hasn't.

[mansr]

8 hours ago, Em2016 said:

 

Somebody in another forum was commenting that error correction with USB audio is not possible:

 

"That would not make any sense to resend any audio packets when music is playing in real time."

 

Could you explain how a custom protocol could allow this? In the context of real-time music playback (like streaming Tidal for example, if the app could use this custom protocol).

 

Not that I'm at all worried about dropped USB audio packets - just very interested in the technical side.

The TCP connection to Tidal has no problem with retransmissions.

[mansr]

32 minutes ago, Em2016 said:

Noted. I meant real-time streaming of Tidal on a PC to a USB DAC (via direct USB cable connection from PC to USB DAC).

Real-time streaming from Tidal to a PC works fine with retransmissions actually happening. Why would the next hop, PC to DAC, have issues? As Peter already said, you just need a bit of buffer in the DAC and some extra bandwidth.

[mansr]

1 hour ago, OE333 said:

So why was the Isochronous USB mode chosen for Audio transmissions ?

The reason is that USB Audio was (and is) mainly used for Pro-Audio equipment (the few Computer Audiophiles do not count). In Pro Audio the main interest is to avoid any latency - so the input buffers needed for error correction (with several ms latency) are an absolute No-No.

Latency is one reason, guaranteed bandwidth another. With bulk mode, a data burst on another device might eat into the bandwidth and cause drop-outs of indefinite length. Isochronous mode reserves bandwidth upfront that can't be used by other devices.

[mansr]

1 minute ago, Ralf11 said:

What  USB mode would be the absolute best for Audio transmissions ?

Only bulk and isochronous are at all suitable. The remaining two transfer types, control and interrupt, are no good. Given that errors are very rare in practice, isochronous seems preferable.