In case someone wants to try this, i compiled the driver for the 4.19.118-v7+ (so newest kernel for the rpi 3 B+) with max to 768kHz.
just swap the attached file with the "/lib/modules/4.19.118-v7+/kernel/sound/soc/bcm/snd-soc-bcm2835-i2s.ko" and reboot
Could be possible that there is a limit in the overlay too, so perhaps check that if it doesn't go up to 768kHz.
PS: You do this on your own risk of course
In case someone wants to try this, i compiled the driver for the 4.19.118-v7+ (so newest kernel for the rpi 3 B+) with max to 768kHz.
just swap the attached file with the "/lib/modules/4.19.118-v7+/kernel/sound/soc/bcm/snd-soc-bcm2835-i2s.ko" and reboot
Could be possible that there is a limit in the overlay too, so perhaps check that if it doesn't go up to 768kHz.
PS: You do this on your own risk of course
Thanks Hifoli for your great job! I'll try it and post my update.
Regards,
Ian
Hi Ian,
I have an issue with receiverpi playing independently without the rpi. I initially removed L1 and shorted L7 since i was using 3.3v ps. Now if I don’t power rpi, i have no sound even if i have music playing into the optical of receiverpi. How do i use the receiverpi without the rpi attached. I have fifopi on top of receiverpi then going to transportpi. All is good if rpi is powered on. But i want to remove rpi on the stack.
Thanks
I have an issue with receiverpi playing independently without the rpi. I initially removed L1 and shorted L7 since i was using 3.3v ps. Now if I don’t power rpi, i have no sound even if i have music playing into the optical of receiverpi. How do i use the receiverpi without the rpi attached. I have fifopi on top of receiverpi then going to transportpi. All is good if rpi is powered on. But i want to remove rpi on the stack.
Thanks
In case someone wants to try this, i compiled the driver for the 4.19.118-v7+ (so newest kernel for the rpi 3 B+) with max to 768kHz.
just swap the attached file with the "/lib/modules/4.19.118-v7+/kernel/sound/soc/bcm/snd-soc-bcm2835-i2s.ko" and reboot
Could be possible that there is a limit in the overlay too, so perhaps check that if it doesn't go up to 768kHz.
PS: You do this on your own risk of course
Hifoli,
Can you provide source code or instructions?
I just butchered together Botic RPi codec driver and Audiophonics ESS RPi driver and now I’m using FifoPi->TrasportPi->D90 via FifoPi DoP decapsulation to DSD128.
This is with Ian’s J9-high hack to set pin15 of the HDMI high.
All that from HQPlayer.
Works great!
Next I am planning to use the codec driver to detect DoP DSD and set one of the GPIO pins high.
Is that even possible? Detecting DoP that is. Setting the GPIO is trivial...
Tomorrow when I’m rested I’ll post instructions and pictures how to play native DSD256 via TransportPi (by way of BBB/Hermes/Cronus) and DSD128 DoP via FifoPi stack.
If PCM768 is possible with RPi, that means DSD256 DoP will also be possible!
New update of RaspberryPi DSD128/PCM384 solution
Luchoh gave me a very good information about RPi DSD128/PCM384 KHz solution and I confirmed it works!
In the Volumio, when you select Audiophonics I-Sabre ES9028Q2M as DAC model, RPi can play up to DSD128 (through DoP) and PCM 384KHz even without an ESS controller (Though you can still use it as real time stream monitor).I configured as this setup it works great!
That's a really good news.
@ Luchoh Thank you so much!
384KHzSettings.PNG by Ian, on Flickr
Have a good weekend.
Ian
Luchoh gave me a very good information about RPi DSD128/PCM384 KHz solution and I confirmed it works!
In the Volumio, when you select Audiophonics I-Sabre ES9028Q2M as DAC model, RPi can play up to DSD128 (through DoP) and PCM 384KHz even without an ESS controller (Though you can still use it as real time stream monitor).I configured as this setup it works great!
That's a really good news.
@ Luchoh Thank you so much!
384KHzSettings.PNG by Ian, on Flickr
Have a good weekend.
Ian
Last edited:
@Hifoli,
I PMed you a waveform of the same test I did long time ago by my LeCroy (8GS/s). Seems it related to the test equipment and method. However my oscilloscope is still limited the jitter measurement noise floor to 3ps, so it still can not accurately tell how good is the clock .
And when I use the original MCLK as trigger (SCK is generated child clock so using MCLK can get result more closed to real case), it shows that the jitter at non-isolated GPIO is higher than the isolated GPIO.
You can try to find my old post about GPIO terminator for details.
Good weekend.
Ian
I PMed you a waveform of the same test I did long time ago by my LeCroy (8GS/s). Seems it related to the test equipment and method. However my oscilloscope is still limited the jitter measurement noise floor to 3ps, so it still can not accurately tell how good is the clock .
And when I use the original MCLK as trigger (SCK is generated child clock so using MCLK can get result more closed to real case), it shows that the jitter at non-isolated GPIO is higher than the isolated GPIO.
You can try to find my old post about GPIO terminator for details.
Good weekend.
Ian
Exactly, Ian!
So next for me is to remove all the I2C code from the ESS driver and figure out what is the difference with the generic RPI driver that only goes to PCM192.
Next is to expose the MUTE and DSD_EN lines to the GPIO.
I think we can name this a FifoPi codec/driver and maybe add it to the official kernel.
Hopefully we can figure out if it could go to PCM784/DSD256.
So next for me is to remove all the I2C code from the ESS driver and figure out what is the difference with the generic RPI driver that only goes to PCM192.
Next is to expose the MUTE and DSD_EN lines to the GPIO.
I think we can name this a FifoPi codec/driver and maybe add it to the official kernel.
Hopefully we can figure out if it could go to PCM784/DSD256.
@ Luchoh,
That would be so great! I'm looking forward to your update.
And, if I get chance to upgrade FifoPi to Q3, I'm gonna provide isolated DSD_EN and MUTE signal too just in case you can use them.
Regards,
Ian
Hi, I only changed the .rate_max value to 768kHz otherwise it’s the original driver code: bcm2835-i2s.c
Btw. a lot of things don’t need to be changed in the driver and can instead just be changed by an overlay. Look at graphic_sound_card or simple_sound_card, first of all its way easier to change things there and second its the way to get your hat supporterd like all the other hat overlays you find in /boot/overlays. There is also a good sticky on that in the rpi forum called the i2s sound thread.
Greetings Oli
Last edited:
To get PCM 768 on a RPI you'll need to figure out how to feed the serializer a different source clock (from what I've read PLLA or PLLD could work since they have high enough frequency range and don't seem to be affected by other peripherals) and figure out the register values to set the correct frequency.
The problem is that Broadcom does not publish the full datasheet for the chip. Some people have managed to deduce some stuff using trial and error but it's still undocumented.
The problem is that Broadcom does not publish the full datasheet for the chip. Some people have managed to deduce some stuff using trial and error but it's still undocumented.
Hi Ian,
unfortunately I can't confirm your solution. Setting the DAC type to Audiophonics I-Sabre ES9028Q2M doesn't allow PCM 384kHz, the output confirmed by the D90 was still 192 kHz.
Arnu
unfortunately I can't confirm your solution. Setting the DAC type to Audiophonics I-Sabre ES9028Q2M doesn't allow PCM 384kHz, the output confirmed by the D90 was still 192 kHz.
Arnu
Luchoh gave me a very good information about RPi DSD128/PCM384 KHz solution and I confirmed it works!
In the Volumio, when you select Audiophonics I-Sabre ES9028Q2M as DAC model, RPi can play up to DSD128 (through DoP) and PCM 384KHz even without an ESS controller (Though you can still use it as real time stream monitor).I configured as this setup it works great!
That's a really good news.
@ Luchoh Thank you so much!
384KHzSettings.PNG by Ian, on Flickr
Have a good weekend.
Ian
Ian,
Why don’t you instead upsample?
HQPlayer will do it and Roon too - unless it’s on MacOS.
I just want to test the BridgePi on my current Volumio setup. I confirmed native DSD256 works perfectly without any problem. But I can not find a DSD512 file for now.
Regards,
Ian
BridgePi opens a window to USB streamer for all RPi gears
BridgePi is a small adapter board that can bridge a USB streamer into a RPi stack through GPIO.
This new concept opens a new window for all RPi gears, like DACs, TransportPi, FifoPi and so on, to work with higher performance USB streamers. Native DSD up to DSD512 and PCM 384KHz or higher, HQPlayer, Roon up-sampling.... all become possible.
I really like this concept. I finished the prototype last night and I'm working on testing them. I'm so exciting about the new discoveries it brings to build my digital transport and system.
BridegPiUSBstreamer by Ian, on Flickr
Ian
BridgePi is a small adapter board that can bridge a USB streamer into a RPi stack through GPIO.
This new concept opens a new window for all RPi gears, like DACs, TransportPi, FifoPi and so on, to work with higher performance USB streamers. Native DSD up to DSD512 and PCM 384KHz or higher, HQPlayer, Roon up-sampling.... all become possible.
I really like this concept. I finished the prototype last night and I'm working on testing them. I'm so exciting about the new discoveries it brings to build my digital transport and system.
BridegPiUSBstreamer by Ian, on Flickr
Ian
Last edited: