Hi all,
new here and pretty new to the DIY DAC world.
I have setup a Raspberry Pi 3b+ with PurePi, FifoPi and a Innomaker DAC 5122 on top.
I have powered the FifoPi from the PurePi 3.3 power supply with short cables.
All other connections are through GPIO.
All seem to be up and running, but I cannot get any sound out of the DAC.
I tried different Moode settings such as Allo Boss DAC in slave and non slave mode, or IANFifo II but nothing seem to work.
Any idea what I might be doing wrong?
If I remove the FIFOPi and put the dac directly on top of the raspberry, it works.
Thanks for your help,
Simone
new here and pretty new to the DIY DAC world.
I have setup a Raspberry Pi 3b+ with PurePi, FifoPi and a Innomaker DAC 5122 on top.
I have powered the FifoPi from the PurePi 3.3 power supply with short cables.
All other connections are through GPIO.
All seem to be up and running, but I cannot get any sound out of the DAC.
I tried different Moode settings such as Allo Boss DAC in slave and non slave mode, or IANFifo II but nothing seem to work.
Any idea what I might be doing wrong?
If I remove the FIFOPi and put the dac directly on top of the raspberry, it works.
Thanks for your help,
Simone
Hi, thanks for your reply.
I am not sure I understood your indication: do you mean that my config is wrong and I need to change in moode’s settings or that this hardware cannot work together?
In case it’s only a matter of settings, could you suggest the right one?
There is an option to make the Allo Boss DAC driver (the one that should be used in Moode according to innomaker’s user guide) work in slave mode enabled, but it does not work either.
Let me know if you have an idea,
Thanks.
Simone
I am not sure I understood your indication: do you mean that my config is wrong and I need to change in moode’s settings or that this hardware cannot work together?
In case it’s only a matter of settings, could you suggest the right one?
There is an option to make the Allo Boss DAC driver (the one that should be used in Moode according to innomaker’s user guide) work in slave mode enabled, but it does not work either.
Let me know if you have an idea,
Thanks.
Simone
Last edited:
Hi @radiantradish, I tried your recommendation but Moode seems not to give a “slave enabled” option if I select allo-boss-dac-pcm512x audio in the dtoverlay section (although it does give it if I select Allo Boss DAC in the “named I2S device” section.
Am I missing something in your setting?
Am I missing something in your setting?
IIRC the "slave" option in the driver overlay for the Allo Boss only works with Allo Boss DAC + Allo Kali Recolcker hardware.
You could ask @iancanada if your master mode DAC will work with any of the FifoPi line but I thought that only sync mode (slave/passive) DAC's work with the FifoPi's.
@simonblaster :
I am afraid the boards just cannot be stacked and assumed to work together.
IMO it's important to learn a bit about I2S to understand what your various hardware pieces are actually doing.
I2S bus consists of lines: output data, input data, bitclock, frameclock. We will ignore the input data line here.
I2S bus on RPi can run in several modes:
Master - all three signals are generated by RPi. That means RPi must generate the clock signals. Since it has no free PLL onboard, the audio clock is generated via a rational divider. This divider outputs a very jittery signal which on average corresponds to the required audio clock frequency - for scope pictures e.g. https://www.diyaudio.com/community/threads/avoiding-rpi-master-i2s-fractional-jitter.376583/
Slave bitclock - the bitclock is generated by the DAC side, and RPi generates the frameclock and data out.
Slave frameclock - RPi generates bitclock and data out, with switching channels on the data out line according to external frame clock. This mode is very rarely used.
Slave bitclock & frameclock - all clock signals are provided by the DAC and RPi generates only the data output. This mode is optimal because it avoids the jittery RPi audio clock generator and allows the master clock (which is what really matters as the master clock runs the actual conversion) to be close to the DAC chip.
What FIFOPi does:
Most RPi DACs (basically for cost and software reasons) have no clock onboard and generate its master clock internally via PLL from the extremely jittery incoming clock provided by the RPi I2S running as master. FIFOPi acts as I2S receiver in slave mode (i.e. RPi generates all the clocks), buffers the data line (hence the FIFO in the name), and outputs a master I2S signal re-clocked by precise clock provided by the FIFOPi board.
What your Innomaker DAC 5122 does:
It is a proper DAC with two on-board clocks (each for its audio samplerate family). The clocks are switched using GPIOs 3 and 6 of PCM5122, operated via I2C registers by the RPi linux driver https://isrc.iscas.ac.cn/gitlab/mir...b8cd28633a65c0e0966087f534c3f4781873154d_0_39 As a result it runs in master mode, feeds the two clock signals back to RPi, and requires RPi I2S to operate in the slave mode (which the driver sets up correctly).
Since the master clock is right next to the chip, no jittery RPi clock is used, and there is no reason to reclock any I2S signals - that's how a proper RPi DAC connection should look like.
What happens if you stack the 5122 DAC onto the FIFOPi:
1. standard 5122 driver config with RPi I2S slaved - both RPi and FIFOPi on both sides will wait for the clock signals, FIFOPi I2S clock outputs will conflict with 5122 I2S clock outputs (both being in master mode) - no communication
2. 5122 driver switched to slave - RPi will generate jittery clock -> FIFOPi reclocks using its own clock (the clock family is recognized automatically) -> outputs I2S master -> 5122 in slave accepts the master clock signals, and using its own PLL it will generate internal master clock signal from the incoming lower-frequency I2S clock. This PLL generator is by principle more jittery than the precise master clock by the chip.
As a result the 5122 DAC crystals are avoided, and FIFOPi crystals are used. They are located much farther from the chip, you incurr the latency of the FIFO, and eventually the FIFO will over/underflow as the RPi and FIFOPi clocks are running independently.
This assumes the slave parameter of the PCM5122 driver configures the clock registers correctly to work OK as a slave in your specific setup.
On the other hand you will gain the galvanic isolation of the FIFOPi.
In my opinion the FIFOPi in this setup is redundant, just complicates the chain, and most likely worsens the performance (PLL, latency, eventual FIFO issues), unless the galvanic isolation is important for you.
I am afraid the boards just cannot be stacked and assumed to work together.
IMO it's important to learn a bit about I2S to understand what your various hardware pieces are actually doing.
I2S bus consists of lines: output data, input data, bitclock, frameclock. We will ignore the input data line here.
I2S bus on RPi can run in several modes:
Master - all three signals are generated by RPi. That means RPi must generate the clock signals. Since it has no free PLL onboard, the audio clock is generated via a rational divider. This divider outputs a very jittery signal which on average corresponds to the required audio clock frequency - for scope pictures e.g. https://www.diyaudio.com/community/threads/avoiding-rpi-master-i2s-fractional-jitter.376583/
Slave bitclock - the bitclock is generated by the DAC side, and RPi generates the frameclock and data out.
Slave frameclock - RPi generates bitclock and data out, with switching channels on the data out line according to external frame clock. This mode is very rarely used.
Slave bitclock & frameclock - all clock signals are provided by the DAC and RPi generates only the data output. This mode is optimal because it avoids the jittery RPi audio clock generator and allows the master clock (which is what really matters as the master clock runs the actual conversion) to be close to the DAC chip.
What FIFOPi does:
Most RPi DACs (basically for cost and software reasons) have no clock onboard and generate its master clock internally via PLL from the extremely jittery incoming clock provided by the RPi I2S running as master. FIFOPi acts as I2S receiver in slave mode (i.e. RPi generates all the clocks), buffers the data line (hence the FIFO in the name), and outputs a master I2S signal re-clocked by precise clock provided by the FIFOPi board.
What your Innomaker DAC 5122 does:
It is a proper DAC with two on-board clocks (each for its audio samplerate family). The clocks are switched using GPIOs 3 and 6 of PCM5122, operated via I2C registers by the RPi linux driver https://isrc.iscas.ac.cn/gitlab/mir...b8cd28633a65c0e0966087f534c3f4781873154d_0_39 As a result it runs in master mode, feeds the two clock signals back to RPi, and requires RPi I2S to operate in the slave mode (which the driver sets up correctly).
Since the master clock is right next to the chip, no jittery RPi clock is used, and there is no reason to reclock any I2S signals - that's how a proper RPi DAC connection should look like.
What happens if you stack the 5122 DAC onto the FIFOPi:
1. standard 5122 driver config with RPi I2S slaved - both RPi and FIFOPi on both sides will wait for the clock signals, FIFOPi I2S clock outputs will conflict with 5122 I2S clock outputs (both being in master mode) - no communication
2. 5122 driver switched to slave - RPi will generate jittery clock -> FIFOPi reclocks using its own clock (the clock family is recognized automatically) -> outputs I2S master -> 5122 in slave accepts the master clock signals, and using its own PLL it will generate internal master clock signal from the incoming lower-frequency I2S clock. This PLL generator is by principle more jittery than the precise master clock by the chip.
As a result the 5122 DAC crystals are avoided, and FIFOPi crystals are used. They are located much farther from the chip, you incurr the latency of the FIFO, and eventually the FIFO will over/underflow as the RPi and FIFOPi clocks are running independently.
This assumes the slave parameter of the PCM5122 driver configures the clock registers correctly to work OK as a slave in your specific setup.
On the other hand you will gain the galvanic isolation of the FIFOPi.
In my opinion the FIFOPi in this setup is redundant, just complicates the chain, and most likely worsens the performance (PLL, latency, eventual FIFO issues), unless the galvanic isolation is important for you.
Last edited:
Hi @phofman,
first of all, thank you so much for taking your time to come back to me and for your comprehensive explanation.
I have actually read it more than once as it really clarifies a lot of points I still struggle to understand form an audio (technical) perspective.
Following a couple of interesting projects (one of these from Gabster on YouTube) I am trying to experiment and develop a direct understanding of the different components in a streamer/DAC chain, and upgrade step by step to appreciate those changes outcome. My last step started from the assumption that a FIFO Pi, providing isolation and especially a better quality (and upgradable) reclocking than the one embedded in the DAC, would consequently improve its outcome. Evidently, I did not consider the constraints that you pointed out and that might be the cause of different results than what I expected. I am not concerned about this because I am not restrained to this particular DAC (I am trying a few of them in parallel) so I will be able to move to another one which has not clocks onboard.
At this moment, I am nevertheless still struggling in finding the right configuration for this setup, as I am still getting no sound at all out of the dac despite all my attempts, that included to force the slave mode in the DAC with the config line “dtoverlay=allo-piano-dac/pcm512x-audio,slave” directly written in the /boot/config.txt file.
Let me know if you have any idea of what might be wrong, and again, thanks a lot for your help and support.
Simone
first of all, thank you so much for taking your time to come back to me and for your comprehensive explanation.
I have actually read it more than once as it really clarifies a lot of points I still struggle to understand form an audio (technical) perspective.
Following a couple of interesting projects (one of these from Gabster on YouTube) I am trying to experiment and develop a direct understanding of the different components in a streamer/DAC chain, and upgrade step by step to appreciate those changes outcome. My last step started from the assumption that a FIFO Pi, providing isolation and especially a better quality (and upgradable) reclocking than the one embedded in the DAC, would consequently improve its outcome. Evidently, I did not consider the constraints that you pointed out and that might be the cause of different results than what I expected. I am not concerned about this because I am not restrained to this particular DAC (I am trying a few of them in parallel) so I will be able to move to another one which has not clocks onboard.
At this moment, I am nevertheless still struggling in finding the right configuration for this setup, as I am still getting no sound at all out of the dac despite all my attempts, that included to force the slave mode in the DAC with the config line “dtoverlay=allo-piano-dac/pcm512x-audio,slave” directly written in the /boot/config.txt file.
Let me know if you have any idea of what might be wrong, and again, thanks a lot for your help and support.
Simone
The FIFO is a workaround for improving the jittery clock of RPi. If you already have decent clock directly by the DAC chip, there is absolutely no reason to cripple your chain with a jittery master mode RPi, a latency-introducing and buffer-border-failure-prone FIFO in between, and PLL in the DAC at the end.
Why do you insist on this technically inferior path?
Anyway, if for some reason you want to change the I2S master/slave arrangement, I would suggest to start without the FIFO first. The FIFO should be transparent, so always good to start with the minimum configuration.
BTW - do you have a separate power supply for your FIFO/DAC? If not, no effect in galvanic isolation.
As of your slave arrangement - according to the PCM5122 datasheet the default value of Register 13 is 000 = PLL reference clock SCK . You need this to be switched to BCK as you want your BCK be PLLed to the DAC master clock - value 001. But IIUC the current driver does not do that. It could have worked in commit https://isrc.iscas.ac.cn/gitlab/mir...8cd28633a65c0e0966087f534c3f4781873154d_0_241 but this code was later removed by https://github.com/raspberrypi/linu...f2c2a8d8f93c521372bdba38a95808fed230L242-L258 and the current code does not seem to play with the PCM512x_PLL_REF register at all https://github.com/raspberrypi/linux/blob/rpi-6.1.y/sound/soc/bcm/allo-boss-dac.c#L279-L289 . Honestly, I am not surprised the support for slave mode was removed since it brings no advantage to that board.
Last edited:
I did a couple quick tests on kernel 6.1.21 with a Boss DAC and Kali setup and the "slave enabled" driver option works. Maybe some other code in the kernel is bumping the PCM5122 register in this particular DAC?
Here's some detail:
# Kernel 6.1.21, Boss DAC rev 1.2, Kali Reclocker (SBC01-021-002)
# Slave enabled (SOUND OUTPUT OK)
pi@moode:~ $ cat /boot/config.txt | grep allo
dtoverlay=allo-boss-dac-pcm512x-audio,slave
# dmesg
[ 62.983299] pcm512x 1-004d: No SCLK, using BCLK: -2
# Slave disabled (NO SOUND OUTPUT)
pi@moode:~ $ cat /boot/config.txt | grep allo
# dmesg
[ 102.507462] bcm2835-i2s 3f203000.i2s: I2S SYNC error!
# More dmesg
# Slave disabled (NO SOUND OUTPUT)
pi@moode:~ $ dmesg
[ 8.535246] bcm2835-codec bcm2835-codec: Device registered as /dev/video31
[ 8.535342] bcm2835-codec bcm2835-codec: Loaded V4L2 encode_image
[ 8.639922] snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517
[ 8.651974] snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517
[ 8.957146] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 9.049920] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 9.220438] cfg80211: loaded regulatory.db is malformed or signature is missing/invalid
[ 9.314061] snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517
[ 9.314285] brcmfmac: F1 signature read @0x18000000=0x15264345
[ 9.330262] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 9.332166] usbcore: registered new interface driver brcmfmac
[ 9.332424] snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517
[ 9.616030] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Nov 1 2021 00:37:25 version 7.45.241 (1a2f2fa CY) FWID 01-703fd60
[ 10.433837] pcm512x 1-004d: supply AVDD not found, using dummy regulator
[ 10.463432] pcm512x 1-004d: supply DVDD not found, using dummy regulator
[ 10.463662] pcm512x 1-004d: supply CPVDD not found, using dummy regulator
[ 11.447144] 8021q: 802.1Q VLAN Support v1.8
[ 12.029770] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[ 12.312296] 8021q: adding VLAN 0 to HW filter on device eth0
[ 12.317858] lan78xx 1-1.1.1:1.0 eth0: Link is Down
[ 17.925153] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 19.521028] ICMPv6: process `dhcpcd' is using deprecated sysctl (syscall) net.ipv6.neigh.wlan0.retrans_time - use net.ipv6.neigh.wlan0.retrans_time_ms instead
[ 36.261292] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled
[ 102.507462] bcm2835-i2s 3f203000.i2s: I2S SYNC error!
pi@moode:~ $
# Slave enabled (SOUND OUTPUT OK)
pi@moode:~ $ dmesg
[ 8.401848] bcm2835-codec bcm2835-codec: Device registered as /dev/video31
[ 8.401937] bcm2835-codec bcm2835-codec: Loaded V4L2 encode_image
[ 8.571626] snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517
[ 9.180350] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 9.250068] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 9.275569] cfg80211: loaded regulatory.db is malformed or signature is missing/invalid
[ 9.425690] snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517
[ 9.430452] brcmfmac: F1 signature read @0x18000000=0x15264345
[ 9.450252] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 9.452197] usbcore: registered new interface driver brcmfmac
[ 9.452422] snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517
[ 9.745437] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Nov 1 2021 00:37:25 version 7.45.241 (1a2f2fa CY) FWID 01-703fd60
[ 10.429991] pcm512x 1-004d: supply AVDD not found, using dummy regulator
[ 10.431081] pcm512x 1-004d: supply DVDD not found, using dummy regulator
[ 10.431298] pcm512x 1-004d: supply CPVDD not found, using dummy regulator
[ 11.445377] 8021q: 802.1Q VLAN Support v1.8
[ 11.920229] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[ 12.236073] 8021q: adding VLAN 0 to HW filter on device eth0
[ 12.241683] lan78xx 1-1.1.1:1.0 eth0: Link is Down
[ 17.892740] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 19.265393] ICMPv6: process `dhcpcd' is using deprecated sysctl (syscall) net.ipv6.neigh.wlan0.retrans_time - use net.ipv6.neigh.wlan0.retrans_time_ms instead
[ 36.340717] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled
[ 37.177668] pcm512x 1-004d: No SCLK, using BCLK: -2
[ 62.983299] pcm512x 1-004d: No SCLK, using BCLK: -2
pi@moode:~ $
Here's some detail:
# Kernel 6.1.21, Boss DAC rev 1.2, Kali Reclocker (SBC01-021-002)
# Slave enabled (SOUND OUTPUT OK)
pi@moode:~ $ cat /boot/config.txt | grep allo
dtoverlay=allo-boss-dac-pcm512x-audio,slave
# dmesg
[ 62.983299] pcm512x 1-004d: No SCLK, using BCLK: -2
# Slave disabled (NO SOUND OUTPUT)
pi@moode:~ $ cat /boot/config.txt | grep allo
# dmesg
[ 102.507462] bcm2835-i2s 3f203000.i2s: I2S SYNC error!
# More dmesg
# Slave disabled (NO SOUND OUTPUT)
pi@moode:~ $ dmesg
[ 8.535246] bcm2835-codec bcm2835-codec: Device registered as /dev/video31
[ 8.535342] bcm2835-codec bcm2835-codec: Loaded V4L2 encode_image
[ 8.639922] snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517
[ 8.651974] snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517
[ 8.957146] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 9.049920] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 9.220438] cfg80211: loaded regulatory.db is malformed or signature is missing/invalid
[ 9.314061] snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517
[ 9.314285] brcmfmac: F1 signature read @0x18000000=0x15264345
[ 9.330262] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 9.332166] usbcore: registered new interface driver brcmfmac
[ 9.332424] snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517
[ 9.616030] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Nov 1 2021 00:37:25 version 7.45.241 (1a2f2fa CY) FWID 01-703fd60
[ 10.433837] pcm512x 1-004d: supply AVDD not found, using dummy regulator
[ 10.463432] pcm512x 1-004d: supply DVDD not found, using dummy regulator
[ 10.463662] pcm512x 1-004d: supply CPVDD not found, using dummy regulator
[ 11.447144] 8021q: 802.1Q VLAN Support v1.8
[ 12.029770] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[ 12.312296] 8021q: adding VLAN 0 to HW filter on device eth0
[ 12.317858] lan78xx 1-1.1.1:1.0 eth0: Link is Down
[ 17.925153] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 19.521028] ICMPv6: process `dhcpcd' is using deprecated sysctl (syscall) net.ipv6.neigh.wlan0.retrans_time - use net.ipv6.neigh.wlan0.retrans_time_ms instead
[ 36.261292] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled
[ 102.507462] bcm2835-i2s 3f203000.i2s: I2S SYNC error!
pi@moode:~ $
# Slave enabled (SOUND OUTPUT OK)
pi@moode:~ $ dmesg
[ 8.401848] bcm2835-codec bcm2835-codec: Device registered as /dev/video31
[ 8.401937] bcm2835-codec bcm2835-codec: Loaded V4L2 encode_image
[ 8.571626] snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517
[ 9.180350] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 9.250068] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 9.275569] cfg80211: loaded regulatory.db is malformed or signature is missing/invalid
[ 9.425690] snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517
[ 9.430452] brcmfmac: F1 signature read @0x18000000=0x15264345
[ 9.450252] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 9.452197] usbcore: registered new interface driver brcmfmac
[ 9.452422] snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517
[ 9.745437] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Nov 1 2021 00:37:25 version 7.45.241 (1a2f2fa CY) FWID 01-703fd60
[ 10.429991] pcm512x 1-004d: supply AVDD not found, using dummy regulator
[ 10.431081] pcm512x 1-004d: supply DVDD not found, using dummy regulator
[ 10.431298] pcm512x 1-004d: supply CPVDD not found, using dummy regulator
[ 11.445377] 8021q: 802.1Q VLAN Support v1.8
[ 11.920229] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[ 12.236073] 8021q: adding VLAN 0 to HW filter on device eth0
[ 12.241683] lan78xx 1-1.1.1:1.0 eth0: Link is Down
[ 17.892740] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 19.265393] ICMPv6: process `dhcpcd' is using deprecated sysctl (syscall) net.ipv6.neigh.wlan0.retrans_time - use net.ipv6.neigh.wlan0.retrans_time_ms instead
[ 36.340717] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled
[ 37.177668] pcm512x 1-004d: No SCLK, using BCLK: -2
[ 62.983299] pcm512x 1-004d: No SCLK, using BCLK: -2
pi@moode:~ $
@TimCurtis : Thanks for the test. They actually implemented the slave mode directly in the ASoC codec code https://github.com/raspberrypi/linu...aebbceadd7fc7/sound/soc/codecs/pcm512x.c#L631 , that was probably the reason for removing it from the platform driver.
The "slave disabled" mode cannot work with the reclocker (also explicitely stated in the Kali reclocker specs), your results are perfectly correct. Still the fact is that using a reclocker with a master-capable DAC is technically suboptimal as master clock must be recovered via PLL in the DAC chip, instead of using the local precise crystal clock.
The "slave disabled" mode cannot work with the reclocker (also explicitely stated in the Kali reclocker specs), your results are perfectly correct. Still the fact is that using a reclocker with a master-capable DAC is technically suboptimal as master clock must be recovered via PLL in the DAC chip, instead of using the local precise crystal clock.
Ok, that clears it up.
I totally agree that reclockers are only for non-Master mode DAC's. The Allo Boss slave mode kludge catered to those enthusiasts that wanted to use the Kali clocks instead of the Boss clocks, maybe believing this would somehow be better.
As far as the OP issue goes I'm guessing the Innomaker DAC isn't designed to respond to the PLL switch from the Kernel and thus even with the slave mode option enabled there is still no sound.
I totally agree that reclockers are only for non-Master mode DAC's. The Allo Boss slave mode kludge catered to those enthusiasts that wanted to use the Kali clocks instead of the Boss clocks, maybe believing this would somehow be better.
As far as the OP issue goes I'm guessing the Innomaker DAC isn't designed to respond to the PLL switch from the Kernel and thus even with the slave mode option enabled there is still no sound.
Their design looks basically identical, same 5122 GPIOs for enabling the oscillators. @simonblaster : Maybe dmesg logs would tell more...
Also there is a major difference between
Also there is a major difference between
and
It could also be that even if the Innomaker DAC can be switched into slave mode via the Boss driver option there is still some compatibility issue with the DAC and FifoPi Ma. AFAIK none of the FifoPi's support master mode DAC's. It's possible that the Boss in slave mode may not work with the FifoPi's either but I don't own a FifoPi so not something I can test.
Re the piano overlay. The name is broken because of the slash and there is no "slave" driver option for that overlay. I'm not sure how that overlay made its way into the discussion?
dtoverlay=allo-piano-dac/pcm512x-audio,slave
The correct overlay names and options for Allo devices are below.
slave: If enabled, Boss and MiniBOSS DAC operate in slave mode required by Kali reclocker.
glb_mclk: If enabled, Kali MCLK is used and PLL for Piano 2.1 is disabled for best SQ.
Re the piano overlay. The name is broken because of the slash and there is no "slave" driver option for that overlay. I'm not sure how that overlay made its way into the discussion?
dtoverlay=allo-piano-dac/pcm512x-audio,slave
The correct overlay names and options for Allo devices are below.
Code:
Allo Boss DAC allo-boss-dac-pcm512x-audio slave
Allo Boss 2 DAC allo-boss2-dac-audio
Allo DigiOne allo-digione
Allo DigiOne Signature allo-digione
Allo Katana DAC allo-katana-dac-audio
Allo MiniBoss DAC allo-boss-dac-pcm512x-audio slave
Allo Piano 2.1 Hi-Fi DAC allo-piano-dac-plus-pcm512x-audio glb_mclk
Allo Piano Hi-Fi DAC allo-piano-dac-pcm512x-audioslave: If enabled, Boss and MiniBOSS DAC operate in slave mode required by Kali reclocker.
glb_mclk: If enabled, Kali MCLK is used and PLL for Piano 2.1 is disabled for best SQ.
@TimCurtis: thank you for you tests, really puzzling me how I still can’t get any sound.
@phofman: my bad, I copied from a wrong line but my tests were done with the config “dtoverlay=allo-boss-dac-pcm512x-audio,slave”
As to insisting on this test, I am trying to reproduce the results that a user discussed on a Facebook group talking about Allo Boss and FIFO Pi: he mentioned that, according to his different trials, quality improved drastically moving from internal DAC clocks to Fifo Pi, and an even bigger difference was obtained with Accusilicon’s. One of the tested dac was Innomaker Allo Boss with 5122 chip. So that’s where I started and was curious to find out. This is the original post if you are curious : https://www.facebook.com/groups/318663196139962/permalink/384550586217889/
@phofman: my bad, I copied from a wrong line but my tests were done with the config “dtoverlay=allo-boss-dac-pcm512x-audio,slave”
As to insisting on this test, I am trying to reproduce the results that a user discussed on a Facebook group talking about Allo Boss and FIFO Pi: he mentioned that, according to his different trials, quality improved drastically moving from internal DAC clocks to Fifo Pi, and an even bigger difference was obtained with Accusilicon’s. One of the tested dac was Innomaker Allo Boss with 5122 chip. So that’s where I started and was curious to find out. This is the original post if you are curious : https://www.facebook.com/groups/318663196139962/permalink/384550586217889/
Hi @phofman,
I completely understand your point and I agree with you that I might get to a different conclusion with my experiment. But that’s exactly what makes my own tests interesting, paired with having the chance to learn more about these components and their role, also considering the support that I received here and your very comprehensive notes.
here is an abstract of that post (directly translated from Italian, it might not be accurate):
“…..Some time ago I posted the beginning of what would have been an investigation into the Hi-End potential of SBC-based systems. Also having an I2S input on HDMI on the DAC I went in that direction, but not only. Obviously I assumed that it was necessary to focus only on the quality of the HAT. Below I summarize the conclusions supported by measurements and listening. I started with two HATs with the same chip: the TI 5122. The PiFi without reclocking and the Innomaker with two reclocking crystals. Obviously the latter is superior by definition, body, articulation etc etc... But what happens if we mount the PiFi on a better clock like the Allo Kali? What was previously unlistenable suddenly outclassed the Innomaker...Especially by feeding it DSD! But as Ian Canada warns in his considerations attached to the FifoPi, the quality of the crystals is the most important thing in the reclocking operation. So I take the former Innomaker leader and mount it on a FifoPi with Accusilicon upgraded crystals. Again a high jump, and this time ear-licking. I also put it in competition with the Saber 9038PRO with the usual on board microquartz.....but there is no competition. So conclusion n°1 the reclock is more important than the chip used. The next step concerned the power. Here I jump directly to the foreseeable conclusions: last but not least the switching power supply (with any clock the treble is always annoying and the female voices a bit shrill), follows a good linear power supply and battery power wins over all. …..”
I completely understand your point and I agree with you that I might get to a different conclusion with my experiment. But that’s exactly what makes my own tests interesting, paired with having the chance to learn more about these components and their role, also considering the support that I received here and your very comprehensive notes.
here is an abstract of that post (directly translated from Italian, it might not be accurate):
“…..Some time ago I posted the beginning of what would have been an investigation into the Hi-End potential of SBC-based systems. Also having an I2S input on HDMI on the DAC I went in that direction, but not only. Obviously I assumed that it was necessary to focus only on the quality of the HAT. Below I summarize the conclusions supported by measurements and listening. I started with two HATs with the same chip: the TI 5122. The PiFi without reclocking and the Innomaker with two reclocking crystals. Obviously the latter is superior by definition, body, articulation etc etc... But what happens if we mount the PiFi on a better clock like the Allo Kali? What was previously unlistenable suddenly outclassed the Innomaker...Especially by feeding it DSD! But as Ian Canada warns in his considerations attached to the FifoPi, the quality of the crystals is the most important thing in the reclocking operation. So I take the former Innomaker leader and mount it on a FifoPi with Accusilicon upgraded crystals. Again a high jump, and this time ear-licking. I also put it in competition with the Saber 9038PRO with the usual on board microquartz.....but there is no competition. So conclusion n°1 the reclock is more important than the chip used. The next step concerned the power. Here I jump directly to the foreseeable conclusions: last but not least the switching power supply (with any clock the treble is always annoying and the female voices a bit shrill), follows a good linear power supply and battery power wins over all. …..”
