Is there any DAC with checksum capabilities?

[arbenede]

Years ago I have been involved in the design of the digital section of high speed (10 Gb/s) fibre optic serial communication links. Every time I see claims of "better sounding" USB and Ethernet cables, or operating systems, NAS, hard disks etc I scratch my head. I don't understand why no one has thought of including CRC checking hardware and firmware into their DAC, as it is routinely done in high speed communication links. This would allow to quantify pretty easily the impact of every component in the transport of the digital sample values from the disk to the digital input of the DAC. It is true that analog noise could still be conduced from the digital section to the analog section of the DAC, but still...

 

[RayDunzl]

I don't understand why no one has thought of including CRC checking hardware and firmware into their DAC, as it is routinely done in high speed communication links.

If I'm not mistaken, USB for audio is asynchronous/isochronous

https://www.edn.com/fundamentals-of-usb-audio/

"Isochronous transfers are used to transfer data in real-time between host and device.

When an isochronous endpoint is set up by the host, the host allocates a specific amount of bandwidth to the isochronous endpoint, and it regularly performs an IN- or OUT-transfer on that endpoint.

For example, the host may OUT 1 KByte of data every 125 us to the device.

Since a fixed and limited amount of bandwidth has been allocated, there is no time to resend data if anything goes wrong. The data has a CRC as normal, but if the receiving side detects an error there is no resend mechanism. "

My DAC manual says it has "mute on receive error".

 

[DonH56]

Error-checking is usually done at protocol levels above the DAC itself as @RayDunzl said. Some chips include it but since the DAC itself may be asked (tasked) to handle a variety of protocols it makes little sense to include it in every DAC chip.

Internally there may be circuit features (analog'ish and digital logic) to prevent/reduce bit errors.

 

[RayDunzl]

Years ago I have been involved in the design of the digital section of high speed (10 Gb/s) fibre optic serial communication links.

I worked with WDM transmission for a while, as a tech, not engineer. Cross country here and a trip to Hong Kong for a taste of undersea.

It was amazing how much error could be introduced into a span before the error correction was unable to patch things up for no error between the data sent and received.

 

[danadam]

RME ADI-2 Pro and DAC have "USB Diagnosis" in their settings (in windows driver only, AFAICT). From DAC manual:

USB Diagnosis shows specific USB
transmission errors (CRC5/16, usually 0)
and general errors. If the unit detects a
record or playback error the number
shown will no longer be 0. An audio re-
set is performed automatically. The
counter is reset on start of play-
back/record.

 

[arbenede]

By the way my proposal is not use use CRC for error correction. The idea is to do something along these lines:

1. Compute the CRC of a test audio file
2. Reset the CRC register inside the DAC
3. Put $500 USB cable between transport and DAC
4. Play test audio file
5. Check DAC CRC with the CRC computed in 1.
6. Repeat 1-5 with $15 USB cable

I think you got the idea.

 

[Blumlein 88]

By the way my proposal is not use use CRC for error correction. The idea is to do something along these lines:

1. Compute the CRC of a test audio file
2. Reset the CRC register inside the DAC
3. Put $500 USB cable between transport and DAC
4. Play test audio file
5. Check DAC CRC with the CRC computed in 1.
6. Repeat 1-5 with $15 USB cable

I think you got the idea.

The USB connection has been tested to death. It is a waste of time to worry about. Your sound quality is not being impacted by the USB connection.

 

[KSTR]

I've done that kind of test with my ADI-2 Pro. I used an old junk USB cable, singled out one of the data lines and brought it close to a ferrite bead. At some point I would first get the usual dropouts (and CRC failure indication in the control panel) and with just a tiny bit more of spoiling the line's impedance the communication completely breaks, the USB device not even being correctly enumerated again. The region where I could provoke consistently the occasional data error and associated short dropout without complete breakdown was extremely narrow, 1mm closer to the ferrite --> full stop.
As long as the PHY's in host and device can cope with the corrupted impedance the data is correct and also the is no additional jitter or whatever. The USB host sends out the isochronuous packet(s) with no handshake at all and the device receives it (or not) and simply discards the buffer when a low-level error is present (as the data packets are actually CRC'd, just that there is no re-send mechanism when an error is detected).

 

[RayDunzl]

3. Put $500 USB cable between transport and DAC
6. Repeat 1-5 with $15 USB cable

I don't have a $500 USB cable
I don't even think I have a $15 USB cable

I don't even remember buying a USB cable, except for a 25 foot long repeater cable, which was $8 if I'm not mistaken, and whatever cables came with whatever pieces of gear they came with.

I do have measurements, which don't show any faults I could attribute to problems with USB data corruption.

 

[Blumlein 88]

I don't have a $500 USB cable
I don't even think I have a $15 USB cable

Could you put together 3 $5 cables for us Ray?

 

[gvl]

I would think any transmission errors would likely result in audible artifacts like static or interruptions as there would be a bunch of samples lost at once. It's not like you're going to lose a single sample or some random bits in a sample here and there.

 

[egellings]

Maybe with music, as opposed to, say, numerical calculations where no error at all is permissible, an occasional error could slip by inaudibly and not bother anyone.

 

[gvl]

Maybe with music, as opposed to, say, numerical calculations where no error at all is permissible, an occasional error could slip by inaudibly and not bother anyone.

Does it really matter then? My point is such errors are rather unrealistic, if there are errors then they will very likely be audible.

 

[KSTR]

I might try to run my broken USB cable test with a digital loopback connection between the digital I/O's of the RME (or to a second inteface) and could run subtraction tests where dropouts (muted segments) would be visible as well as some random corrupted sample values. I don't expect any of the latter to show up, though

 

[egellings]

I suppose errors that cause drop outs would be audible for sure, but let's just say that a numerical value a sample was wrong, but a valid possible number for a sample to have. That might not be heard.

 

[Blumlein 88]

I and others have done these tests. Hours, and hours with nary a single bit mis-placed. It is a non-issue if you don't have a broken DAC or broken cable.

Maybe someone can reinvent the USB connection like these guys invent the wheel.

 

[gvl]

I suppose errors that cause drop outs would be audible for sure, but let's just say that a numerical value a sample was wrong, but a valid possible number for a sample to have. That might not be heard.

Samples are sent out in packets and check sums are calculated on a bunch of samples at once. If there is damage that cannot be repaired then a bunch of samples in that packet will get dropped. If a single sample has a bad value then likely it got damaged before it was put on the wire. I didn't dig into USB protocol details, so it is just my educated guess.

 

[AudioSmell]

Yes there is - e.g. ADI 2 DAC FS. There are test tracks linked in the user guide in various sample frequencies and bit depths (see Bit Test chapter). I use them when connecting ADI to a new source. I play them from available players and ADI shows that the checksum is correct if the transmission is perfect ("Bit Test ... Passed" on top of the current screen on the built in display). Otherwise it won't detect the test and will show nothing.

The bit test passes OK e.g. from:
- an old iPad connected via a common USB cable - tested using several apps from the app store
- PC connected to a bus powered USB DAC acting as an USB to optical bridge, then via a common long optical cable to ADI, using a SW player which does not alter data

Edit: Those test tracks are some raw data, so it is advised to mute the outputs.

 

[gvl]

I suspect the RME test is more useful to detect if there is any resampling going on in the player software or the OS mixer rather than to catch digital transmission errors.

 

[danadam]

I suppose errors that cause drop outs would be audible for sure, but let's just say that a numerical value a sample was wrong, but a valid possible number for a sample to have. That might not be heard.

Like this?

(orig.flac on top, orig_1sample_error.flac below)
Still audible.
I guess the audibility will depend on the amount of error and the surrounding sound (e.g. it should be more audible in quiet parts)