USB audio transmission isn’t bit true

[Summit]

On 12/2/2018 at 4:24 PM, AudioDoctor said:

 

 

Another thing to keep in mind when reading this, they are trying to sell you something to fix the "errors" they are telling you exist.

 

I agree that it’s best to read and filter everything as it was written as something someone want to promote or sell.

[asdf1000]

On 11/30/2018 at 9:50 AM, mansr said:

If they use a custom protocol (not UAC), they could have some form of error correction. 

 

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.

 

Cheers

[PeterSt]

1 hour ago, Em2016 said:

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

 

And what would be wrong with that example ?

So that. All it requires is extra buffering.

 

But it would be useless because USB errors are non-existent. Well, to the degree as was discussed in this thread. And that's sufficiently non. 

[asdf1000]

14 minutes ago, PeterSt said:

And what would be wrong with that example ?

So that. All it requires is extra buffering.

 

How much extra buffering? I assume there is a limit to how much error correction you can provide, because there is only so much buffering the user wants to sit through? And increased buffering is a problem with latency for audio + video playback/sync but I'm only interested in audio here.

 

 

14 minutes ago, PeterSt said:

But it would be useless because USB errors are non-existent. Well, to the degree as was discussed in this thread. And that's sufficiently non. 

 

See the last line of my post:

 

"Not that I'm at all worried about dropped USB audio packets - just very interested in the technical side (of this USB audio error correction)"

 

 

[PeterSt]

1 minute ago, Em2016 said:

How much extra buffering? I assume there is a limit to how much error correction you can provide, because there is only so much buffering the user wants to sit through?

With a good implementation the round trip latency of USB can be 1ms. So 20ms would allow for 19 retries and won't bother anyone. Of course this also implies a 20 fold speed temporarily required.

 

3 minutes ago, Em2016 said:

Not that I'm at all worried about dropped USB audio packets

 

Fair enough.

[PeterSt]

Just now, PeterSt said:

Of course this also implies a 20 fold speed temporarily required.

 

Thus make the buffer 200ms and utilize 20ms of it only. Now the 20 fold has become 2 fold. Etc.

[asdf1000]

Thanks Peter!

 

This part I can understand:

 

7 minutes ago, PeterSt said:

With a good implementation the round trip latency of USB can be 1ms. So 20ms would allow for 19 retries and won't bother anyone.

 

But this part I don't understand what you mean here (bold )

 

7 minutes ago, PeterSt said:

So 20ms would allow for 19 retries and won't bother anyone. Of course this also implies a 20 fold speed temporarily required.

 

What is this 20 fold speed temporarily required?

[PeterSt]

Suppose USB2 maxes out at 768K 2ch samples of 32 bits. This is then so because of the bandwidth limitation (transceivers are not faster). With a buffer of 20ms in order to retry 20 times because the buffer is empty, those retries imply 20 times 768K in the time normally done in 1ms. That does not fit.

 

N.b. Usually it is easy for me to make mistakes in this kind of relative thinking. So be my guest ...

 

One thing which makes it more complex is that USB does not transmit at the level of audio samples but in larger blocks (packets). So if something goes wrong with one sample (if detectable at that level in the first place) it implies a retransmit at the packet level.

Now suddenly nothing holds of my proposition ...

Over and out. LOL.

[asdf1000]

27 minutes ago, PeterSt said:

One thing which makes it more complex is that USB does not transmit at the level of audio samples but in larger blocks (packets). So if something goes wrong with one sample (if detectable at that level in the first place) it implies a retransmit at the packet level.

Now suddenly nothing holds of my proposition ...

Over and out. LOL.

 

But here, Chord UK are saying their Windows driver allows lost packets (not samples) to be resent... so I'm trying to work out how this is possible (technically).

 

"It's true that standard driverless USB does not resend faulty packets; but with the Chord Windows driver, it does."

 

and

 

"Yes WASAPI, Kernel Streaming and ASIO all work in the same way to resend lost packets."

 

 

https://www.head-fi.org/threads/chord-electronics-hugo-2-the-official-thread.831345/page-867#post-14264276

 

https://www.head-fi.org/threads/chord-electronics-hugo-2-the-official-thread.831345/page-1004#post-14693056

 

Just in case anyone asks again - no I'm not worried at all about lost packets. Just interesting in learning how this can be done in real-time, even with a custom protocol.

 

[asdf1000]

5 hours ago, PeterSt said:

One thing which makes it more complex is that USB does not transmit at the level of audio samples but in larger blocks (packets). So if something goes wrong with one sample (if detectable at that level in the first place) it implies a retransmit at the packet level.

Now suddenly nothing holds of my proposition ...

Over and out. LOL.

 

From Chord:

 

"I think the key here is that yes the music might be playing in real time but the digital audio data transmission is sent at a faster rate. The process is relatively simple where the data is sent, buffered and error checked. If there is a problem then the data can be retransmitted before it is required to keep the music playing. I can't give out many more details than this as it is proprietary technology and I need to keep some parts of the process confidential - I hope you understand."

 

Even for dropped packets, I guess the concept is still the same as you said @PeterSt ? Buffering allows for a certain/limited number (non-infinite obviously) of retries?

 

I have to add the same disclaimer again because someone will ask why I'm worried about dropped packets... I'm not at all worried. Just learning.

 

[esldude]

4 minutes ago, Em2016 said:

 

From Chord:

 

"I think the key here is that yes the music might be playing in real time but the digital audio data transmission is sent at a faster rate. The process is relatively simple where the data is sent, buffered and error checked. If there is a problem then the data can be retransmitted before it is required to keep the music playing. I can't give out many more details than this as it is proprietary technology and I need to keep some parts of the process confidential - I hope you understand."

Snip ....

@PeterSt

I have to add the same disclaimer again because someone will ask why I'm worried about dropped packets... I'm not at all worried. Just learning.

 

Glad you understand the part on the disclaimer.  Now ask yourself why Chord needs a proprietary protocol that solves a non existent problem.

[PeterSt]

 

@Em2016, if you read carefully between their lines, you will notice that this is about 192K sampling rate. At least I saw it. This means that for 2ch there's the overhead available for 3 retransmissions, if needed.

 

But why don't I believe a hoot of it ...

 

Maybe @Miska can shed a light on whether ASIO even reports back about errors and at a "level" that a retransmit can take place before a next sample is already out. I don't know anything about ASIO (I somehow managed to avoid it forever).

[asdf1000]

36 minutes ago, esldude said:

Glad you understand the part on the disclaimer.  Now ask yourself why Chord needs a proprietary protocol that solves a non existent problem.

 

Noted and I added that disclaimer a few times in replies because I know it's not an issue and people will be quick to remind me it's not an issue (I agree).

 

Still interested in understanding how they are doing it.

 

18 minutes ago, PeterSt said:

 

@Em2016, if you read carefully between their lines, you will notice that this is about 192K sampling rate. At least I saw it. This means that for 2ch there's the overhead available for 3 retransmissions, if needed.

 

But why don't I believe a hoot of it ...

 

Maybe @Miska can shed a light on whether ASIO even reports back about errors and at a "level" that a retransmit can take place before a next sample is already out. I don't know anything about ASIO (I somehow managed to avoid it forever).

 

Thanks Peter. So there's overhead available for 3 retransmissions with 192k/176k.

 

Overhead for 4 retransmissions  with 96k/88k? And 5 retransmissions  with 48k/44k? Is that what you are seeing with their explanation?

 

They also said this re-sending of lost packets works not only with ASIO but also WASAPI (when you install their Chord Windows driver).

 

"Yes WASAPI, Kernel Streaming and ASIO all work in the same way to resend lost packets."

 

https://www.head-fi.org/threads/chord-electronics-hugo-2-the-official-thread.831345/page-1004#post-14693056

[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.

[asdf1000]

3 minutes ago, mansr said:

The TCP connection to Tidal has no problem with retransmissions.

 

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).

 

Friendly disclaimer: I know dropped packets are a non issue. Just interested in the discussion.

 

[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.

[Miska]

2 hours ago, Em2016 said:

They also said this re-sending of lost packets works not only with ASIO but also WASAPI (when you install their Chord Windows driver).

 

"Yes WASAPI, Kernel Streaming and ASIO all work in the same way to resend lost packets."

 

https://www.head-fi.org/threads/chord-electronics-hugo-2-the-official-thread.831345/page-1004#post-14693056

 

I wonder how well they tested it, because with Mojo any error drives the DAC nuts and it begins to play out white noise. And it is very sensitive... One reason I totally gave up using it.

 

[Miska]

9 hours ago, PeterSt said:

Suppose USB2 maxes out at 768K 2ch samples of 32 bits. This is then so because of the bandwidth limitation (transceivers are not faster). With a buffer of 20ms in order to retry 20 times because the buffer is empty, those retries imply 20 times 768K in the time normally done in 1ms. That does not fit.

 

768/32 shouldn't be anywhere near bandwidth limit of USB2? 768/32 is just 46 Mbps, and USB2 has bandwidth of 480 Mbps.

 

At least there are pro audio interfaces that can do 16 channels input, 16 channels output simultaneously at 192 kHz, over USB2. (187 Mbps)

 

[esldude]

32 minutes ago, Miska said:

 

I wonder how well they tested it, because with Mojo any error drives the DAC nuts and it begins to play out white noise. And it is very sensitive... One reason I totally gave up using it.

 

So that explains why they need this at Chord.

 

The long million tap filtering I guess.

[PeterSt]

38 minutes ago, Miska said:

At least there are pro audio interfaces that can do 16 channels input, 16 channels output simultaneously at 192 kHz, over USB2. (187 Mbps)

 

Yes, you are correct. And XMOS does better than 46M these days as well (IIRC) (but with a driver of which I wonder how robust it is).

 

So my remark about the transceivers not being able to cope is wrong. It will be the (audio) drivers mostly not supporting it.

So if this is brought to the higher level (physical layer) then there's sufficient headroom for retransmissions.

 

[Miska]

Just now, PeterSt said:

Yes, you are correct. And XMOS does better than 46M these days as well (IIRC) (but with a driver of which I wonder how robust it is).

 

So my remark about the transceivers not being able to cope is wrong. It will be the (audio) drivers mostly not supporting it.

So if this is brought to the higher level (physical layer) then there's sufficient headroom for retransmissions.

 

I mostly try to stick to the driver in Linux kernel. On macOS too, devices rarely have their own drivers but instead rely on the OS' built-in one.

 

Almost all XMOS based gear uses Thesycon's driver on Windows. Technically one of the most robust ASIO drivers has been the one for TEAC UD-501/UD-503.

 

For the cases where USB interface in the DAC is well behaving, I haven't seen need for retransmissions. Some devices like the first generation M2Tech hiFace and I think also exaSound DACs use bulk mode transfer instead which has error correction. It also breaks the often problematic packet pattern of UAC2 too.

[PeterSt]

9 minutes ago, Miska said:

Almost all XMOS based gear uses Thesycon's driver on Windows.

 

Yes. And I was referring to that Chinese guy (forgot the name at this moment) who provides DAC boards with the AK for yourself to provide with native 768 (and 512x DSD IIRC). I don't think that is Thesycon. I have the driver laying around somewhere.

[abulr]

On 11/26/2018 at 5:40 PM, beerandmusic said:

The bigger question is, so where does that leave us....i would start that it is with enet that i found i preferred 8 years ago even before advent of usb toys, and probably why i preferred using a used $50 sony bluray player as a dlna endpoint streaming native dsd, even more so than a noisy pc connected to a very high priced DAC.

how exactly does this work? i have a similar sony bdp lying around, so easy for me to test...
do you plug the sony into the network via ethernet, then stream digital file from some NAS / PC  to there via the network?
you output the sony bdp audio directly into amp via RCA?

[OE333]

Isochronous streaming of audio data according to UAC2 and UAC3 standards has CRC error detection but no error correction mechanism (the same by the way is true for S/P-DIF transmissions). So if there is a transmission error a complete USB  packet is dropped leading to a gap in the audio stream of 125us. How this gap is dealt with depends on the DAC (short mute, linear interpolation, polynominal interpolation....). In every case it means a degradation of the signal integrity and of course a less ore more severe degradation of the signal quality.

 

If Bulk mode with a sufficiently long input data buffer would be used instead of Isochronous mode then erroneous packets could be re-transmitted and errors could be avoided.

 

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.

 

Are USB transmission errors really an issue ?

I can say from extended testing, that (provided proper cables and equipment are used) transmission errors do not occur. I had tests running for 48 hours and more and not one single error occurred. So according to my experience I can 100% confirm Miska's comment:

 

On 1/3/2019 at 3:03 PM, Miska said:

For the cases where USB interface in the DAC is well behaving, I haven't seen need for retransmissions.

 

In our new SDV3100HV DAC we constantly monitor and analyze the USB transmission quality. It would be easy to display the results and give the user a feedback about transmission quality. That could give some information about cable or noise problems etc.

So perhaps in the next firmware version we should include this feature....

 

[crenca]

17 minutes ago, OE333 said:

In our new SDV3100HV DAC we constantly monitor and analyze the USB transmission quality. It would be easy to display the results and give the user a feedback about transmission quality. That could give some information about cable or noise problems etc.

So perhaps in the next firmware version we should include this feature....

 

 

That would be very cool and oh-so anti "audiophile", in that audiophiledom loves to talk endlessly about their personal USB foibles when the evidence (what there is) points in other directions.

 

The only other manufacture I know of who provide any end user USB quality feedback at all is Schiit (perhaps there are others) with their "buy better gear light", and it is just a light - very minimal.