Public Beta Test: Audio Without Compromise - Refining the Future of Volumio on Bookworm

Volumio Development Volumio Beta Testing
, ,
205

can you please disable mediatek/BT_RAM_CODE_MT7961_1a_2_hdr.bin, it only segfauls wifi for mt7961 and they dont have bluetooth anyway, if not please tell me how to blacklist that specific firmware, so i wont have to fix it every update. my wifi worked on older versions of volumio.

1 Like
206

Since yesterday i get a message box when trying to start webradio after reboot
After going to play options and save the i2s device configuration without altering anything it saves the config and successfully starts the sound device.
After that everything is working until the next reboot.
Surprisingly this was not the case the first few days with v4.013

Pi3b
Allo Kali + Piano 2.1 in dual mono mode
Volumio v4.013
Plugins:
Spotify
Autoruns (doesn’t work)
Backup + Restore

image
image927×302 56.7 KB

EDIT:

a few hours and some reboots later the issue solved itself and i cannot reproduce it any longer…

207

Hello ,
I have flashed volumio 4.013 on a new sd card , I can ping it but I can not configure it …
I can not acces web gui … it has assigned a static ip adress .
Thanks

208

Volumio doesn’t assign a static IP, without manually doing it.
With a bit of luck you can access the device via the internal hotspot and reconfigure the etwork for automatic IP.

209

After posting my issue, due to Volumio NOT enable my SPDIF output on my motherboard, in ALPHA test, althought it was mention that it wiil be solved in next 2 or 3 releases, i found out that the problem still exists…i have to SSH, enter in alsamixer and manually enable spdif/16…
Is it worth try to help, when things stay the same? It’s really disappointing…don’t get me wrong.

210

@Rui_C

Let’s keep things encouraging, remarks like ‘It’s really disappointing’ aren’t helpful at this stage. The transition to Bookworm requires significant time and effort, and the dev team is fully focused on addressing all reported issues. While some fixes are straightforward, others demand days of debugging and testing. We’re still in beta, and every bit of patience and support makes a difference.

1 Like
211

@Weathen
Like it was said, don’t get me wrong, But it seems that issues are reported and then forgotten.
However, i’ll keep help you, as much as i can.

Another issue: volume slider do nothing…in app and in browser. I only can lower or raise volume in my amp.

212

Hey @balbuze,

Thanks for your report and for sharing the log.

We’ve confirmed the issue on V4.0.13 for Raspberry Pi 5:

  • When using software volume (softvol) with an I2S DAC, the volume is reset to 100% after reboot, despite a configured startup value.
  • This happens only when rebooting via SSH or system-level commands (reboot, shutdown -r now, etc.), not when using the Volumio UI.

Root cause:
Reboots from the UI invoke the full shutdown handler (volumio.shutdownd), which ensures mixer and plugin states are saved properly.
Reboots via shell bypass this, preventing alsactl store from running and resulting in:

  • Mixer restore failures (exit code 99)
  • MPD falling back to default softvol at 100%

Recovery steps:
To restore a working state:

  1. SSH into the unit and manually remove all duplicate DAC overlays from /boot/config.txt

  2. In the UI:

    • Go to Playback Options, switch output to HDMI or Jack
    • Set Mixer to Software
    • Reboot from the UI

  3. Once booted:

    • Go back to Playback Options, switch output back to I2S DAC
    • Reboot from the UI

  4. Reconfigure any final output or mixer settings as needed, again followed by a UI reboot

This sequence re-initializes the system properly and ensures mixer state is valid.

Next steps:
We will investigate why alsactl store and mixer state are skipped during non-UI reboots and consider adding a systemd override or fallback handler to capture state persistently.

Kind Regards,

213

Hey @Galo5,

Thanks for confirming.

What you’re seeing aligns with a known behavior where reboots initiated via the shell (like reboot or shutdown -r now) bypass Volumio’s shutdown handler (volumio.shutdownd). That handler is responsible for:

  • Saving mixer state via alsactl store
  • Persisting plugin states cleanly

When it is skipped:

  • alsactl restore fails on next boot (commonly with exit code 99),
  • MPD falls back to its default software volume, which starts at 100%,
  • Result: your last-set value (e.g., 30) is lost, and you’re greeted with full blast.

No logs

This is just a working theory.
We do not proceed without logs.

Please reproduce the issue under known conditions and send a log via http://<volumio_ip>/dev.

Otherwise, it remains speculative.

Kind Regards,

214

Hey @Plunder,

Thanks for providing both logs and outlining your setups clearly. After a thorough review, the main issue affecting both devices appears to be Wi-Fi authentication instability, not a direct failure of Webradio or audio playback.

Key finding: 9 authentication rejections (status_code=16)

Your devices are attempting to associate with the SSID FiberFirst, but the access point (AP) is rejecting the connection. This is confirmed by:

wlan0: CTRL-EVENT-ASSOC-REJECT ... status_code=16

According to the IEEE 802.11 spec:

  • Status Code 16 = Authentication rejected because of challenge failure
  • Usually triggered by AP-side rejection, band steering confusion, mesh roaming issues, or driver/firmware interaction problems

Breakdown of all occurrences:

Unit 1 – RPi5 with Touch Display + Topping E50:

  • Jun 25 17:41:25 - BSSID 00:00:00:00:00:00
  • Jun 25 19:53:49 - BSSID d8:44:89:52:61:b2 (twice)
  • Jun 25 19:53:53 - BSSID d8:44:89:52:61:b2
  • Jun 25 19:54:44 - BSSID d8:44:89:52:61:b2

Unit 2 – RPi5 with MSD + Topping D10s:

  • Jun 21 19:15:30 - BSSID 00:00:00:00:00:00
  • Jun 25 19:48:51 - BSSID d8:44:89:52:61:b2 (three times in rapid succession)

These rejections cause:

  • Wi-Fi disconnects
  • Streaming to stop
  • UI to hang or become unresponsive
  • In one case, Wi-Fi settings are lost and must be reconfigured manually after reboot

Next step: need your hardware topology

To assess whether this is purely Wi-Fi-side or impacted by USB/power bus behavior, please provide:

  1. Power supply model and specs (voltage, amperage, USB-C or GPIO powered)
  2. USB DAC port connection (USB 2.0 or 3.0)
  3. Use of any USB hub (active or passive)
  4. How the display is powered (direct from Pi or external PSU)
  5. Any other connected devices (GPIO, HDMI, USB peripherals)
  6. Any cooling solutions or overlays in use (fan HATs, etc.)

We’re not seeing strong indicators of a power issue in logs, but need to rule out USB controller edge cases or enumeration timing problems on RPi5 under load.

Kind Regards,

215

Hey @rost21A,

Thanks for confirming the issue persists in Volumio 4.013 on Raspberry Pi 2, 3, and 4.

This is a known problem originating in the backend, and it affects both the Buster and Bookworm versions. I am not part of the official Volumio team, so I can’t apply fixes directly, but I will escalate this internally for investigation.

Appreciate your patience and input.

Kind Regards,

216

Hey @RedEyeNinja,

Thanks for the report. Based on your experience with 4.013 on Pi5 8GB + NVMe, here’s a structured and verified breakdown.

Issue summary

  • Initial Internal Server Error

    • Occurred after fresh flash and idle time.
    • Resolved by disabling Wi-Fi immediately after setup.

  • NVMe Boot Failure After Reboot on New Subnet

    • After setting Custom DNS and moving to another subnet:

      • Device fails to boot entirely from NVMe.
      • No logs available due to complete boot halt.

Possible failure domains (fact-based)

  1. Bootloader/Init Stack

    • Pi5 boot behavior differs when network topology changes, especially under EFI/NVMe root.
    • Boot or firmware might hang if DHCP fails and fallback DNS cannot resolve key endpoints (e.g., Volumio OTA, MyVolumio).

    Relevant Raspberry Pi firmware issue (upstream):
    https://github.com/raspberrypi/firmware/issues/1901 - boot regression with NVMe under specific EEPROM + network conditions.

  2. Wi-Fi stack causing critical failure

    • Internal server error might trace back to wpa_supplicant failing or interface rename (e.g., wlx*) not matching expected wlan0, breaking network binding in early userland.
    • Volumio backend services like volumio-remote-updater or volumio-state are not network-failure tolerant at this stage.

  3. Custom DNS and networkd interaction

    • Switching subnet post-DNS set can break systemd-networkd startup, especially if persistent lease caching is not cleared. That can lead to unresponsive service dependencies on boot.

Kind Regards,

1 Like
217

Hey @Josh2000,

Thanks for the report.

Unfortunately, without logs from the moment the issue occurs, we cannot analyze the root cause. Any assumptions about overlay loading, device timing, or module behavior would be speculative at this point.

If the issue reappears, please capture a full log immediately via
http://<volumio_ip>/dev
and share the link here so we can investigate properly.

Until then, the issue must be considered isolated to your setup only.

Kind Regards,

218

oh sorry - i created and a uploaded a log but forgot to copy the link here :slight_smile:
But as mentioned in the EDIT the issue disappeared after a while and i cannot reproduce

http://logs.volumio.org/volumio/ICEY88u.html

219

Hey @Rui_C,

Thanks for reporting back. Just to clarify - this SPDIF issue was previously addressed by @gkkpch in a dedicated PR, which added an amixer command to unmute SPDIF (IEC958 Playback Switch) during system initialization. That fix was committed and the issue marked resolved at the time due to no further feedback.

Since you’re now experiencing the same issue again, we need to verify whether:

  • The fix is missing or regressed,
  • Your system is using a different card or mixer config,
  • Or something else is interfering with SPDIF init.

To proceed, please provide the following from your current BETA setup:

  1. Full system log:
    Open http://<your_volumio_ip>/dev and paste the log URL here.

  2. Your motherboard model and audio chipset (e.g., Realtek ALC892, Intel HDMI Audio, etc.).

  3. Output from this SSH command, before doing anything manually:

    amixer -c 0

  4. If you are making any manual changes to enable SPDIF, please specify the following:

    • Path and file name you are editing
    • The original content before the change
    • The content after your change

This is important so we can understand exactly what you’re doing manually, and whether it’s something the system should already be applying based on the previously merged fix.

Once we have these, we can determine whether the fix is missing, needs board-specific adaptation, or has regressed in the current builds.

Kind Regards,

220

Hey @Josh2000,

Thanks for following up with the log link.

From the log contents, the playback error you encountered:

Failed to open "default detected output" (sndio); Requested audio params cannot be satisfied

is confirmed to be ALSA-related, and occurred because MPD could not route audio to the DAC during early startup.

Key findings:

  1. Your DAC (PianoDACPlus) is detected properly as card 2, but MPD uses a complex virtual routing layer (volumioHw -> volumioOutput -> postMultiRoom) and likely tried to initialize before the DAC was fully available in the device tree.

  2. The ALSA restore service failed:

alsa-restore.service: Failed with result 'exit-code'.

Exit code 99 typically means alsactl restore ran before the card was initialized.

  1. Supply regulators AVDD/DVDD/CPVDD were not found for the DAC overlay, and dummy regulators were used:
pcm512x 1-004d: supply AVDD not found, using dummy regulator

This is expected on some DAC setups and not fatal.

  1. User fix (“re-saving I2S DAC in playback settings”) retriggers the overlay binding and resets ALSA state, which is why it worked.

Conclusion:
This looks like a cold-boot race condition in ALSA device readiness on the Bookworm kernel (6.12.27-v7+). It resolved itself later likely due to changes in boot timing, SD card I/O delay, or power variance.

We need to keep an eye on this condition as it suggests a kernel regression of sorts.

Kind Regards,

221

Log after turning on Volumio:
http://logs.volumio.org/volumio/OJc27JF.html
Log after switching on PLAY:
http://logs.volumio.org/volumio/KuSBuKx.html

And who is “Galo5”? Again

@Wheaten ban the @nerd. He keeps calling names :rofl: :rofl: :sneezing_face:
tie-knot

1 Like
222

Yeah he does that on purpose.
He almost calls you a melon… Just 2 more letters. @Gelo5, @Galo5, @Gali5, @Galia5.
image

But we can refer to him as @QuirkNerd or @neard

1 Like
223

Hey @Gelo5,

Thanks for sharing the logs. I reviewed both:

1. Boot log – OJc27JF

  • System initializes correctly.
  • All core services including MPD and ALSA appear stable.
  • No immediate errors tied to audio or playback observed on boot.

2. PLAY pressed log – KuSBuKx

  • Playback initiates successfully.
  • volumio-state-machine transitions state to play.
  • MPD confirms playback start, stream appears to resolve without backend error.

There are no critical issues in either log - looks like your system is behaving well during boot and audio playback. If you’re debugging a specific symptom (e.g. no sound, stuttering, incorrect metadata), please clarify so we can isolate further.

As for the Galo5 vs Gelo5 naming humor - it’s all part of the community charm. Just two vowels away from a fruit salad. No bans here, just good banter - and maybe a second helping of melon if you hang around too long. Keep the slices coming, @QuirkNerd is always hungry for puns.

Kind Regards,

2 Likes
224

Hey @hifiswede,

Thanks for reporting the issue. We understand how frustrating it is to deal with recurring breakage, especially from a firmware file you don’t even use.

Before we can take action or suggest a safe workaround, could you please provide the following so we can reproduce and verify:

  1. A log link from your affected system

    • You can generate it by visiting http://<your-volumio-ip>/dev and clicking Submit log, then paste the URL here.

  2. Details about your setup:

    • What device are you running Volumio on? (e.g., x86 PC, Raspberry Pi, or something else)

    • Is MT7961 onboard or a USB module?

    • Volumio version that broke it vs the last one where Wi-Fi worked.

    • Output of:

      lsusb
dmesg | grep -i mt7961

We also need to confirm if your specific MT7961 hardware variant truly lacks Bluetooth, or if it’s a driver regression we should fix upstream. Once we have that info, we’ll suggest a way to permanently block the problematic firmware if needed or remove it from future builds if universally harmful.

Looking forward to your reply.

Kind Regards,