Did you try short open open?
You can get also a MonitorPi PRO and control easily the inputs.
This is manual source selection optional control input. But it looks crazy, what mean X?for now i know that only way it works is:
Pin2 is 5v, pin 4,6 is gnd. Pin 1,3,5 is from procesor.
--all pins are not connected is rpi
-pin 1 is connected to pin 2 is hdmi
-pin2 is connected to pin3 is USB
-pin2 is connected to pin 5 is rca
Have try lots of options but no luck witch optical.
Pin2 is 5v, pin 4,6 is gnd. Pin 1,3,5 is from procesor.
--all pins are not connected is rpi
-pin 1 is connected to pin 2 is hdmi
-pin2 is connected to pin3 is USB
-pin2 is connected to pin 5 is rca
Have try lots of options but no luck witch optical.
Oh man, this is sounding great!
Even got it working on the rpi 5 with a modified version of the i-sabre-k2m driver on a version 6.6 kernel, though there are some quirks. Still, it sounds better to me than using the i-sabre-q2m driver or the generic i2s driver.
Anybody else experimented with the pi 5 yet? Right now I can't go any higher than 192KHz, and there is some odd behavior with 16bit content. Almost sounds like the L/R channels are out of phase, but with 16 bit content only. Too bad the documentation of the RP1 chip found in the pi 5 is a bit sparse.
Ok, one problem resolved for now. I set the dip switch on the bottom of the fifiopi to losslessly convert 16bit to 32bit. Should the hdmiPi/holo spring 2 need this?
As for not being able to pass anything higher than 192KHz, after tailing dmesg, it appears I'm getting remote I/O errors (-121) when trying to write to the register that the codec specifies for setting 352.8KHz and above. Not sure if that's a red herring or not, as there are errors on other registers too, and I'm wondering if any such registers really need to be set for the fifopi to operate correctly.
As for not being able to pass anything higher than 192KHz, after tailing dmesg, it appears I'm getting remote I/O errors (-121) when trying to write to the register that the codec specifies for setting 352.8KHz and above. Not sure if that's a red herring or not, as there are errors on other registers too, and I'm wondering if any such registers really need to be set for the fifopi to operate correctly.
hello, I have a similar configuration. since I will mainly use the USB input, I wanted to control the selection via jumpers and I already had MonitorPi. Unfortunately this didn't work, I could choose RPI or HDMI. I wrote to Ian about this and he advised me to install MonitorPiPro. now it is working.
I've switched back to the rpi 4 as a sanity check. Recompiled the kernel & modules, and can confirm that the q2m overlay I mentioned above, which comes with the 6.6y kernel, works with fifioPi, up to 384/DSD128.
After looking over the output of dmesg more thoroughly, on the pi 5 the q2m/k2m "card" fails to be registered, and this is not the case on the pi 4. The pi 4 still shows the I/O -121 errors in dmesg when attempting to update bits, mute, etc, so it seems these can be ignored.
I will have to do some more learning about the new RP1 chip found on the pi 5, as it seems this is the crux of the problem. With the old broadcom soc found in the earlier pi's, i2c traffic can switch between master & slave mode on the fly, whereas that's not possible with RP1's i2c. However, there are multiple i2c busses available on the RP1, and from what I can gather from the docs, it should be possible to run one bus in master mode while the other runs in slave mode.
Hello, just installed the clock:
on my
Thanks
ADZ
IAN CANADA SC-PURE Femtosecond Clock Ultra-Low Phase Noise 22.5792MHz
and 24on my
IAN CANADA TRANSPORTPI DIGI Ultra Low Jitter Digital Audio Interface Module
with shared power from Rasp 3b+ with Volumio
and the sound is slow like a vinyl playing half the speed. Any ideas?Thanks
ADZ
Last edited:
Finally got up to 384kHz working on the pi 5! Worked with one of the maintainers on github and he updated the drivers to support changing the pi 5's PLL for i2s on demand.
So now we can confidently say the Ian Canada HATs will work at higher sample rates on the pi 5.
The PR that makes this possible has not yet been merged into the 6.6 kernel, but you can get this patched version using the rpi-update command as mentioned in the PR comments:
https://github.com/raspberrypi/linux/pull/5999
I've tested extensively and everything is working in terms of PCM sample rates. Still can't get DoP passthrough to work but that's minor since the Q7 can still decode it.
Fun times ahead. Really like what I'm hearing.
So now we can confidently say the Ian Canada HATs will work at higher sample rates on the pi 5.
The PR that makes this possible has not yet been merged into the 6.6 kernel, but you can get this patched version using the rpi-update command as mentioned in the PR comments:
https://github.com/raspberrypi/linux/pull/5999
I've tested extensively and everything is working in terms of PCM sample rates. Still can't get DoP passthrough to work but that's minor since the Q7 can still decode it.
Fun times ahead. Really like what I'm hearing.
Last edited:
