All I am saying is that the SPDIF jitter performance described in Jans review link is irrelevant for the USB audio system with the ADI DAC (or any other USB DAC with its own master clock).
That said, a properly implemented DAC USB input will yield the same performance with any USB source, as long as the source adheres to the specifications of the USB standard.
In other words: as long as the audio data get transfered through the USB system without any data loss, there is no difference between different USB audio sources. In case of data loss the USB system is broken.
I am sure some people will continue the discussion about USB audio fairydust -- I am out of here. Bye!
That said, a properly implemented DAC USB input will yield the same performance with any USB source, as long as the source adheres to the specifications of the USB standard.
In other words: as long as the audio data get transfered through the USB system without any data loss, there is no difference between different USB audio sources. In case of data loss the USB system is broken.
I am sure some people will continue the discussion about USB audio fairydust -- I am out of here. Bye!
Well I haven't read anything here from someone saying clock jitter is of importance for USB, so I don't know where you got that.
Jan
Jan
I believe in this point mbrennwa is correct. Technically that is; of course the marketing people can spin it any which way they want 
Edit: it seems audio streams are using the USB without error correction (there's no time for it), as described here:
Isochronous Transfers
Now, this discusses timing jitter in isochronus streams:
Interrupt Transfers
... but it is NOT what we audio types normally mean by jitter. Timing jitter in an isochronus stream means that a new packat can be send anywhere in a 10ms window, and since it is not defined WHERE in that window it is send, that can be called timing jitter.
Nevertheless, for audio I believe it is irrelevant.
Jan
Edit: it seems audio streams are using the USB without error correction (there's no time for it), as described here:
Isochronous Transfers
Now, this discusses timing jitter in isochronus streams:
Interrupt Transfers
... but it is NOT what we audio types normally mean by jitter. Timing jitter in an isochronus stream means that a new packat can be send anywhere in a 10ms window, and since it is not defined WHERE in that window it is send, that can be called timing jitter.
Nevertheless, for audio I believe it is irrelevant.
Jan
Last edited:
I built a pair of fanless computers based on Intel Atom motherboards and put them into some nice small aluminum chassis which had room for a DVD drive.
I found motherboards that have SPDIF on a header. I took the SPDIF out to an RCA jack via a transformer. I made a dimmer pot for the LEDs which were very bright and a toggle switch to turn on the tiny chassis fan if I ever need it.
In one of them I put an M Audio Audiophile 192 high res PCI card. I intended it to be an audio measurement interface but the drivers for it quickly went out of support and the electrolytic capacitors all tested high for ESR. Still I think the idea of a computer is the best place to start. You can then choose your OS and your favorite app.
I found motherboards that have SPDIF on a header. I took the SPDIF out to an RCA jack via a transformer. I made a dimmer pot for the LEDs which were very bright and a toggle switch to turn on the tiny chassis fan if I ever need it.
In one of them I put an M Audio Audiophile 192 high res PCI card. I intended it to be an audio measurement interface but the drivers for it quickly went out of support and the electrolytic capacitors all tested high for ESR. Still I think the idea of a computer is the best place to start. You can then choose your OS and your favorite app.
Probably a bit late to the party as always and I’m sorry if this has been suggested, or if I have missed your original requirements.
I would suggest a Volumio primo device, it is not the cheapest and you can probably find better devices technically speaking, but what you do get is a easy to setup and use streamer with tons of support. Both in turns of Volumio being very progressive in development and (Useful) software updates, and if you should have any trouble, the customer support from Volumio is from my experience top notch. (At least if you get the one with included lifetime Plan)
Just to clarify: I also use rpi with Volumio and must say for ease of use and smooth operation the primo is by far a better solution. In my experience no bottle-neck sound wise either.
I would suggest a Volumio primo device, it is not the cheapest and you can probably find better devices technically speaking, but what you do get is a easy to setup and use streamer with tons of support. Both in turns of Volumio being very progressive in development and (Useful) software updates, and if you should have any trouble, the customer support from Volumio is from my experience top notch. (At least if you get the one with included lifetime Plan)
Just to clarify: I also use rpi with Volumio and must say for ease of use and smooth operation the primo is by far a better solution. In my experience no bottle-neck sound wise either.
Volumio is very good as an OS (also depends on taste/preference but it is stable) however in the case of the Primo device jitter over SPDIF coax is very high. If that would not be the case I would have tried the device already. Now I understand we should focus on USB or something like that but IMHO all outputs should at least be average/OK. 2.733 ns is extremely high so it is safe to say the coax SPDIF output is unusable. Since I am already an RPi hat0r according some there is a chance I will be getting accused of prejudice... well, the Elac Discovery suffers from a bad Toslink output. I did not know that beforehand.
Volumio Primo music player/streamer Measurements | Stereophile.com
Señor Didden, can you post a screenshot of the app of the iFi? Discussing every other player is nice just like discussing the USB protocol (a bag of hurt Steve Jobs would say) is but the Zen stream is the one many probably don't know and you have one.
Volumio Primo music player/streamer Measurements | Stereophile.com
Señor Didden, can you post a screenshot of the app of the iFi? Discussing every other player is nice just like discussing the USB protocol (a bag of hurt Steve Jobs would say) is but the Zen stream is the one many probably don't know and you have one.
Last edited:
Yes, with regards to USB jitter. However USB audio specifications leave room for variations in the implementation. E.g. Windows and Linux implementations are slightly different. If not properly addressed at the Dac side this may result in other errors than jitter such as over/underruns that can be heard as random glitches occurring once in a while.
With regards to SPDIF he also misses the point the Zen streamer works well with SPDIF Dacs. In my book that is a bonus.
I can connect the streamer and the ADI both through USB and S/PDIF at the same time I think and switch between them with the ADI remote. I think.
Jan
With iPhone power button and then Home button while the power button is still being pressed. Then send the screenshot to Whatsapp or your email.
With Android devices I don't know (nor do I wish to know 🙂).
Last edited:
I got the ADI set up in DAC mode, so I can switch between inputs USB with internal clock, or S/PDIF with S/PDIF clock.
But, apparently the Zen can only output either on S/PDIF OR on USB, and you have to reconfigure to change to another output. That's funny.
Jan
But, apparently the Zen can only output either on S/PDIF OR on USB, and you have to reconfigure to change to another output. That's funny.
Jan
Ohja? I thought the USB out and S/PDIF out are separate circuits, that can operate simultaneously.
The reconfig means that replay is stopped and has to be restarted afterwards.
Jan
The reconfig means that replay is stopped and has to be restarted afterwards.
Jan
Well, let's see what's going on. The Primo uses Asus Tinker Board S with Rockchip ARM RK3288. RK3288 integrates an SPDIF transmitter the output of which is available on the Tinker Board between its ethernet and USB ports
The Primo SPDIF cinch si soldered directly to this output Volumio's Primo is a two-headed streaming monster! - YouTube time 4:18:
Using the RK3288 SPDIF output is quite simple Spdif - Rockchip Wiki
The reference manual to RK3288 http://opensource.rock-chips.com/images/8/8f/Rockchip_RK3288_TRM_V1.2_Part1-20170321.pdf talks about clock to the SPDIF transmitter at chapter 2.9.3 "Fractional divider usage".
A peek at the linux driver for the rockchip SPDIF transmitter shows it is configured to use the fractional divider indeed, even solving the denominator > 20x nominator issue to minimize the jitter
Here solving for the I2S peripheral (the same clock arrangement) [1/2] clk: rockchip: add I2S internal clock IDs for rk3288 - Patchwork
SPDIF specific:
https://www.kernel.org/doc/Documentation/devicetree/bindings/sound/rockchip-spdif.txt
https://elixir.bootlin.com/linux/latest/source/drivers/clk/rockchip/clk-rk3228.c#L158
https://elixir.bootlin.com/linux/latest/source/drivers/clk/rockchip/clk-rk3228.c#L195 and many other links.
Now what does the non-PLL fractional divider do. The Wikipedia explains nicely https://en.wikipedia.org/wiki/Frequency_divider#Fractional-n_dividers - flipping an integer divider between values n and n+1 to reach the required fractional number on statistical average, sorting the sequence randomly to minimize the effect. So basically the clock generator flips between two close frequencies to generate a mid frequency, on average. Looks very familiar - the very same technique which RPi uses for generation of its internal I2S clock, called MASH in its documentation. Periods of the two frequency ticks generated by the fractional divider in RPi differ by 1.3ns for 48kHz. Clearly the rockchip uses half the dividers (or half the frequency) so that the two frequency ticks differ by twice as much (2.7ns).
I analyzed the RPi fractional divider behavior in Avoiding RPi Master I2S Fractional Jitter . It has the very same cause and the very same "hack" could be applied to the Rockchip driver. Only the nearest integer-divider frequency would differ more from the required audio samplerates as the numerator divider in the rockchip is more coarse (larger difference between the n an n+1 frequencies) than that in RPi's Broadcom.
To conclude - the SPDIF jitter of the Volumio Prime (= Asus Tinker Board S = RK3288) is perfectly explainable and completely irrelevant to its USB performance.
Attachments
Last edited:
But that is about software, not hardware, on the streamer (host) side. I do not see the effect of the streamer hardware on that.
Unless the USB port is shared with some high-bandwidth function and the actual controller is just an IP core burnt into the SoC, which is the case for RPi3 (and earlier) - the 100M/gigabit adapter is USB->network adapter and the slow USB2 line, provided by the Synopsys dwc2 IP core inside the BCM2837 SoC, is split by an onboard USB hub to feed the onboard USB-network adapter and the USB ports. There are reports that the USB transfer is unreliable when the USB port is loaded by the network traffic. But that is the flaky design I was talking about. No reason to buy the deprecated RPi3 today unless one is already in the drawer.
Last edited:
Streamer is running software in some form or another so it may be an issue just as well as the hardware. Anyhow the point I was making is that it is not necessarily true that properly implemented USB Dac will yield the same performance with any USB source as mbrennwa was claiming.
The two outputs use different alsa drivers (snd-usb-audio and snd-soc-rockchip-spdif), therefore they appear as two different alsa devices to the userspace player software the streamer is using. The player would have to support playing to two devices simultaneously. Not many players support that as generally two sound devices run with two independent clocks and the devices will get off sync sooner or later. In your case SPDIF = the rockchip internal fractionally-divided clock analyzed above (RK3328 in this case) and USB ADI = crystal clock by the DAC in the ADI.
EDIT: I overlooked the chips on the bootom side of the Zen streamer - the SPDIF is generated by iFi circuits. That means they use I2S from the RK chip, slaved to their own external master clock. So the SPDIF clock is not generated by the rockchip, but by an external clock, again asynchronous to ADI clock.
Last edited:
Well, you were talking about varying OS support by the DAC, that's a different story IMO. Obviously a linux streamer cannot use windows-only DAC properly and vice versa.
Isochronous data packets, just like all other USB data packets, carry CRC 16 info at the end of the packet. However broken packets are not resent upon detection. The device knows an error occurred and may do something about it e.g. by repeating the last samples received, interpolating, etc. It may or may not be audible.
That section talks about interrupt transfers, IIUC. They are used for irregular transfers (i.e. polling volume level, setting volume/mute, keyboard/mouse polling by HID). The host asks and the device responds anytime within the specified time frame.
OK, so with the USB packets having CRC, I assume that 1st and 2nd order errors are corrected as usual.
That the 'cannot resend broken packet' only comes into play if the error correction fails, which should be rare, and if it happens, would be readily audible.
Jan
That the 'cannot resend broken packet' only comes into play if the error correction fails, which should be rare, and if it happens, would be readily audible.
Jan
Last edited: