I do not know, I have not seen any mention of correcting the errors detected by CRC on USB. The standard way for the device is not sending the Ack reply and dropping the broken data packet. USB data packets can be quite large (up to 1024bytes) and the CRC is only 16 bits.
That was very clear and all the words don't change the fact that the SPDIF output of the Primo sucks and the one of the Zen Stream doesn't. The Zen Stream seems competently designed in nearly all aspects contrary to some other popular solutions. It has both excellent SPDIF over coax and USB performance. This makes it a versatile device usable in both scenarios.
This makes it superior to Volumio Primo straight away.
So I see Jan has to be massaged into a RPi 4 as the others are very good but maybe less good for audio 🙂 The flaky 3B is not the be preferred. This leaves the Zen Stream which he coincidentally already has. This device measures also very good. Maybe we can concentrate on the device as it seems a winner. Not of RPi of course as religion forbids to say that.
Maybe we can spend words on the device that was chosen and why it performs so good. I think I will try the Zen Stream out as well as I see its design is superior to many devices I know. It certainly has design aspects specifically for audio contrary to any RPi. This is because the iFi was solely designed to playback audio the best possible way for a competitive price. That fact may be hard to swallow but it gives it a head start of proportions when compared to a cheap universal device meant to spread computers and coding in third world countries.
Attachments
Last edited:
That is my understanding as well. If too much data is dropped, properly designed DAC's will just mute the output. There is no way to correct / re-send. By the way, in 99% of the cases, the root cause of dropped USB audio data is a non-standard USB cable - especially those boutique ones... they can be quite nasty.
On-the-fly error correction is something completely different than dropping/asking for resend of a package.
Jan
Jan
An RPi4 with RoPieee is really hard to beat IMO/IME.
RoPieee | RoPieee: a RoonBridge ready-to-go image for Raspberry Pi
Also supported by Roon
RoPieee - Roon Labs Community
case
Flirc Raspberry Pi 4 Case
Literally up and running in 20 minutes with Roon.
RoPieee | RoPieee: a RoonBridge ready-to-go image for Raspberry Pi
Also supported by Roon
RoPieee - Roon Labs Community
case
Flirc Raspberry Pi 4 Case
Literally up and running in 20 minutes with Roon.
My understanding is that there is no error correction. The USB audio is a packet transfer, and the per-packet inspection (and correction) is not possible. The only thing that is possible to control is how fast the packets are received at DAC's end (to a certain degree).
Last edited:
I know, also the HDMI on this device is questionable why’s there. Me personally never bothered with the SPDIF output jitter as I won’t ever use it. If one needs spdif, better look for something else. I agree
However for someone looking for a easy, non-diy way to use volumio With separate USB dac, I think it is a option worth considering.
Last edited:
Well there is CRC redundancy in each packet, so there must be some error correction which probably is totally transparent to the user app.
See https://www.usb.org/sites/default/files/crcdes.pdf:
USB in a NutShell - Chapter 4 - Endpoint Types
The USB specification calls for the use of Cyclic Redundancy Checksums (CRC) to
protect all non-PID fields in token and data packets from errors during transmission.
BTW, for some unusual listening, go to Welcome to My Library! | Linear Audio NL and click the link For some unusual listening.
Enjoy!
Jan
Last edited:
I did not mean only varying OS support. It is possible to have poorly performing Linux USB streamer feeding Linux-only dac. E.g. RPi3 as you yourself mentioned.
You probably see wrong as I have never proposed any RPi for Jan's purpose of USB playback. RPi4 would be OK but just for USB there are more suited alternatives, in my view. Unless one wants to use software which is RPi-only (everyone's choice).
But comparing the Zen streamer to plain RPi from the audio output POW is IMO not fair. The Zen streamer contains a Rockchip compute module plugged into a specialized audio board with external clock. We can compare it to RPi4 (or better the CM4 module) with some hat with dedicated clock onboard, mastering the RPi's I2S peripheral switched to slave. Not many hats feature that, IMO the pure reason is that the vendor would have to provide a custom linux driver which most hardware vendors are scared of. I believe it's a much better option than using the jittery internal clock and reclocking the I2S with some FIFOs later on, causing large latency and unavoidable over/underruns in the long run.
One key advantage of the rockchip SoCs compared to the RPi is their integrated configurable divider from external MCLK to I2S bitclock. That makes the proper audio clock circuit much simpler as only a crystal can be used, feeding the DAC MCLK and the MCLK input pin of the rockchip, no external configurable clock divider is needed (plus an optional simple two-crystal selector)
The major disadvantage of rockchip vs. RPi is the outdated android kernel, compared to the latest kernel available for RPi on their github, and the overall software support. Apparently that is the key aspect.
Error detection and correction are quite different animals. I do not know for sure but I have never heard of a USB receiver doing any error correction, everyone (including the USB specs) talks about error detection only. The redundancy is quite small.
Does the iFi really have an outdated kernel? That could be a wrong assumption. IFi says they optimised software and maybe things are not outdated at all.
Just suppose they really made stuff up to date with all the bells and whistles. Add the good hardware implementation to that. Seems a good combo then.
Just suppose they really made stuff up to date with all the bells and whistles. Add the good hardware implementation to that. Seems a good combo then.
Last edited:
I can only guess by online hints https://www.diyaudio.com/forums/digital-source/377596-looking-expensive-streamer-11.html#post6805314 . Maybe some web admin interface of the streamer (if any is available) would give more details.
Yeah I spend some fair amount of time searching for it, and didn't find it either. It appears that the CRC is used to detect a packet error only.
That has important implications. It means that yes, USB audio has no jitter if the DAC does the clocking (only DAC clock jitter, eventually, but not due to the transmission).
But depending on the USB implementation and connection, you CAN get packet errors meaning that a (very) short section of the audio is wrong, or even that whole packet(s) drop out. That will be audible if large enough.
But I still find it very hard to believe that these things can happen due to non-boutique USB cables.
Jan
If normal cables would cause that maybe USB should not be used at all 🙂 The nonsense you hear in audio.... A strange question in this sea of words... how does it sound now it has had some hours? It's a detail 😀 And how are the presumed dropouts, CRC errors, USB driver issues, glitches, skewed bits, outdated Android kernelhorror etc.?
I ask this because I get a very slight impression this device just works OK. Maybe more than OK. Maybe better than most devices even. Maybe better than ....
I ask this because I get a very slight impression this device just works OK. Maybe more than OK. Maybe better than most devices even. Maybe better than ....
Last edited:
Well I must say the sound of my combo* is very, very good. The tonal balance isn't what it should be, because I just moved into a loft with 15 ft high ceilings so the acoustics need (a lot of) work.
But resolution, clean, undistorted, detailed sound, probably the best I ever had. I finally may have hit the jackpot ;-)
* Zen Streamer, ADI-2 Pro Fs R, Purifi ETI400 amps, ESL63 speakers.
Jan
That sums it up pretty well. Some will keep arguing that you haven't experienced the best yet 🙂 I don't measure height with limb measurements but the ceiling is higher than normal? Then the ESL63 will have to work too hard I think. You could build a sound pressure/monitoring meter with a nice cheap device called RPi. Great support and always the latest kernel.
Last edited:
That signal path looks like gold - congrats! Its probably very hard to beat by any standard.
//