Appreciated. Your time and continued contributions to Alpha and Beta testing - especially with hardware configurations that may not be widely covered - are valued.
To clarify: none of this is or has been personal. There is no vendetta, no intention to diminish your efforts, and no suggestion that your testing is unwelcome or unimportant.
My focus in these replies is and has always been:
To separate verified facts from assumptions
To maintain traceable context for every regression or claim
To prevent conclusions from being drawn too early in cases where only a single user or setup is involved
That doesnāt minimize your work - it ensures the process remains stable and correctable when more data becomes available. Without logs and edge-case testers like yourself, the build wouldnāt improve.
Regarding direction and usage
You raised important questions:
Is this feedback going toward a better version?
Will the outcome serve all users, not just premium ones?
While I canāt speak on behalf of Volumioās commercial roadmap, the Bookworm-based Beta builds are clearly scoped as platform-wide upgrades, not gated behind premium-only offerings. Every kernel, overlay, driver, and plugin refinement benefits core functionality - including yours.
If this changes at any point, that deserves open communication from the Volumio team.
Closing
Letās stay focused. If you do recall or locate the version where HDMI/I2S playback at 192/24 worked on the same hardware chain, that will materially help backtrack this behavior.
Thanks again for sticking with it - and for your patience when the process slows for validationās sake.
Thatās the piece we needed - thanks for confirming the regression began with:
v0.068 (May 21, 2025): 192/24 via I2S/HDMI worked
v0.069 (May 23, 2025): 192/24 via I2S/HDMI dropped out
Reference post and log:
āGot around to testing v0.069 on Pi5 8GB w/ NVME boot from clean flash. Only issue I have to report is i2s/hdmi dropping out on 192/24ā¦ā uiSRDIy.html
This isolates the failure window to a two-day commit delta, and confirms that the issue appeared before DSD or plugin paths were touched in that run - simplifying triage.
Next steps (Internal)
Weāll now:
Review all PRs, commits, and overlay/firmware adjustments made between v0.068 and v0.069
Focus especially on ALSA routing, HDMI I2S overlay order, and MPD pipeline flags for 192kHz
This is going to take a bit of time; once thatās diffed, weāll respond with either a patch, a kernel-level trigger workaround, or escalation if it involves Pi firmware blobs.
Appreciate your patience in pushing this through.
Letās keep it moving.
Quick clarification request to ensure weāre tracking this regression accurately.
Iāve reviewed all PRs and commits between v0.068 (May 21) and v0.069 (May 23). There were no changes during that window to:
HDMI
I2S
MPD
ALSA routing
Kernel
Audio overlays
The only updates in that period were:
x86 kernel and firmware handling
rfkill improvements on Raspberry Pi (unrelated to playback chain)
Also, based on the latest hardware output:
card 1: bcm2835 Headphones
This confirms the board in use is not a Pi5, since Pi5 does not expose the legacy analog headphone output at all. That device only appears on Pi4 or earlier.
Weāre currently operating on the assumption that:
The original 192/24 I2S/HDMI regression you reported between v0.068 and v0.069 was seen on a Pi5
Later test logs (including the one showing the headphone output) were from a separate Pi4 used with the HiFiBerry Digi
Can you confirm:
Was the regression you reported between v0.068 and v0.069 (re: HDMI/I2S audio dropout) observed on Pi5, or was that actually on Pi4?
If Pi5: do you still have a log showing HDMI (card 0) without the headphone output present?
If Pi4: we can adjust the scope accordingly and re-analyze routing and format fallback for that platform.
This will help ensure weāre tracking the correct hardware and isolating the regression with full fidelity.
Thanks again for your persistence and detail. Hereās a full update on where things stand after a complete audit:
1. Confirmed range
v0.068 (May 21): HDMI and I2S playback at 192/24 reported as working.
v0.069 (May 23): Playback fails silently; DAC shows lock, but no audio.
Confirmed against:
Pi4 with HiFiBerry Digi (I2S S/PDIF HAT)
Rootfs and boot data from both versions
2. Kernel and firmware
Kernel version: 6.12.27-v8+ #1876
Identical in both v0.068 and v0.069
/boot/start4.elf, fixup4.dat, and all overlays: no change
Device Tree: same DTB
No changes in kernel configs
3. ALSA, MPD, and Audio Stack
alsa-utils, libasound2, and all audio libraries: unchanged
mpd.conf and MPD version: same across both versions
No diffs in /etc/asound.conf or custom routing
No plugin modifications that would affect audio
4. Root Filesystem Diff
A complete diff between 0.068 and 0.069 rootfs revealed:
Only changes to wireless.js and volumioconfig.sh (for hotspot and rfkill)
No changes in /volumio, /usr/lib/node_modules, or systemd audio targets
No new backend code, overlay logic, or boot-time routing updates
5. I2S/HDMI HAT Considerations
The HiFiBerry Digi is a WM8804-based I2S S/PDIF transmitter.
It is sensitive to bit clock timing stability, especially at 192kHz.
No master clock (MCLK) is exposed by the Pi; WM8804 uses BCLK as source.
This makes it susceptible to edge instability or DAI link settling issues at boot, even when the configuration has not changed.
6. Scope of problem
There is no software, config, kernel, overlay, or firmware change that explains the problem
The issue is non-deterministic, possibly influenced by HDMI hotplug state, DAC cold/warm power, or PLL lock condition
Diagnostic suggestion
To narrow this further:
Try pinning clocks with force_turbo=1 and core_freq=500 in /boot/userconfig.txt
If still reproducible, we may need to:
Introduce a dtoverlay variant that stabilizes MCLK output
Modify WM8804 startup timing via a custom overlay
Delay MPD start until audio DAI locks are confirmed
Let me know if you want help writing a minimal .dts overlay for testing clock parameters, or if youād like to validate MPD behavior by deferring its systemd startup with a condition on sound.target.
Volumio v 4.010
RPi 4
IQAudio DAC+
NAS: OMV v7
Music scan is missing Artist listings, Albums - not sure of the exact extent, but approximately 70 albums, 768 tracks http://logs.volumio.org/volumio/AocmMea.html
Have repeated scan with volumio 3.812 with no problems
Thanks
Youāre likely encountering a known issue with Volumio 4.x on Bookworm and SMB shares using vers=3.1.1. Your log confirms both of your NAS mounts use this protocol version:
vers=3.1.1
This version has been observed to cause incomplete music scans, missing artist and album metadata, especially with embedded ID3 parsing enabled. Itās a regression introduced due to how the Bookworm kernel and CIFS stack handle directory and metadata access.
Back again with initial set-up of Raspberry Pi 2B with 4.010
Started with new flash of 4.010 with Rt 5370 wipi USB no hotspot.
Shut down , restart with MT7612U Dual band USB , hotspot created.
Hotspot set up wizard wasnāt perfect, the yes/no buttons were not displayed correctly and after selecting I2S DAC the only selections were the last 6 on the list. Onto network, I was expecting to see some options for the two frequencies but didnāt but wifi was available and selected . The hot spot disappeared as expected. Selected new address for GUI and filled in my password etc and was the able to select the correct DAC. After restart I realised that when I plugged in the MT7612U I had the left the RT5370 and removed the USD SD card reader. By the flashing of the led on the RT5370 I could tell it was this USB that was active. I restarted with the RT5370 removed but the IP address for the GUI was set at the default 127.0.0.1 rather than 192.168.1.173. Restarted with RT5370 all OK.
@nerd
I have done a clean install of 4.010.
I am using a wifi dongle that I had working previosly on 4.005 ( tp-link, ac 600 archer t2uh).
I comes up on the hotspot everytime, however when i run the first start up wizard, i cannot connect to my wifi network. It says "the unit will connect to network xxxxx when first setup completes. It hangs there.
I played around with this for quite a while, and once I had it actually connected to my 5G network with good speeds! Donāt know How i did that. Anyways I think every new vesrion is getting closer and closer! Thanks for all the effort!
@jocoman, I believe this has been reported as an intial start issue with wifi only.
Could you try this again and when it hangs (do wait a litle), just poweroff and reboot and check whether it has connected correctly?
This would confirm what has been reported before.
@gkkpch
Repeated the test. did not reboot this time.
Came up on the 2.6 ghz network.
Changed over to the 5G network.
System changed over.
did a reboot.
system still running the 5G.
Did a second reboot, came back on the 5g. So great.
Going to install the Touchscreen software nowā¦
regards
I have a strange issue with my RPI . In the router I have set a static IP adress.
I have flashed V4.010 but it get the 169.254.96.115. When I scan the QR code , the WEB UI page is not oppen it so I have conenct to the Volumio Hotspot and I have assigned the same IP address that it is in the router for this RPI. I have rebooted the RPI and it has the same IP adress 169.254.96.115. With the v3.812 I have disabled also the Wifi but still can not access the WEb UI ,
the connection to Volumio sudenly stopped yestarday .
Since I have assigned a static IP adress In the router after flashing the volumio OS, the same Ip adress was assigned as wriiten in I have also this error
@balbuze I have flashed another sd card , connected to the hotspot , perform the steps and reboot but again the Ip adresa is 169.254.96.115 ā¦ after the configuration o should disable the hotspot or wireless confit ? It appears that the Ip addressed is not saved .
Thanks
I did a full rescan as suggested, but used āvers=2.0ā This did sort out album and artist problems. However there were still missing items. Looking at the logs again I realised that the problem was being caused by file names that were too long and the scan failed to access them correctly. I spent 2 - 3 hours sorting out the file names and did a full rescan - problem solved! Thank you for pointing me in the right direction. Interesting that the file name length s not a problem in v3.812 and previous versions - progress?
please fix the inread of usb devices likes hdd and usb sticks. It is horribel. It is really annoying it is mostly not working if its works, its really slow. ive a big music collection. Above 4 tb.
