HifiBerry Digi won’t work with generic I2S driver, the WM8804 must be initialized and configured via i2C by the kernel driver
1 Like
Hi Nerd
Sorry if this seems a dumb question but how do I update my version v0.058 to v0.060?
Checking updates in system points to version 3.799.
Is it a case of a fresh install?
Thanks in advance
Hey @Steve1,
Not a dumb question at all, in fact - very good question indeed. Starting from 0.060 OTA will be available. Unfortunately 0.060 requires fresh install.
Kind Regards,
1 Like
Hi @nerd ,
just tested beta version Volumio-0.060-2025-04-24-x86_amd64.img
Here comes my test report with log.
startup sound at first boot 
WEB UI is working at HDMI.
An at first boot time attached USB stick with music files is not scanned automatically . I had to start several times an “update” at “Sources”. 
the playback generally does work (tried webradio, TIDAL, TIDALconnect, network drive and local music lib).
index of local files (music library) scan or update does work.
index of network volumes (music library) scan or update does work.
automount of local USB plugged media does work and is scanned automatically.
SPDIF out ok
HDMI out - not tested
analogue out - not tested
Playback of high resolution files is broken, sounds like the audio is hacked into pieces (WAV 352.8 kHz 32 bit, DSD 2.82 MHz 1 bit, DSD 5.64 MHz 1 bit, DSD 11.28 MHz 1 bit)
Webradio ok
myVolumio ok (user level: Superstar)
TIDAL ok
TIDALconnect ok but often got the message “could not connect the server” when skipping to another title
Qobuz - not tested
music lib index ok (artists, albums, tracks, playtime)
ssh / logs ok
SMB mount ok
plugins - not tested
WEB UI ok
background image upload ok
USB automount ok
LAN ok
WLAN - not tested
Network Drives ok
update - not tested
startup sound ok
alarm - not tested
Logfile: http://logs.volumio.org/volumio/WoDo2oi.html
Hardware:
volumio@smx:~$ inxi -Fxxxz
System:
Kernel: 6.6.69-volumio arch: x86_64 bits: 64 compiler: gcc v: 13.2.0 Console: pty pts/0
Distro: Debian GNU/Linux 12 (bookworm)
Machine:
Type: Desktop Mobo: ASRock model: J3455-ITX serial: <superuser required>
UEFI: American Megatrends v: P1.40 date: 07/14/2017
CPU:
Info: quad core model: Intel Celeron J3455 bits: 64 type: MCP smt: <unsupported> arch: Goldmont
rev: 9 cache: L1: 224 KiB L2: 2 MiB
Speed (MHz): avg: 2196 min/max: 800/2300 cores: 1: 2196 2: 2196 3: 2196 4: 2196
bogomips: 11980
Flags: ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3
Graphics:
Device-1: Intel HD Graphics 500 vendor: ASRock driver: i915 v: kernel arch: Gen-9 ports:
active: DP-1 empty: DP-2,HDMI-A-1 bus-ID: 00:02.0 chip-ID: 8086:5a85 class-ID: 0300
Display: server: X.org v: 1.21.1.7 driver: X: loaded: modesetting unloaded: fbdev,vesa
dri: iris gpu: i915 tty: 124x87
Monitor-1: DP-1 model: Dell P3223QE serial: <filter> res: 3840x2160 dpi: 140
size: 697x392mm (27.44x15.43") diag: 800mm (31.5") modes: max: 3840x2160 min: 720x400
API: OpenGL Message: GL data unavailable in console and glxinfo missing.
Audio:
Device-1: Intel Celeron N3350/Pentium N4200/Atom E3900 Series Audio Cluster vendor: ASRock
driver: snd_hda_intel v: kernel bus-ID: 00:0e.0 chip-ID: 8086:5a98 class-ID: 0403
API: ALSA v: k6.6.69-volumio status: kernel-api
Network:
Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: ASRock driver: r8169
v: kernel pcie: speed: 2.5 GT/s lanes: 1 port: e000 bus-ID: 01:00.0 chip-ID: 10ec:8168
class-ID: 0200
IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives:
Local Storage: total: 1.89 TiB used: 787.42 GiB (40.7%)
ID-1: /dev/sda vendor: Samsung model: SSD 860 EVO 1TB size: 931.51 GiB speed: 6.0 Gb/s
type: SSD serial: <filter> rev: 1B6Q scheme: GPT
ID-2: /dev/sdb type: USB vendor: Samsung model: PSSD T7 size: 931.51 GiB type: SSD
serial: <filter> scheme: MBR
ID-3: /dev/sdc type: USB vendor: SanDisk model: Ultra Fit size: 57.28 GiB speed: 6.0 Gb/s
type: N/A serial: <filter> rev: 1.00 scheme: GPT
ID-4: /dev/sdd type: USB vendor: SMI (STMicroelectronics) model: USB size: 15 GiB type: N/A
serial: <filter> rev: 1100 scheme: MBR
Partition:
ID-1: /boot size: 168.4 MiB used: 65.4 MiB (38.8%) fs: vfat dev: /dev/sdc1
Swap:
Alert: No swap data was found.
Sensors:
Src: /sys System Temperatures: cpu: 57.0 C mobo: N/A
Fan Speeds (RPM): N/A
Info:
Processes: 217 Uptime: 45m wakeups: 0 Memory: 3.7 GiB used: 1.38 GiB (37.4%) Init: systemd
v: 252 target: graphical (5) default: graphical Compilers: N/A Packages: pm: dpkg pkgs: 844
Shell: Bash v: 5.2.15 running-in: pty pts/0 (SSH) inxi: 3.3.26
Cheers,
Robert
This a first with a first private or previously owned set of x86 devices, ones we used before to get a first idea of compatibility.
No worry, practice shows way, way, way, way, way more compatibility that we can test ourselves, but this is why we really need you with x86 to cover your configuration as well. There is no guantantee we will ever cover all, we just do our best.
MytTargets:
- HP Laptop - x2 Detachable 10-p0XX
- Asus notebook NJ550J
- HP notebook 15-r77nz
- Chuwi larkbox
- Dell Wyse 3040
- Lenovo Yoga520
- Lenovo T15V
- Asus Z390m based build
Some of them owned, others left pre-owned to me for testing
- Testing a HP Laptop - x2 Detachable 10-p0XX
- boots fine
- wizard fine, as the device does only have bt/wifi it finishes quickly.
- Following wifi configuring ends up in a hung system after disabling hotspot and connecting ssid, Log details will be forwarded to the devs, a forced restart shows everything ok, incl. wifi ip address.
- Audio works as expected, incl. software event-based speaker/headphone switching.
- Touchscreen works fine out-of-the-box, no adjustments needed.
- usb-to-eth adapters appear to work fine for the ones supported by the 6.6.y kernel (tested 3 different/brand devices)
- USB ports working
- SD slot working
- Bluetooth working
- Onboard bluetooth playback from an iphone works, no issues
- Playback via usb, incl. DSD fine
- Playback via airplay ok
- SMB connection for audio source OK
- Factory reset works, resulting in the already mentioned wifi issue.
- Media keys (prev/play/next) working
- Vol + & Vol - keys working
- Brightness control NOT working
- Mute key NOT working
- Ctrl-alt F1 (terminal) and ctrl-alt F2 (GUI) working
Log for wifi issue attached here
1 Like
When the dust settles I will additional test:
Dell E4200
Toshiba Click Mini
1 Like
Hi @Robert.Hecht,
Thanks a lot for your detailed report and for testing the x86 alpha image on real hardware. Much appreciated.
Here’s a breakdown of the issues you raised, along with what we’ve confirmed from the log you provided:
1. High-Resolution Playback (WAV 352.8kHz, DSD)
From the MPD log:
- MPD correctly identifies and accepts high-res formats.
- ALSA device
hw:5,0opens successfully with format S32_LE and rate 352800. - Playback state changes to playing, and there is no fallback or error.
This indicates MPD is doing the right thing, and ALSA accepts the stream.
However, if playback sounds broken, it is likely that:
- The SPDIF interface or the receiving device does not properly handle the given format.
- There may be a runtime format mismatch that ALSA accepts but cannot transmit bit-accurately.
To confirm what ALSA is actually playing, could you please run the following during playback of one of the failing files?
cat /proc/asound/card5/pcm0p/sub0/hw_params
This will confirm if ALSA is actually using the format MPD requested.
2. TIDAL Connect: “Could not connect to server” on title skip
This one is clearly visible in your log:
Fetch playback info returned error: Error: connect ECONNREFUSED 127.0.0.1:3000
This means that the streaming daemon tried to query Volumio’s local API during a skip event, but the connection was refused. This typically points to a race condition between Volumio backend startup state and TIDAL Connect’s request timing.
The symptom matches exactly what you reported in the TIDAL app.
This will be reported upstream to the TIDAL Connect integration team.
3. USB Drive Not Scanned on First Boot
From your log:
- The USB device was detected and mounted correctly.
- It was indexed shortly after NAS mount cleanup was triggered.
MPD log shows:
update: removing currently indexed NAS and USB entries
update: added USB: /media/SMI_USB
...
update: updating DB (USB)
This confirms that the USB scan did happen automatically. It may have just followed NAS initialization, causing a delay in visible content. No manual update was strictly necessary, although the UI may not have shown feedback immediately.
This seems to be a misunderstanding due to the timing of operations, not a fault in the backend.
Let us know if you are able to run the hw_params check during a failing high-res playback session, and thanks again for the detailed testing and feedback.
Kind Regards,
1 Like
Thanks for the detailed hardware report, @gkkpch.
The Wi-Fi hang when transitioning from hotspot to SSID has been tracked here, as it matches similar behavior observed in past Buster builds as well:
Issue:
It’s likely related to a race condition or timing gap in the service transition between hostapd, wpa_supplicant, and connman. We’ll continue tracking it under that thread.
Let us know if you spot any variation across devices - especially if some handle the transition cleanly.
Kind Regards,
Hi @nerd ,
thanks a lot for your instant reply!
When I tried reproducing this morning this issue I couldn’t. The hires files WAV and DSD were played correctly via spdif now. Nevertheless I have a presumption what the issue’s reason is. Yesterday I tested during the process that builds up the musiv lib from local USB files and NAS files. During this scan the playback of hires files is broken. This morning this process had finished during the night an the playback works fine now.
In tests of former releases I had the same issue when playing via HDMI out. I moved over to SPDIF therefore and this works fine. I’ll test HDMI this evening and will come back to you.
The file
/proc/asound/card5/pcm0p/sub0/hw_params
does not exist on my system…?
Best regards,
Robert
Hey @Robert.Hecht ,
Thanks for the follow-up, this is very helpful.
You’re absolutely right: if you’re switching outputs (HDMI, SPDIF, USB), the ALSA card numbers can change between reboots or when devices are added or removed.
That is likely why you did not find the file at /proc/asound/card5/pcm0p/sub0/hw_params - the SPDIF device may now be assigned to a different card or subdevice.
Here are the steps to find the correct hw_params path:
-
Run this command to list all active ALSA playback devices:
for d in /proc/asound/card*/pcm*p/sub*/hw_params; do echo $d; cat $d; echo ""; done -
Look through the output and find the one currently in use. You should see something like:
access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 352800 -
That tells you which card and subdevice is active. For example:
/proc/asound/card2/pcm0p/sub0/hw_params
Once you identify the correct path, it will confirm whether ALSA is receiving the expected high-resolution stream.
Thanks again for confirming SPDIF and planning to test HDMI. Real hardware feedback like yours helps us catch things we cannot see in test environments. Looking forward to the HDMI results.
Kind Regards,
v0.60, RPI3, Allo Kali + Allo Piano 2.1 is working in dual mono and dual stereo mode
Plugins: Spotify
1 Like
Hi @nerd ,
playback via HDMI output shows this broken / hacked in pieces sound at hires files in the first 5 to 10 seconds of the file. After the first 10 seconds the playback works fine for the rest of the file. This issue is really an old one. I saw this over the last years at every release and trying 3 X86/AMD64 hardware variants. This was the reason for me to switch over to SPDIF - where playback of hires files works fine.
http://logs.volumio.org/volumio/TsNr7Lt.html
volumio@smx:~$ cat /proc/asound/card0/pcm3p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 8192
buffer_size: 65536
volumio@smx:~$ cat /proc/asound/card0/pcm3p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 8192
buffer_size: 65536
volumio@smx:~$ cat /proc/asound/card0/pcm3p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 8192
buffer_size: 65536
volumio@smx:~$ cat /proc/asound/card0/pcm3p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 8192
buffer_size: 65536
volumio@smx:~$ cat /proc/asound/card0/pcm3p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 8192
buffer_size: 65536
volumio@smx:~$ cat /proc/asound/card0/pcm3p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 8192
buffer_size: 65536
volumio@smx:~$
Via HDMI MP3 and FLAC files up to 48kHz/24bit were played correctly. Everything above and every DSD file shows this hacked sound at the first 5-10 seconds of the file.
Best regards,
Robert
Brand: Toshiba
Model: Satelite Click Mini L9W-B 22
Chipset: Atom™ Z3735F
Running from: eMMC
Confirmed image version: V0.060 (6.6.69 Kernel, alpha test)
What is working:
Hardware:
Bluetooth
Internal Audio
Physical Volume buttons
Volume buttons Keyboard
Physical Power Button
WiFi
Docking keyboard
LCD + Touchscreen
Both SD card slots (tablet and Docking)
Media keys (Prev/Play/Pause/Next Keyboard)
GUI shutdown
Touchscreen
Music:
DSD64, DSD128, DSD256
MP3
Flac
Webradio
Tidal
Tidal Connect
Qobuz
Qobuz + BT
Local files phone + BT
Spotify
What is not working:
Brightness control (Keyboard)
Turning screen on/off (Keyboard)
Mute (Keyboard)
GUI Restart, Tablet gets stuck needs forced shutdown
Rotation
Hey @Robert.Hecht,
Thank you for this thorough follow-up and for testing HDMI playback again.
Based on your observations and the system logs, we can confirm that Volumio is correctly opening the HDMI device at high sample rates. The ALSA configuration shows proper format negotiation (S32_LE, 192kHz), and no errors appear in the backend.
What you are encountering during the first few seconds of high-resolution playback over HDMI appears to be a limitation in how HDMI audio is handled at the hardware and driver level. This behavior is known to occur on many Intel and AMD HDMI interfaces. When a new audio stream starts, especially one with a high sample rate, the HDMI audio path must re-lock its internal clock domains to the stream. During this re-sync process, the output may become distorted or temporarily unstable until the buffers stabilize and the link settles.
This is different from SPDIF or USB audio, where the signal path is simpler and does not require the same level of handshake or clock realignment. That is why you consistently see correct playback over SPDIF, even with the same files and system.
Volumio, by design, prioritizes direct and bit-perfect playback. It does not inject silent pre-rolls or impose fixed-rate resampling, which means it does not mask these hardware behaviors. Some software players do this silently behind the scenes, which can reduce the issue but at the cost of purity or added latency.
To sum up: this is not caused by Volumio itself but by how HDMI audio interfaces handle stream transitions at high resolutions. It is a known behavior on Linux and has been observed across multiple systems. A workaround would involve either pre-buffering silence or enforcing a fixed output rate, but that would compromise the bit-perfect playback goal.
If bit-perfect playback without glitches is essential, SPDIF or USB DACs remain the most reliable choice for high-resolution formats on x86 platforms.
Note for internal testing (not part of; not introduced by Bookworm Alpha):
The HDMI high-resolution playback glitch observed in the first few seconds appears consistent with known hardware behavior related to HDMI clock locking and buffer priming. To further support or rule out this theory, we may consider the following controlled tests in a separate environment:
-
Force fixed output rate in mpd.conf
Usingaudio_format "96000:24:2"would prevent HDMI re-negotiation between tracks. If playback becomes smooth from the start, it suggests clock domain switching as the culprit. -
Pre-buffering test
Introduce a manual playback delay (e.g. silent pre-roll or scripted pause) to allow HDMI hardware time to lock before sending actual audio. This could confirm if the glitch is timing-related. -
Cross-check with other Linux players
Use tools likeaplay,mpv, orcplaywith ALSA HDMI output under similar conditions. Consistent behavior would reinforce that the limitation is in the hardware or driver layer, not Volumio.
These are not part of the Bookworm Alpha’s user-facing scope, but they may inform long-term HDMI handling improvements or documented behavior notes.
Kind Regards,
1 Like
Hey @Wheaten,
Thanks for the comprehensive hardware report. Much appreciated - especially on such a compact Atom-based convertible where kernel quirks tend to pile up.
About What’s Not Working
1. Brightness control (keyboard)
Likely an ACPI event not mapped or not exposed properly through udev. On Bay Trail devices, brightness keys often rely on vendor ACPI handlers or kernel DMI-based quirk tables.
Suggestion:
- Check if
/sys/class/backlight/intel_backlight/brightnessexists - If yes, brightness keys may still emit scancodes but require a userland listener (e.g.,
udev,acpid, or custom keymap viasetkeycodes) - This could also be addressed via kernel DMI-based ACPI table patch or by injecting userspace mapping in a recipe overlay
2. Screen on/off toggle (keyboard)
Likely linked to the same ACPI event handling gap. These Fn keys often send ACPI video events or vendor-specific inputs.
Suggestion:
- Confirm if
acpi_listenshows key events when the button is pressed - If not, a kernel-level
platform_driverquirk might be needed, or patchingacpi-videoto handle this model viadmi_match
3. Mute key
If no mixer change occurs, this is likely either:
- The keycode is not being translated into an ALSA action
- Or the default audio card (probably
card0) does not expose a validMasterorPCMcontrol to act upon
Suggestion:
- Use
evtestorshowkeyto verify the key is reaching the input subsystem - Consider adding a
udevrule to bind the mute key to an ALSA mixer control - If needed, device-specific fixups via
/lib/udev/hwdb.d/or kernelinput_idhandlers could be applied
4. GUI Restart causing freeze
This is the most serious of the group and probably rooted in one of:
- A broken ACPI
reboot()implementation on this SoC - A graphical target shutdown that misroutes to suspend or halts systemd
- Or early unmount of eMMC triggering a stall
Suggestion:
- Try
sudo systemctl rebootmanually to confirm if issue is with GUI hook or with underlying shutdown/reboot process dmesgafter boot may reveal if the previous session hit a soft lock or if the shutdown was incomplete- If reproducible, consider forcing reboot via
/proc/sys/kernel/sysrqmechanism (echo b > /proc/sysrq-trigger) to isolate whether the issue is GUI-layer only
Path Forward
This is a great candidate for either:
- A device-level patch (via kernel quirk or version bump)
- Or a recipe-level patch in platform detection to inject specific input, backlight, or reboot handling
We can look into tailoring DMI match entries if the ACPI tables confirm unique IDs. Let x86 devs know if you have dumps from dmidecode and acpidump, that would help define scope for a patch candidate.
Thanks again for helping us push these edge devices into supported territory.
Kind Regards,
v0.060 installed on RPi4 with HiFiBerry DAC2 HD.
Connected to SMB using ethernet playing FLACs and all good so far.
Thanks for the great work 
Thanks again @nerd for your quick, detailed and well-researched answer. I realise that this problem should be tackled elsewhere - if there is a sensible solution at all. For me personally, bit-exact audio is also Volumio’s greatest asset alongside its ease of use and integration into the surrounding systems. The solution of working via SPDIF is completely fine for me.
So let’s focus on the stability and hardware compatibility which are the main goals for this alpha phase. 
Working with you is always a pleasure to me!
Cheers, Robert
Update: analogue out works fine, even with hires files.
When playback via analogue out is running, SPDIF keeps playing as well.
1 Like
Hi @nerd, as requested.
1 - After /sys/class/backlight/ it stops.
2 - acpi_listen doesn’t intercept the key combo FN + Display Toggle
3 - button/mute MUTE 00000080 00000000 K
Testing ... (interrupt to exit)
Event: time 1745591894.298232, type 4 (EV_MSC), code 4 (MSC_SCAN), value c00e2
Event: time 1745591894.298232, type 1 (EV_KEY), code 113 (KEY_MUTE), value 1
Event: time 1745591894.298232, -------------- SYN_REPORT ------------
Event: time 1745591894.502203, type 4 (EV_MSC), code 4 (MSC_SCAN), value c00e2
Event: time 1745591894.502203, type 1 (EV_KEY), code 113 (KEY_MUTE), value 0
Event: time 1745591894.502203, -------------- SYN_REPORT ------------
4 - sudo systemctl reboot Device shuts down, but won’t reboot. Need to force a reset (hold power button for 15 seconds to boot)
dmesg.txt (109.2 KB)
sudo su
echo b > /proc/sysrq-trigger
System freezes completely
5 - Forgot to mention, screen rotation does’t work (just mentioning it )
volumio@click:~$ sudo xrandr --query
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 16384 x 16384
DSI-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis)