Dietpi: Amiberry fast boot doesn't wait for sound / issue with RPi 4 sound

[Cybolic]

ADMIN EDIT

Solution:

sed -i "/\(\(SOUNDCARD_TARGET_CARD\+\+\)\)/s/dtoverlay=vc4-'/dtoverlay=vc4-kms-v3d'/" /DietPi/dietpi/func/dietpi-set_hardware

---

Required Information

• DietPi version | 6.28
• Distro version | 10.2
• Kernel version | 4.19.93-v71+
• SBC device | RPi 4 Model B
• SDcard used | SanDisk Extreme Pro 32GB or Integral 16GB - doesn't matter

Additional Information (if applicable)

• Software title | Amiberry
• Freshly installed
• Can be replicated on a fresh installation of DietPi

Steps to reproduce

1. Enable Amiberry fast boot through dietpi-config
2. Reboot
3. Start any configuration (without disabling sound)

Expected behaviour

Amiberry should be able to start the emulation.

Actual behaviour

Amiberry freezes on the first black (emulation) boot screen and the log will say that it can't open an audio device.

Extra details

What I need to do to actually use Amiberry, is to:

• Quit the fast boot instance (rendering it useless)
• Launch dietpi-config and go to Audio Options
• Open the soundcard selection; select rpi-bcm2835-3.5mm; select Ok
• Re-open the soundcard selection; now select hw:0,0; select Ok
  If I don't follow the last step, ALSA won't work (alsamixer won't launch and Amiberry will keep freezing).

I've tried adding After=sound.target to /etc/systemd/system/amiberry.service but with ALSA not really starting correctly anyway, I'm not sure that helps anything.

[Cybolic]

Hmmm.. this issue might be something completely different.

I just noticed that dtparam=audio=off was still in config.txt, so this might actually be an issue with the G_CONFIG_INJECT function not correctly writing the setting to the file.

Changing that line to dtparam=audio=on and rebooting allowed the Amiberry fast boot to launch correctly.

[MichaIng]

@Cybolic
Many thanks for your report.

I just checked the code:

• Amiberry pulls ALSA
• ALSA is configured on RPi with rpi-bcm2835-auto, if you didn't apply a different sound card before already
• rpi-bcm2835-auto means HDMI sound output, if plugged and the monitor supports sound output, else 3,5mm jack... Actually would be nice the other way rount, 3,5mm as fast as something is attached (not sure if this can be known by hardware actually?) but my last info is that HDMI is indeed priorized then :thinking:.

So basically as you want 3,5mm jack output and have a generally audio-capable HDMI monitor attached, you need to select rpi-bcm2835-3.5mm indeed.

Another issue, if I think through it, is that, if the RPi onboard audio card is not yet enabled, the amixer settings (which are to switch between auto, HDMI and 3,5mm output) cannot be applied. I am not sure if those are still stored to ALSA settings file then or ignored completely. In letter case, there would be indeed just a two stage solution:

1. Enable onboard audio, reboot
2. Apply amixer settings to force 3.5mm or HDMI

For our Amiberry images it hence makes sense to enable onboard audio for first boot. When dietpi.txt is edited to enable/apply e.g. some USB DAC for first boot, onboard is automatically disabled for next reboot.

---

What I find strange is that you apply hw:0,0 again. Since this will disable onboard sound for next reboot! This auto-detected audio cards at the bottom of the list are more to support external sound cards that are not present in the above pre-defined list, in a generic way.

If you find time, could you go through the following steps:

• Select hw:0,0 or none if not already done
• Reboot, sound should be disabled now in both cases, hardware-wise
• Select rpi-bcm2835-3.5mm
• cat /var/lib/alsa/state and paste output here, to see if ALSA stores settings regardless of hardware being available already or not.
• Reboot, depending on above, 3.5mm output is now forced or not, hence an additional selection is required or not. The command to force 3.5mm manually and persistently btw is: amixer -c 0 cset numid=3 1; alsactl store

If indeed values are not stored wthout hardware being enabled/available, I'll edit the sound card selection so that amixer settings are applied automatically on next boot a single time, via script which removes itself once done, so that there is no manual two stage selection required.

[Cybolic]

I tested a bit and what I found what that sound just doesn't work on boot without either dtparam=audio=on in config.txt (manually set) or by doing the dietpi-config roundabout on each boot.
/var/lib/alsa/asound.state will have the same info no matter what I do.

• Set dtparam=audio=off in config.txt
• Selected hw:0,0
• Rebooted
• alsamixer reports no mixer device
• Selected rpi-bcm2835-3.5mm
• alsamixer reports no mixer device
• Selected hw:0,0
• alsamixer works
• Selected rpi-bcm2835-3.5mm
• Reboot
• alsamixer reports no mixer device
• Selected rpi-bcm2835-3.5mm
• alsamixer reports no mixer device

I did notice though, that when setting rpi-bcm2835-3.5mm then /etc/asound.conf is set with card 1 in both pcm.defaultand ctl.default (which doesn't work) but is set with card 0 in both when selecting hw:0,0 in dietpi-config (which works).

Perhaps this is actually the fix from #2173 causing an issue?

[Cybolic]

I think I was right on that one.

• Commented out line 1824 in dietpi-set_hardware
• Selected rpi-bcm2835-3.5mm
• Rebooted
• alsamixer works

[Cybolic]

For what it's worth, my config has dtoverlay=vc4-fkms-v3d and cat /proc/asound/devices gives:

  0: [ 0]   : control
 16: [ 0- 0]: digital audio playback
 17: [ 0- 1]: digital audio playback
 18: [ 0- 2]: digital audio playback
 33:        : timer

[MichaIng]

@Cybolic
Great find, so something has changed there. In the past, when enabling OpenGL, some additional hardware device was added as card 0, hence the onboard card moved to card 1. Seems this has changed, respectively the additional GL audio device is simply not added anymore, since not showing up in aplay -l anymore.

If you find time, could you test with dtoverlay=vc4-kms-v3d (replacing the old one, note the missing "f")?

---

Okay found it, this audio device only appears with the full KMS driver dtoverlay=vc4-kms-v3d, hence assumption with above is that the correct audio card is selected then, but for the fake KMS driver dtoverlay=vc4-fkms-v3d we need to leave card index untouched: https://github.com/raspberrypi/linux/issues/3181#issuecomment-526185508

[MichaIng]

Fixed with: https://github.com/MichaIng/DietPi/commit/d2ad522e40a7de689d644d909c02a809ccd6dcec
Changelog: https://github.com/MichaIng/DietPi/commit/ebee9cbd43995a0b822b8fee38eeb74ba7c18d13
I'll add this as live patch and merge it into out Amiberry image, where it is essential.

[MichaIng]

Live patch via MOTD or can be done manually:

sed -i "/\(\(SOUNDCARD_TARGET_CARD\+\+\)\)/s/dtoverlay=vc4-'/dtoverlay=vc4-kms-v3d'/" /DietPi/dietpi/func/dietpi-set_hardware