No the Fifo will not help you if the DAC after is resynchronising the I2S signal !
The stuffs are usefull is you stream from a jittery spidf or usb source to a DAC chip or a pcb which accept I2S signal without reclocking it !
For instance with some diy projects : DDDAC pcb (PCM1794 dac chip); Bufallo PCB (ES9018) ; AYA II PCB (TDA1541A), etc...
If you use the Ian's stuffs on a ready made device, you must cut the embeded input signal of your dac to swap it by the signal from the Clock II the nearest of the dac chip you can ! Better to do it with some ready made project for clean wirewing (like with uf-l wires and plugs for instance).
Hope this helps
The stuffs are usefull is you stream from a jittery spidf or usb source to a DAC chip or a pcb which accept I2S signal without reclocking it !
For instance with some diy projects : DDDAC pcb (PCM1794 dac chip); Bufallo PCB (ES9018) ; AYA II PCB (TDA1541A), etc...
If you use the Ian's stuffs on a ready made device, you must cut the embeded input signal of your dac to swap it by the signal from the Clock II the nearest of the dac chip you can ! Better to do it with some ready made project for clean wirewing (like with uf-l wires and plugs for instance).
Hope this helps
Last edited:
Reclocking is one thing, FIFO buffer is another.
There is no question whether a FIFO is better than a "plain" reclocker. There is no contest.
The RPi has a very jittery I2S output, so the s/pdif you will get from the Digi+ will also be jittery. It will need all the help it can get.
But, looking at your DAC, I do not see an I2S input, so if you use the FIFO you will need a way to convert its I2S output back to s/pdif (and undo most of the improvement in the process).
So if I were you, I'd look for a good USB to s/pdif converter instead (so as to bypass the RPi's problematic I2S output).
Sorry Eldam, I think I have to disagree with you on this. After having experimented with SPDIF re-clocking (with the Mutec MC-3+) on some capable D/A converters like the RME, Weiss and DcS stuff I have come to the conclusion that: the cleaner/low jitter the SPDIF, the better the result of the clock+data recovery is after that.
And don't underestimate the benefit of the isolator board which allows galvanic isolation between the RPi and the equipment further down the chain. A lot of audio quality degradation is caused by noise transferred through ground connections.
Unless of course if the D/A converter is following the same FIFO strategy as Ian does, but I don't know of DACs that actually do this. Most of them follow either a async sample rate converter or some kind of re-clocking of the clock signals approach.
I expect that I can get better results with Ian's FIFO then with the Mutec, not the least because I can optimise XO quality and power supplies. I don't want to hack into my DcS Puccini to input directly on the I2S there (and frankly speaking wouldn't know how...) And this is why I'm currently building the following setup:
RPi > FIFO + Isolator + Dual XO + SPDIF > DcS Puccini
This will take a while to finish. I received the boards from Ian last week but am pretty busy on my daytime job.
Will report back as soon as finished.
Last edited:
How have you verified the results? Measurements? Listening?
If that was the case, there ought to be a clear preference for optical S/PDIF (that provides total galvanic isolation).
DimDim,
I agree with you on the difference between re-clocking and a FIFO. See my previous post on this.
But using the USB out on a RPi is not the way forward. I have had very bad experience using that, even with some excellent USB > SPDIF converters. I think there is something wrong with the internal audio engine of the Linux distro when using USB. Maybe some sample rate conversion. The audio over USB problem on the RPi has been reported in many places.
Taking audio from I2S into the FIFO and using either a direct I2S connected DAC or use the SPDIF board if you have an external DAC that you want to use, is probably by far the best way forward.
I've verified by listening comparisons.
I'm still trying to get my head around if and how I would be able to do jitter measurements with my limited equipment. Let me know if you have any suggestions.
There is some excellent discussion on this (if you read German) and some measurements on:
aktives-hoeren.de • Thema anzeigen - Mutec MC-3+ Smart Clock
A good optical connection would indeed be better. The problem is that the Toslink standard doesn't result in particularly good S/PDIF signals on the receiving end. This link introduces even worse signal quality for the receiving end to work with.
Agree on both. I'm known with the concepts but not in depth really. With the fifo, i mostly am talking about the separation of the pi and the clock output directly into ian's s/pdif output board. I should've clarified it =)
I can easily elaborate on that.
The i2s can be done via HDMI, USB or GPIO. The internal clock of the pi is software based (not even a cheap crystal). They will all suffer the same fate. So raspberry pi's clock is definately not an ideal solution. The Hifiberry Digi+ reclocks already the signal which is a significant boost.
About the USB. The problem with the Pi is that the USB is shared with the network. Meaning that if you want to play a high bitrate audio over USB, and have data on network / usb device there, the bandwidth is very narrow. It's well known. So high than probably 88.2KHz FLAC files, it will not play without hickups. The GPIO / HDMI does not share the same bus, so the using 192KHz files is without issues.
The i2s interface is good in its own way, but the noise is the problem (also due to the fact most are powered with a switching power supply. I'm using a lineair myself that helps a lot)
This is indeed basically my question; if the "adapticlock" (lock/reclock system) of the Gungnir Dac nullifies the effect of having the fifo, isolation board, dual xo reclock and spdif board out, instead of having a hifiberry digi+ board instead
I have the feeling that this answers my questions, but I prefer to have a good critical answer from you guys who know much more about it than me
Double-blind or sighted?
The J-test is a pretty good method, all it requires is a reasonably decent sound card.
I can read German, but 40 pages...
Sure - but the effects of noise/interference should be very different from those caused by jitter. So which is worse?
The problem you are describing used to be very real, but since it was mainly software related it has been essentially fixed. I have an older RPi (single core) running Archphile and streaming HD audio (including DSD) to an Amanero with absolutely no problems. That is largely due to Archphile's totally lean configuration - no resources are wasted.
I have friends that have the newer RPi (quad core) that use it to stream all kinds of HD audio, including DXD, with absolutely no problems. All of them using USB to I2S interfaces or USB DACs.
So you should give it another chance.
That was my first thought, but then I said to myself "Ian's s/pdif board is input only" and so deleted the sentence. You reminded me that it does output too.
So, one more vote from me for this solution.
AFAIK the RPi outputs regular audio & video through its HDMI port, not I2S. I mean, you will have to connect it to an AVR or a TV to listen to the audio. You cannot connect it directly to a DAC's I2S input.
Also the RPi does have an actual 19.2MHz crystal for a time base for its clock, but it uses a couple of PLLs to generate all of the necessary frequencies using fractional division. The resulting clock has (naturally) tons of jitter. This jitter makes for jittery I2S outputs.
The Hifiberry Digi+ if I'm seeing correctly uses a WM8804 to generate the s/pdif signal, which is definitely an improvement, but it still has to work with flawed I2S signals and it can not work miracles. Plus it also uses fractional division (utilizing a single crystal), meaning it is not perfect for most sampling rates.
See my answer above to jochems.. The problematic USB implementation is not an issue if the RPi has been set up properly for audio reproduction.
What I wanted to say is the FIFO has not so much interrest if a further re clocking in the chain can de synchronising the 3 I2S signals ! The interrest of the FiFO is to buffer a re synchronised I2S signal : I mean the 3 signals in relation to each other : it's an anti jitter device and a bader resynchronisation after can break this job !
You listened a further improvement, but it may be better without the latter resynchronisation as a too long link or another devices on the chain but a good clock (Clock 2) can waste this time alignement the FIFO made just before as it was said above !
That was the sense of my input ! So the weak link is indeed you haven't a pcb with a raw I2S input possibility to stay clean with the signal after the buffer as also writted by members. That's why I writted to you some nice DIY project. Would Ask to Pedja Rogic rapidly a clean AYA2 pcb (35 euros) which as uf-l input socket both for I2S and simultaneous mode I2S (word channel splitted in two L/R channels)... if you have a TDA1541A chip !
I may add an isolator between the Fiffo and the clock board in your shoes !
Dear Eldam,
Thanks for your input.
But I'm not sure I fully grasp this part :
BTW I'm extremely pleased with the sound of my DcS Puccini, both on CD/SACD and using it as a DAC. I haven't heard any other player or DAC that sounds better in my system. Although I can't claim I've heard everything.
My main goal with my project using Ian's FIFO is to see what the maximum quality is that I can achieve with streaming while using an RPi as renderer and get the cleanest, jitter free, S/PDIF signal into my DcS Puccini.
I'm looking forward to see what I find in my shoes on 5 December
Thanks for your input.
But I'm not sure I fully grasp this part
:BTW I'm extremely pleased with the sound of my DcS Puccini, both on CD/SACD and using it as a DAC. I haven't heard any other player or DAC that sounds better in my system. Although I can't claim I've heard everything.
My main goal with my project using Ian's FIFO is to see what the maximum quality is that I can achieve with streaming while using an RPi as renderer and get the cleanest, jitter free, S/PDIF signal into my DcS Puccini.
I'm looking forward to see what I find in my shoes on 5 December
You are right about the Hifiberry Digi+ (this is actually my base case that I will compare the FIFO solution with).
It works already quite well, and I was surprised that it already gave a better result than the squeezebox Touch that I used until recently (and sold now
.Thanks for you and Gitaarwerk clarifying the USB issue
.I still think the better way is to use the I2S out from the RPi and take it from there. There are a lot of good USB to s/PDIF solutions out there but to get close to the potential quality of Ian's FIFO (using excellent clocks and power supplies) I would have to pay for something like a Berkley Alpha USB.
In addition to that I plan to feed the FIFO clock to my DAC using it's Wordclock input. This would be an interesting experiment on its own.
Are you feeding the Puccini with an external word clock signal (from the FIFO?) like you would with the dCS U-Clock?
If you want to go down that discussion I suggest you find a different place/counterpart.
The answer is of course: it depends...
But why bother if you can improve both? S/PDIF can be connected with high quality transformer solutions that isolate quite well and still allow for excellent S/PDIF transmission.
Yes, that is my plan. Reportedly the external clocking is bringing quite a bit of improvement in the more exotic DcS stacks. So this project would be an interesting way to try that.
Although I have not found any resource yet that could help me with how to interface the L/R clock from I2S to the Wordclock input on studio equipment (basically the standard that DcS uses).
Any suggestions for that would be welcome.
Dear Eldam,
Thanks for your input.
But I'm not sure I fully grasp this part
BTW I'm extremely pleased with the sound of my DcS Puccini, both on CD/SACD and using it as a DAC. I haven't heard any other player or DAC that sounds better in my system. Although I can't claim I've heard everything.
My main goal with my project using Ian's FIFO is to see what the maximum quality is that I can achieve with streaming while using an RPi as renderer and get the cleanest, jitter free, S/PDIF signal into my DcS Puccini.
I'm looking forward to see what I find in my shoes on 5 December
Yep sorry I mixed with Gitarweerk ! It was more an answer for him but saw after a part of the answer was about your system in fact !
Btw I think all those chain you try to add should not give you a great help as explained. Sure, the isolator pcb will not help you here really ! The original problem is you have already a multi plexed signal from your CD source ! So you would go for duplex SPIDF for I2S 3 signals to multiplexed SPIDF again to attack the Puccini then having a resynchronisation inside then a I2S conversion again ????? Rock & Roll !
It doesn't mean your sound is bad but it may be better to feed a circuit/pcb in I2S as the Ian's stuffs are made for this job ! In your case the job of the fifo is partially breaked by the DAC as the signal is reworked in time domain again !
For Gitarweerk, I believe the Isolator pcb between the FIFO & the clock II is missing for a better quality ! I have the same problem at least
Now does a Puccini is sounding better than a new sota ES9018 DIY DAC with the Ian's stuffs before ??? Just you can benchmarking if having the two stuffs
I should try in your shoes as having already some Ian's devices Choose the good crystals
! Clock 2 can managing not only CHD 957 from Crysteq.... ( at least if someone want to give you a better reference he tested at home !) the clock is also important in a DAC ! You know this already as the brand of your DAC was selling a very expensive reclocker device.....
Last edited:
Ah, the question that can't be asked. Well, I guess you answered it.
Because random improvements without understanding the underlying mechanisms and their effects is like throwing components in the air, seeing how they land, and listening to the circuits that result to determine the best one.