Jump to content
IGNORED

dmesg errors in Raspbian with Allo Mini Boss DAC


Recommended Posts

I am setting up an Airplay-enabled audio stream receiver to stream-enable my Hi Fi system, using the Allo Mini BOSS DAC connected to a Raspberry Pi.

I originally planned to use the Raspberry Pi Zero 2 with WiFi, but these seem to be virtually unobtainable at the moment, and hence have repurposed a Raspberry Pi B2 in order to get it going, using Ethernet.

The Raspberry Pi is using Raspbian LITE bullseye and has been fully updated (sudo apt-get update & & sudo apt-get upgrade) and the Pi's firmware itself updated (sudo rpi-update).

The Airplay system seems to work fine, with excellent audio quality, but I am seeing about nine dmesg messages on boot, before the Airplay part is initialized:

snd-allo-boss-dac soc:sound: snd_soc_register_card() failed: -517

I have searched the Internet for this message, without any hits.

Should I be worried about this message? What does it indicate? Am I loading drivers in the wrong order in /boot/config.txt?

I would be grateful for any pointers.

 

 

 

 

Link to comment

snd_soc_register_card returns -EPROBE_DEFER

 

It seems raspberry-pi calls DAC initialize when DAC module is not ready yet and linux kernel will attempt to initialize the DAC in later stage of the start-up sequence

 

https://github.com/raspberrypi/linux/blob/rpi-5.15.y/sound/soc/soc-core.c

sound/soc/soc-core.c:2342 snd_soc_register_card
  calls snd_soc_bind_card


sound/soc/soc-core.c:1979 snd_soc_bind_card
    calls soc_bind_aux_dev

    ...


sound/soc/soc-core.c:1586 soc_bind_aux_dev
    may return -EPROBE_DEFER (-517) when soc_find_component is failed


 

Sunday programmer since 1985

Developer of PlayPcmWin

Link to comment

Hi Yamamoto. Thanks for the reply and link to the code. I rather thought that it might be a timing issue. I wonder if there is a way to solve this. I have tried delaying kernel boot by putting "boot_delay=30" into the Pi's config.txt, which does indeed delay kernel boot by 30 seconds, but unfortunately, it also delays the DAC initialize call, which means that the kernel is still trying to use the DAC before its initialization is complete. So, is it possible to do any of the following (but I don't know how to do them):

  • Initialize the DAC device earlier in kernel start.
  • block (with timeout) calls to the DAC driver until the DAC reports that it is ready.
  • silently abort calls to the DAC driver until the DAC reports that it is ready.
  • ... any other solutions that someone can think of.
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...