[PI5] audio HATs using Allo drivers fail about linux

[pelwell]

Does cat /sys/kernel/debug/devices_deferred return anything?

You could try with the slave parameter:

dtoverlay=allo-boss-dac-pcm512x-audio,slave

Otherwise it's unlikely you'll be able to get help here, since we don't have one and the manufacturer seems to be long gone.

[pelwell]

By the way, the following lines in your config.txt are unnecessary - the DAC overlay does it all:

dtparam=i2c_arm=on
dtparam=i2s=on

[klslz]

Thx. I guess it won't hurt to have these parameters in, even if redundant. ;)

I tried the slave option

###audio#####################
###disable onboard audio
dtparam=audio=off
###I2C
dtoverlay=i2c0-pi5
dtparam=i2c=on
###I2S
dtparam=i2s=on
###audiointerface_overlay
dtoverlay=allo-boss-dac-pcm512x-audio,slave

No success.

I also tried the 6.1 kernel. Same story.

No success

dmesg on 6.1.0-rpi7

[    1.558336] pcm512x 1-004d: Failed to reset device: -121
[    1.559065] snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517
[    1.564033] snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517
[    1.580564] snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517
[   11.748179] snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517

A lot has changed on the I2C part. Perhaps some incompatibilities!?!?
I found this:

Boss: physical pins 3-5-12-27-28-31-35-40 (SDA1-I2C ; SCL1-I2C ; 2S_BCLK ; ID_SD ; ID_SC ; GPIO6/DMUTE ; I2S_LRCLK ; I2S_DOUT).```

Here's a hardcopy.

![Allo-Boss-1 2-header](https://github.com/raspberrypi/linux/assets/5501886/81c79c81-9061-4b3d-84d6-afefb5b59c39)

[klslz]

I forgot:

cat /sys/kernel/debug/devices_deferred
soc:sound	

[pelwell]

And how about this one:

find 2>/dev/null /sys/devices -name "waiting_for_supplier" -exec grep -H . {} \;

[klslz]

find 2>/dev/null /sys/devices -name "waiting_for_supplier" -exec grep -H . {} \;
/sys/devices/platform/soc/107cd00000.local_intc/waiting_for_supplier:0
/sys/devices/platform/soc/107d517c00.gpio/gpiochip3/waiting_for_supplier:0
/sys/devices/platform/soc/107d517c00.gpio/gpiochip2/waiting_for_supplier:0
/sys/devices/platform/soc/107c411000.pixelvalve/waiting_for_supplier:0
/sys/devices/platform/soc/107d542000.avs-monitor/waiting_for_supplier:0
/sys/devices/platform/soc/107c501000.moplet/waiting_for_supplier:0
/sys/devices/platform/soc/107c003000.timer/waiting_for_supplier:0
/sys/devices/platform/soc/107c706400.hdmi/waiting_for_supplier:0
/sys/devices/platform/soc/107d508500.gpio/gpiochip1/waiting_for_supplier:0
/sys/devices/platform/soc/107d508500.gpio/gpiochip0/waiting_for_supplier:0
/sys/devices/platform/soc/107c701400.hdmi/waiting_for_supplier:0
/sys/devices/platform/soc/107c410000.pixelvalve/waiting_for_supplier:0
/sys/devices/platform/soc/soc:sound/waiting_for_supplier:0
/sys/devices/platform/soc/107c500000.mop/waiting_for_supplier:0
/sys/devices/platform/psci/waiting_for_supplier:0
/sys/devices/platform/timer/waiting_for_supplier:0
/sys/devices/platform/107c580000.hvs/waiting_for_supplier:0
/sys/devices/platform/axi/1002000000.v3d/waiting_for_supplier:0
/sys/devices/platform/axi/1000110000.pcie/pci0000:00/pci_bus/0000:00/waiting_for_supplier:0
/sys/devices/platform/axi/1000400018.syscon/waiting_for_supplier:0
/sys/devices/platform/axi/1000120000.pcie/pci0001:00/pci_bus/0001:00/waiting_for_supplier:0
/sys/devices/platform/axi/1000120000.pcie/1f00074000.i2c/i2c-1/1-004d/waiting_for_supplier:0
/sys/devices/platform/axi/1000120000.pcie/1f000d0000.gpio/gpiochip4/waiting_for_supplier:0
/sys/devices/platform/axi/1000120000.pcie/1f00100000.ethernet/mdio_bus/1f00100000.ethernet-ffffffff/waiting_for_supplier:0
/sys/devices/platform/axi/axi:gpu/waiting_for_supplier:0

[klslz]

Just tested the Allo Katana. The same thing. Hmmh, it's similar not working.

What changed: lsmod shows me now

snd_soc_audio_graph_card

plus entourage modules, when enabling

dtoverlay=allo-katana-dac-audio

The Katana module doesn't even get loaded.

These Allo drivers do load "regmap_i2c". Are we looking at a I2C issue?

[klslz]

One more. I'd like to add some more info.

A standard audio HAT that uses the basic I2S driver and no I2C works.

dtoverlay=i2s-dac

snd_soc_rpi_simple_soundcard    65536  0
snd_soc_pcm1794a       65536  1
snd_soc_core          294912  3 snd_soc_pcm1794a,designware_i2s,snd_soc_rpi_simple_soundcard
snd_compress           65536  1 snd_soc_core
snd_pcm_dmaengine      65536  1 snd_soc_core
snd_pcm               163840  5 designware_i2s,snd_compress,snd_soc_core,snd_soc_rpi_simple_soundcard,snd_pcm_dmaengine
snd_timer              81920  1 snd_pcm
snd                   147456  4 snd_timer,snd_compress,snd_soc_core,snd_pcm

**** List of PLAYBACK Hardware Devices ****
card 0: sndrpirpidac [snd_rpi_rpi_dac], device 0: RPi-DAC HiFi pcm1794a-hifi-0 [RPi-DAC HiFi pcm1794a-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

[klslz]

One more (from memory):

Allo Katana HAT: dtoverlay=allo-katana-dac-audio
The OS complains (dmesg) that the I2C frequency of "50000" is invalid. "100000" would be the first valid value.

Since the Katana overlay was somehow replaced by snd_soc_audio_graph_card, I am not sure if this matters.
The system seemed to be in a weird state.

Let me know if I can provide more infos. Or If I should run any tests - updated kernel/firmware etc.

[pelwell]

50kHz is slow, and not a standard I2C speed. The Pi 5 I2C block was only designed to run at the standard speeds - 100kHz, 400kHz and 1MHz, so the driver will be rejecting it. I don't know if it would be possible to achieve other speeds by essentially lying to the driver about source clock speeds. An alternative would be to use software I2C.

[klslz]

I see. But you realize that's a backward compatibility issue affecting perhaps a lot more 3PPs !?!? All earlier platforms supported 50k respectively <100k as it seems. I am not sure if 3PPs can cope (HW/firmware) with the new limit.

[klslz]

Ok. Just had a look at the .dts files . The Allo Katana is the only HAT explicitly specifying

allo-katana-dac-audio-overlay.dts: clock-frequency = <50000>;

[klslz]

Just to mention it. There are of course other non-Allo devices out there, such as the IMO excellent (p/p-r) InnoMaker DAC Pro that's still being actively sold, which fail on the RPi5.

[pelwell]

InnoMaker DAC Pro that's still being actively sold, which fail on the RPi5

Is that so? That would make the Inno-Maker website, which has a quick start guide for Pi 5 -
https://www.inno-maker.com/product/hifi-dac-pro/ - particularly disingenuous.

If there is a reasonably priced card that is recognised as not working on Pi 5 (and where the failure can't be attributed to the choice of I2S clock producer) then I should be able to obtain one for testing purposes.

[klslz]

Is that so?

Cynicism?

Can you provide any more advice how I can support you guys on the subject?

I am a hobbyist and I am not getting paid for the hours I am spending on the subject.
I am not even running these interfaces. I do have them around for running some tests once in a while.
My efforts are 100% dedicated to the community out there that is still happily running these interfaces.

Fact is. Until you guys introduced the RPi5, all these drivers were working flawless. Now they are basically useless.
It looks like a serious compatibility issue to me. An issue that we haven't really seen in the past.

The company Allo is dead, from what I know - they just disappeared in around 2022 and kept their homepage running. If there's nobody taking over the driver maintenance sooner or later, my guess - these drivers have to and will go. I have my doubts that companies like InnoMaker are taking over.

Gotta run. I'd like to enjoy my USB DAC. Again. If I can help, I am listening.

[pelwell]

Cynicism?

Cynicism on whose part? Pointing out a material difference - works vs doesn't work - in the information about what could be a useful test device is not cynicism. Your statement about that device not working on Pi 5 puts you at odds with the manufacturer who gives explicit instructions on how to make it work - surely that's enough cause for doubt.

I'm very prepared to accept that there may be incompatibilities with some devices - I've already fixed a few by making changes to the I2S driver - but before spending money on a sample device I'd like more than an uncorroborated assertion that there is a problem.

[pelwell]

Until you guys introduced the RPi5, all these drivers were working flawless. Now they are basically useless.

I don't follow the logic here. The drivers and existing soundcard installations continue to work exactly as they did on the same Pis they always have. If they can be made to also work on Pi 5 then we will do so, but that will likely depend on owners being sufficiently motivated to send their devices to us for testing.

[klslz]

Look I don't have time for this.

We already discussed the issue around the 50k I2C issue of the Katana dts - as one of probably several issues, since the Boss dts doesn't work either and won't issue that message . I posted the error message.
I am not the expert here. If Innomaker claims to be able to work with it. So be it. I read people reporting that the DAC doesn't work on the Pi5 - which would make sense to me. For sure I am not buying a device that runs high risk of not
working on your new platform, just to prove that it is not working.

[pelwell]

#5853 adds support for non-standard I2C rates. Anyone with the Katana DAC can see if the PR makes it work by waiting about until about 17:30GMT and running sudo rpi-update pulls/5853 (assuming any important data has been backed up).

[klslz]

I tested your changes on a fresh installed SD-card for the Katana driver. The behaviour slightly changed.

• modules get loaded.
• error messages look different now

root@pi5:~# cat /proc/asound/cards
--- no soundcards ---

root@pi5:~# uname -r
6.1.72-v8-16k+

root@pi5:~# cat /sys/kernel/debug/devices_deferred
soc:sound	asoc-audio-graph-card: parse error

root@pi5:~# dm
[    2.002183] brcm-pcie 1000110000.pcie: link down
[    6.934198] i2c_designware 1f00074000.i2c: controller timed out
[    6.934218] allo-katana-codec 1-0030: Failed to read Chip or wrong Chip id: -110

root@pi5:~# find 2>/dev/null /sys/devices -name "waiting_for_supplier" -exec grep -H . {} \;
/sys/devices/platform/soc/107cd00000.local_intc/waiting_for_supplier:0
/sys/devices/platform/soc/107d517c00.gpio/gpiochip3/waiting_for_supplier:0
/sys/devices/platform/soc/107d517c00.gpio/gpiochip2/waiting_for_supplier:0
/sys/devices/platform/soc/107d542000.avs-monitor/waiting_for_supplier:0
/sys/devices/platform/soc/107c003000.timer/waiting_for_supplier:0
/sys/devices/platform/soc/107d508500.gpio/gpiochip1/waiting_for_supplier:0
/sys/devices/platform/soc/107d508500.gpio/gpiochip0/waiting_for_supplier:0
/sys/devices/platform/soc/soc:sound/waiting_for_supplier:0
/sys/devices/platform/psci/waiting_for_supplier:0
/sys/devices/platform/timer/waiting_for_supplier:0
/sys/devices/platform/axi/1000110000.pcie/waiting_for_supplier:0
/sys/devices/platform/axi/1000400018.syscon/waiting_for_supplier:0
/sys/devices/platform/axi/1000120000.pcie/pci0001:00/pci_bus/0001:00/waiting_for_supplier:0
/sys/devices/platform/axi/1000120000.pcie/1f00074000.i2c/i2c-1/1-0030/waiting_for_supplier:0
/sys/devices/platform/axi/1000120000.pcie/1f000d0000.gpio/gpiochip4/waiting_for_supplier:0
/sys/devices/platform/axi/1000120000.pcie/1f00100000.ethernet/mdio_bus/1f00100000.ethernet-ffffffff/waiting_for_supplier:0

[klslz]

Just to mention it. I tried the same RpiOS image I ran on the Pi5 with exact the same settings on a Pi4.

root@pi5:~# uname -r
6.1.72-v8+

root@pi5:~# cat /proc/asound/cards
 0 [BossDAC        ]: BossDAC - BossDAC
                      BossDAC

This at least proves that OS and DAC are working.

I keep the fingers crossed that you guys find what's wrong with the Pi5.

[bendik]

Chiming in to stay in the loop. I can note that pipewire-pulse spits pcm512x 1-004d: No SCLK, using BCLK: -2 non stop.

uname -r
6.6.13-2-rpi
cat /proc/asound/cards
...
 4 [sndrpijustboomd]: JustBoomDac - snd_rpi_justboom_dac
                      snd_rpi_justboom_dac

[paul-1]

@pelwell I tested a Katana card with 6.1.73 with PR #5853 applied. The card loads fine and plays music on a pi5. Allo Boss plays fine too. The Boss Dac only required adding ,slave to the dtoverlay.

Note that I'm not using RaspiOS. I've not started playing with a 6.6.y kernel yet.

[bendik]

My previous comment was misinformed. I had by accident added two wireplumber services. 🤭

Justboom hat works better than ever now.

[klslz]

@pelwell I tested a Katana card with 6.1.73 with PR #5853 applied. The card loads fine and plays music on a pi5. Allo Boss plays fine too. The Boss Dac only required adding ,slave to the dtoverlay.

Note that I'm not using RaspiOS. I've not started playing with a 6.6.y kernel yet.

Good news. There's hope.

Now.

1. You run a different OS. And you build and manage your kernel differently - if I am not mistaken.
   You don't use the rpi-update images - correct ? Apples and oranges ??
   What makes the difference here !?!?
   I did realize that rpi-update is not properly updating all kernel related files (leaving a lot of dead bodies around). Perhaps there's an issue to be found in that department.
2. running the drivers in I2S slave mode - is a reasonable test scenario. These Allo audionterfaces (and a lot more followers) were built to run in master mode though to allow for (or enable) high quality audio on RPIs. I hope the kernel crew considers this.

@pelwell - did #5853 make it into the 6.6 branch by now ?

[klslz]

I just tested my own compiled 6.6.13 - 2712 - CL: e1a8b8b

The Allo Boss works with this kernel!!!! Great.

The Katana still complains about the 50kHz issue. Grrr.

@pelwell - speaks anything against merging your related correction into the 6.6. branch ??
I do have the feeling that'd be it.

[pelwell]

I delayed merging #5853 because of some feedback indicating a regression (#5853 (comment)), but that was with an invalid hardware configuration.

However, thanks to the positive feedback here I think it's probably better to merge now and get some wider testing before the next stable release - watch this space.

[pelwell]

#5853 has been merged, and rpi-6.6.y has been bumped to include the latest 6.1 commits. Let me know how you get on. There should be a new build available via sudo rpi-update rpi-6.6.y within the hour.

[klslz]

FYI - quick update - more tomorrow

p5 # cat /proc/asound/cards
 0 [Katana         ]: Allo_Katana - Allo Katana
                      Allo Katana

[klslz]

I am more than happy to announce that all my Allo interfaces are working now on the RPi5.
And I'm pretty sure that many maintainers and users will also be quite happy about it.

Great job @pelwell and team. It's been some heavy lifting. Thx a lot.

DuT: Allo Katana, Allo Boss

Devices have been tested against kernel branch 6.6 2712 CL: 3287b41 - my own custom build version

I2C controls (alsamixer) of these devices have been successfully (regression) tested
Allo Katana fed with complete sample rate series up to 384kHz has successfully been tested
Allo Boss I2S modes have been tested - both modes master and slave seem to work

Thx to @paul-1 who made me think perhaps not to use rpi-update for the kernel updates. For sure this tool needs some
maintenance.

Bottom line.

From my side "Case Closed".

PS: I just ordered the earlier discussed $60 Inno-Maker Sabre DAC HAT, simply to see how that one performs with the Katana driver.

[pelwell]

Thanks for the feedback. It will take a while for the patch to appear in more-widely-available firmwares, and because the patch changes the timing of all Pi 5 I2C accesses some caution is required before pushing it into a major release.

I'm going to close this issue now, and wait for the first "Pi 5 I2C differently broken" issue.

[klslz]

Just a quick note I wanted to add.
Did some more testing on the same env as earlier.

Allo Piano and the just received InnoMaker DAC Pro - in particular - also work.

p5 ~ # aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: IMDACPro [IM-DAC-Pro], device 0: 1f000a4000.i2s-allo-katana-codec allo-katana-codec-0 [1f000a4000.i2s-allo-katana-codec allo-katana-codec-0]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

(It's my own overlay ;) )

Everything looks stable over here.