I would opt for a setup with master clock as close to the dac as possible - i.e. async UAC2. Especially considering the potentially high samplerate that device is capable of (even though practically it has no usage).
Just a side note: since it claims to support 1.5MHz over USB, considering 2channels and 24bits the bitrate exceeds isochronous highspeed limit for single-transaction mode (one 1024-bytes packet every 125us microframe). It would mean this device requires multiple transactions which is the first device I have encountered to be capable of that (at least the linux host driver supports multiple transactions OK).
Just a side note: since it claims to support 1.5MHz over USB, considering 2channels and 24bits the bitrate exceeds isochronous highspeed limit for single-transaction mode (one 1024-bytes packet every 125us microframe). It would mean this device requires multiple transactions which is the first device I have encountered to be capable of that (at least the linux host driver supports multiple transactions OK).
Thank you all for chiming in. This is a wealth of info I’m gonna try to process and do more tests like some of you suggested. In a different Denafrips forum there was a recommendation to use the Hifiberry Digi+ driver (not the Pontus one) and try playing with software/ hardware audio control in Moode MPD configuration. I’ll also test with SPDIF/Coax outputs on the board, also with Picore/Volumio player and report back my findings.
Like @phofman pointed out I fully understand this is a compromised solution for the such a DAC. My goal was to try to tinker with a DIY solution to see how close I could get to high quality streaming in the cheapest possible way. Also given how fast the streaming landscape is evolving (Wiim, Eversolo) this is also a stop gap solution for maybe the next 6-9 months when I expect more & better streamers with I2S/DSD capabilities to be in the market. It’s definitely been fun so far and I truly appreciate all your help!
Like @phofman pointed out I fully understand this is a compromised solution for the such a DAC. My goal was to try to tinker with a DIY solution to see how close I could get to high quality streaming in the cheapest possible way. Also given how fast the streaming landscape is evolving (Wiim, Eversolo) this is also a stop gap solution for maybe the next 6-9 months when I expect more & better streamers with I2S/DSD capabilities to be in the market. It’s definitely been fun so far and I truly appreciate all your help!
@varunach: I2S is not better than USB, in fact it's the very opposite. I2S is designed for close runs of data between some receiver and the DAC/ADC. But most decent DACs need master clock (that's what times the actual conversion) which is not carried by I2S and either
1) the I2S source must be slaved to the DAC clock via slave I2S- very few RPi HATs use that, no external DACs do as the I2S signal must carry the clock signals in the opposite direction, or
2) must be generated from I2S via (jittery) PLL, or
3) the incoming I2S signal is recalculated to fit local master clock (ASRC).
USB async UAC2 incorporates the master clock into the communication feedback, typically has very short I2S run between the receiver and the chip, allows native DSD even for RPi (no DoP), allows high samplerates reliably (including high-rate DSD), it carries control signals (volume, switching,...) etc.
It's just a fashion to use I2S for an external DAC, technically it's a nonsense.
1) the I2S source must be slaved to the DAC clock via slave I2S- very few RPi HATs use that, no external DACs do as the I2S signal must carry the clock signals in the opposite direction, or
2) must be generated from I2S via (jittery) PLL, or
3) the incoming I2S signal is recalculated to fit local master clock (ASRC).
USB async UAC2 incorporates the master clock into the communication feedback, typically has very short I2S run between the receiver and the chip, allows native DSD even for RPi (no DoP), allows high samplerates reliably (including high-rate DSD), it carries control signals (volume, switching,...) etc.
It's just a fashion to use I2S for an external DAC, technically it's a nonsense.
@phofman Interesting. So the built in USB interface in an RPi4 is better and does native DSD (without necessitating ad additional HAT at all)? I thought the jitter in USB is worse than that of I2S. Perhaps my POV is ill-informed. I'll test with USB. Is there a RPi4 HAT that cleans up the jitter (equiv of a DDC) before sending USB out cleanly? Alternatively I'm wondering if there are other HAT add-ons I could use to improve the I2S clock problem. I think IAN Canada's fifopi module (link) can help? But this increases the overall cost of the streaming solution. Let me know what your thoughts are here.
As @phofman has said previously, i2s is a protocol designed for short distamce (<10cms) data transmission between ICs, however, I think the comparison of 'i2s' to USB is somewhat misleading in the context you're investigating of transmitting data from a streamer to a DAC via an HDMI cable - that isn't really i2s as it utilises LVDS, which is entirely different to the original i2s protocol. I believe LVDS is better than USB, which is why it has gained traction after, I believe, PS Audio, introduced it, not because of any fashion considerations. You can also repurpose Ethernet/RJ45 hardware to achieve the same LVDS connectivity, as per Twisted Pear's 'Teleporter' - the link below may help with understanding
https://www.diyaudio.com/community/threads/introducing-the-bit-teleporter.201106/
https://www.diyaudio.com/community/threads/introducing-the-bit-teleporter.201106/
@nautibuoy : LVDS is just a different electrical protocol pro I2S - balanced signal instead of single-ended. It's still I2S, and each line gets converted to single-ended for the DAC by the receiver. It can make I2S run for longer distances. But the problem with clock remains. I am convinced it's just a marketing - no advantage against proper USB async UAC2.
HDMI/ethernet cables are a handy low-cost medium for the multiple balanced lines as they contain multiple twisted pairs. In fact the ethernet cable is not the best choice for high-speed I2S as each pair is specced to have a different twist distance and introduces a different delay to the I2S line it holds - there are resources online discussing the skew ethernet cable introduces.
@varunach: Proper USB async introduces no jitter as it does not carry the clock signal (unlike I2S master -> slave). A properly designed UAC2 DAC has a precise master clock by the DAC, timing the chip DA conversion. The DAC I2S interface (recipient of the data) runs in master mode, which means only the data line is input, but the two I2S clock lines are outputs, towards the USB receiver. The USB receiver has a small data buffer at its output (clocked in by the internal USB receiver clock, clocked out by the bitclock generated by the DAC chip from the precise master clock). The UAC2 protocol incorporates a feedback message back to the USB host which tells the host how fast it should be sending the data. The value in the feedback message is determined by the USB receiver to keep the output buffer optimally filled.
That way the feedback synchronizes the USB host data consumption rate to the DAC master clock.
You can simplify your chain by avoiding the USB part, if your data transmitter has I2S interface - like RPi (a standard PC has no I2S interface). The DAC I2S master is connected directly to the RPi I2S, but running in SLAVE mode. The I2S interface of RPi will consume the data via DMA from the player software in the rate of the incoming bitclock generated by the DAC - again just by a simple division from the master clock which runs the actual conversion. That's technically the most correct way of connecting a DAC chip to the I2S interface. You can use LVDS for the I2S signal transmission to make it work over longer distance, but note - in this case the two clock signals run from the DAC case to the RPi. I have yet to see a commercial DAC which has this arrangement - vast majority of DACs with external I2S input run in slave I2S and expect the I2S source to generate the clock - the transmitter is expected to be the master.
You can "reclock" the incoming clock with a FIFO - clock A in, clock B out. But ALL independent clocks run at a different frequency, some closer, some more apart. All clocks will eventually over/underflow any FIFO, it's just a simple ratio of the FIFO size and the clock frequency difference. A larger FIFO helps - at the cost of increased latency of the chain. If a FIFO introduces 500ms latency, it may take a few hours for the buffer issue to arise, but such a device is unusable for audio+video. And the buffer issue will occur anyway, inevitably. There are many resources online about issues like this.
HDMI/ethernet cables are a handy low-cost medium for the multiple balanced lines as they contain multiple twisted pairs. In fact the ethernet cable is not the best choice for high-speed I2S as each pair is specced to have a different twist distance and introduces a different delay to the I2S line it holds - there are resources online discussing the skew ethernet cable introduces.
@varunach: Proper USB async introduces no jitter as it does not carry the clock signal (unlike I2S master -> slave). A properly designed UAC2 DAC has a precise master clock by the DAC, timing the chip DA conversion. The DAC I2S interface (recipient of the data) runs in master mode, which means only the data line is input, but the two I2S clock lines are outputs, towards the USB receiver. The USB receiver has a small data buffer at its output (clocked in by the internal USB receiver clock, clocked out by the bitclock generated by the DAC chip from the precise master clock). The UAC2 protocol incorporates a feedback message back to the USB host which tells the host how fast it should be sending the data. The value in the feedback message is determined by the USB receiver to keep the output buffer optimally filled.
That way the feedback synchronizes the USB host data consumption rate to the DAC master clock.
You can simplify your chain by avoiding the USB part, if your data transmitter has I2S interface - like RPi (a standard PC has no I2S interface). The DAC I2S master is connected directly to the RPi I2S, but running in SLAVE mode. The I2S interface of RPi will consume the data via DMA from the player software in the rate of the incoming bitclock generated by the DAC - again just by a simple division from the master clock which runs the actual conversion. That's technically the most correct way of connecting a DAC chip to the I2S interface. You can use LVDS for the I2S signal transmission to make it work over longer distance, but note - in this case the two clock signals run from the DAC case to the RPi. I have yet to see a commercial DAC which has this arrangement - vast majority of DACs with external I2S input run in slave I2S and expect the I2S source to generate the clock - the transmitter is expected to be the master.
You can "reclock" the incoming clock with a FIFO - clock A in, clock B out. But ALL independent clocks run at a different frequency, some closer, some more apart. All clocks will eventually over/underflow any FIFO, it's just a simple ratio of the FIFO size and the clock frequency difference. A larger FIFO helps - at the cost of increased latency of the chain. If a FIFO introduces 500ms latency, it may take a few hours for the buffer issue to arise, but such a device is unusable for audio+video. And the buffer issue will occur anyway, inevitably. There are many resources online about issues like this.
Last edited:
@MarcelvdG @phofman @nautibuoy Thanks for all your comments and insights. I did more tests and I was able to get the board to work for what its actually supposed to do (setting aside the misleading product information which I'm working with aliexpress on).
1. Settings: I switched the output to SPDIF/Coax. In Moode's config I set the device output to use Hifiberry Digi+ driver as suggested by manufacturer. I set volume control to 'software (100%)' and then DOP.
1. Settings: I switched the output to SPDIF/Coax. In Moode's config I set the device output to use Hifiberry Digi+ driver as suggested by manufacturer. I set volume control to 'software (100%)' and then DOP.
- DSD64 content plays as it should, and the DSD LED light on my DAC is lit up.
- DSD128 gets converted to PCM (max is 24bit 192 Khz which is the spec for the board) and it plays fine. No DSD LED light on.
- DSD64/128 content gets converted to PCM (max is 24bit 192 Khz). The weird thing is DSD128 plays just fine (limited to 192 khz), but no sound for DSD64 content (176 khz). I wonder why.
- DSD64/128 content gets converted to PCM (max is 24bit 192 Khz). Both DSD128 (limited to 192 khz) and DSD64 content (176 khz) plays ok.
- DSD64/128 content gets converted to PCM (conversion happens at higher freq such as 356.2khz for DSD128). Both DSD128 and DSD64 content plays ok.
Yep, aware of all that, and I understand that the 'data' is still i2s format, the point I was making is that by making use of LVDS you are abstacting the practial implementation away from the original design intents for i2s in order to transmit the data over significantly longer distances (even 1metre is significantly longer in this context and i doubt Etheret twisting will be an issue over that sort of 'interconnect' distance). To me it hasn't been an issue because I try to keep my i2s runs short and have no problem with native DSD streams at upto DSD512 (I've not tried beyond that).
@varunach, your thread title implies that your goal was to achiieve playback of DSD media on your Pontus DAC so your testing tells me that, apart from the first instance of DSD64 via SPDIF, your RPi solution doesn't deliver your goal as all other instances result in PCM playback?
@nautibuoy : Well, the problem for me is vast majority of these I2S-LVDS interfaces are designed source=master -> DAC=slave. That precludes using proper master clock by the DAC, and master clock must be PLLed from the I2S bitclock instead. Eventhough in many cases the I2S source allows the slave operation and typically also allows slaving the actual data source (via DMA locally or async UAC2 remotely), making the whole chain properly synced to the master clock a few millimeters apart from the DAC, no PLL in the chain.
The use of differential lines only allows for longer runs and convenient=inexpensive connectors/cables.
The use of differential lines only allows for longer runs and convenient=inexpensive connectors/cables.
@phofman all of my DACs are clocked from the oscillators on an isolator/reclocker module, located right on the front of the DAC. Anyway, that is academic in this context as the topic is streaming DSD to the Pontus DAC, which has a LVDS HDMI connector. I believe the Pontus has oscillators and is able to accept both PCM and DSD data streams without any sample rate conversion but I don't know anything more about how it works. So, the problem to be solved seems to be how to get DSD streamed to the Pontus over the HDMI connector?
Well, then you have a plain FIFO in your chain. That's a workaround and no professional devices use it, because merging two clock domains by a FIFO works only for a limited time, untill the FIFO under/overflows. Imagine a concert PA installation which after several minutes/hours of operation glitches.
OK for a home device though, but not technically correct.
If it has internal oscillators and accepts external clocks, it inevitably either asynchronously resamples (like e.g. ESS DACs in async mode do), or uses the workaround with FIFO (for home use).
That would be a terible concert but fortunately I never experience glitches but instead enjoy sublime music reproduction...
BTW, almost all of my serious listening is via native DSD via decoders like ppy's DSC2 and Marcel's ValveDAC and RTZ DAC.
BTW, almost all of my serious listening is via native DSD via decoders like ppy's DSC2 and Marcel's ValveDAC and RTZ DAC.