What it the problem you are hearing?
I don’t know anything about such boards. I’ve tested with HifiBerry boards.
But what is the point in using something limited to 192k PCM with HQPlayer and Holo Audio DAC!?
What it the problem you are hearing?
I don’t know anything about such boards. I’ve tested with HifiBerry boards.
But what is the point in using something limited to 192k PCM with HQPlayer and Holo Audio DAC!?
The Ian Canada HATs states DSD1024 native and 768k PCM, see links in TS. I would never use RPi for anything sound related unless reclocking and isolation are in place between the RPi and the DAC.
Well, Ted Smith does not use the clock coming in on I2S on his DAC. He ignores the clock and uses his own.
You will always need the DACs clock right? Even if the signal is clocked on the sender for I2S, it still need to use the DAC clock to actually send the samples at the right time? If not, then it pretty much boils down to SPDIF protocol (which might not be bad but still).
It depends. I2S is a clocked protocol for internal communication between the output of a (USB or S/PDIF) receiver and the main A2D circuitry, so in simple designs the clock embedded in the I2S signal is all there is. But some DACs are now using I2S for external I2S sources, and some of them may use additional circuitry to reduce jitter by reconstructing the I2S signal with their internal clocks. Does a particular DAC do that? Not the easiest information to find.
The Ian Canada HATs states DSD1024 native and 768k PCM, see links in TS.
That doesn’t sound like RPi’s I2S…
I would never use RPi for anything sound related unless reclocking and isolation are in place between the RPi and the DAC.
Why this reclocking stuff would be less problematic than the USB interface? Holo Audio’s USB interface is already isolated.
Well, Ted Smith does not use the clock coming in on I2S on his DAC. He ignores the clock and uses his own.
Does he use ASRC or DPLL to deal with the clock differences?
You will always need the DACs clock right? Even if the signal is clocked on the sender for I2S, it still need to use the DAC clock to actually send the samples at the right time?
No, most DACs using I2S input use the clock from the I2S. Because the data on I2S is clocked by the sender’s clock.
If not, then it pretty much boils down to SPDIF protocol (which might not be bad but still).
Exactly…
Does he use ASRC or DPLL to deal with the clock differences?
Indeed it is 169.344MHz, tho I’ve used plenty of other similar rates. I don’t attempt to recover the incoming clocks from I2S, S/PDIF, AES/EBU, TOSLink, etc. Instead I sample all incoming digital inputs at the 169.344MHz rate and look for...
The point that people have been trying to make is that with the DS the separation of the clocks is completely immaterial - the clocks aren’t used in the DS and the DS only looks at the steady state values of the data. All digital inputs (whether...
That is not simpler than USB input and needs additional clock conversion for the sample clocks. They would also need to increase the digital sampling clock rate for DSD256+ support
Essentially they are running like ADC for the digital inputs.
But OTOH, these posts didn’t cover USB inputs at all, only the ones where you would be clock slave. On USB you already have the master clock, so it is simpler.
Ted designed the DAC and writes all the FPGA code for the D to A conversion. Whatever he says I would take seriously. He knows what he is doing.
That doesn’t sound like RPi’s I2S…
I think the I2S on RPi is limited because of inaccurate clock, and at higher sample rates the jitter will overlap clock-slots. I asked Ian Canada directly what was supported if using an RPI4 with his reclocking HAT and I2S transport HAT:
But the reason I think I2S is better is not because clocking, async USB does that well, but because of less overhead (XMOS with its CPU etc). I2S in comparison is very light-weight, and is also already in place so very little extra is needed to use it.
I2S in comparison is very light-weight, and is also already in place so very little extra is needed to use it.
Only if you don’t for example reclock it at the DAC side… And if you don’t…
but because of less overhead (XMOS with its CPU etc)
I’d just like to see some data about this…
There seems to be some anchoring to older poor USB receiver implementations in these discussions. Yes, some of those were slapdash affairs. But good designers have stepped up and they are building USB receivers that are very high quality and competitive with any other input, including I2S.
Lots of back and forth here, but I’d still like to know the answers to the two key questions:
does the holo spring v1 reclock the i2s input?
According to Tim Connor (KitsuneHiFi, Holo distributor in the US), I2S MCLK is in charge, no reclocking:
When I owned a Spring level 3 KTE, original batch, I used I2S from a Singxer SU-1.
Yes, NAA on a Raspberry Pi recognises IanCanada Hat as an output.
My system is as follows:
I2S Transport:
RasPi 4B Rev.1.4 + IanCanada FifoPi Q3 + IanCanada HDMIpi Transmitter I2S
DAC:
Holo Audio May DAC KTE
Player Software:
moOde
@SSH, I ran the following:
sudo wget https://www.signalyst.eu/bins/naa/linux/stretch/networkaudiod_3.6.0-42_armhf.deb
sudo dpkg -i networkaudiod_3.6.0-42_armhf.deb
sudo apt install -f networkaudiod_3.6.0-42_armhf.deb
As for ‘Audio Device’, ‘Audiophonics ES9028/9038 DAC’ is a good choice. It plays up to 384/32 and DSD128(DoP).
I also tried ‘IanFIFO II’, which seems the better option. However, it plays only up to 192/24 and DSD64(DoP).
Cheers, so NAA is no problems with Ian Canadas modules.
What’s the maximal sample rate for PCM and DSD with your RPI4 + Ian Canada modules?
As a RoonBridge on Symphonic-MPD, I confirmed it plays up to 768/32 and DSD256(DoP).
And with NAA? Same? I assume we are speaking of I2S output over HDMI (LVDS).
384/32 and DSD128(DoP).
With NAA, the best I have done is 384/32 and DSD128(DoP).
They are all I2S outputs over HDMI(LVDS) from IanCanada HDMIpi Transmitter I2S.
The difference is due to player softwares, I think.
Symphonic-MPD
@jussi_laako might be interested in this, maybe to use as a base for his RPi images.