Public Alpha Test: Audio Without Compromise - Volumio on Bookworm Begins

Robert.Hecht · May 19, 2025, 8:53pm

Hello @nerd ,

did what you suggested. Here you find the log

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

and the captured information:

**EDIT: **
Unique Download Link | WeTransfer

I really hope it helps you finding the root cause for the connection breakdowns and Tidal Application crashes.

Cheers,
Robert

JohnR · May 19, 2025, 8:56pm

I have tried several times but I can’t get SSH to work with 0.66 or 0.67. I even tried starting 0.66 with the wifi USB removed. Volumio played music but SSH didn’t work. My neighbour might have a wired keyboard. I’ll ask tomorrow.

Regards

gkkpch · May 19, 2025, 9:57pm

That is a very interesting one indeed, I will test it on fhe Larkbox as bt connection was ok, but it had so sound. The only device I tested havin this issue (and I tested quite a load of them over the years)

SimonE · May 19, 2025, 10:37pm

OTA update from 0.066 to 0.067
Pi4B, Original 7" Raspberry Pi display, Topping D10s USB DAC
Update completed successfully. Log straight after.

On restart, display was blank (this is normal for me, I always need to power down and then restart to get the screen to work). Failed to find network drive (SSD on another Volumio system).

After power down and restart, screen and network drive OK again.
Tested, all OK: Playing files from NAS, Spotify, Bandcamp, Web Radio, Touch Display, Now Playing, IR_Remote, Play Here, Multiroom, Bluetooth.
Date/time correct. Shows correct version number.
Logs

Dick_van_der_Wal · May 20, 2025, 5:27am

thanks!!! had the same issue. now solved.

have a nice day!

nerd · May 20, 2025, 6:11am

Hey @Robert.Hecht,

Thanks again for testing this and sending the files.

It looks like the uploaded collect-volumio-runtime.zip is actually the original script, not the captured system stats.

Could you please check if /tmp/volumio_debug_capture/ exists on the device and contains multiple .txt files? If so, kindly archive the folder and upload the results as follows:

cd /tmp
tar -czvf volumio_debug_capture.tar.gz volumio_debug_capture

Then you can send back the .tar.gz file (either upload directly to the forum or use transfer.sh or a similar tool and share the link).

This data will help us deeply analyze the system state during the observed Tidal Connect issues.

Kind Regards,

nerd · May 20, 2025, 6:18am

Hey @SimonE,

Thanks again for your thorough validation of the 0.067 OTA - everything in the uploaded logs looks clean, and it’s great to hear that your system is stable across Bluetooth, multiroom, plugins, and the display after a proper power cycle.

One thing that would help us further:

Could you please capture and upload a log immediately after the first reboot (the one where the display stays blank and the network drive fails to connect)? That specific moment is useful for us to diagnose early runtime issues - particularly the HDMI/DSI stack behavior and network volume timing.

We’ll compare that against your post-reboot logs where everything works, and see if we can pin down a consistent pattern.

Kind Regards,

nerd · May 20, 2025, 6:23am

Hey @Dick_van_der_Wal,

Glad to hear it’s solved - though just to keep our records clear: could you remind us what specific issue you were referring to? That’ll help us connect your outcome with any related fixes or threads.

Kind Regards,

nerd · May 20, 2025, 6:27am

Hey @gkkpch,

Thanks for highlighting that - yes, this could be a valuable opportunity to isolate the silent Bluetooth playback issue on platforms like the LarkBox, especially now with the CNVi and LPSS features explicitly enabled in 0.067+.

It would be great if you can:

Re-test the LarkBox using the current 0.067 image.
Try pairing and connecting a known-working A2DP Bluetooth audio device.
Check whether bluealsa-aplay is triggered and if audio routing occurs.
If still silent, confirm:
- Whether the output device is listed under aplay -l
- If the volumio virtual output is properly routed to the expected hardware PCM
- And whether there’s any D-Bus or ALSA log activity during playback

Would really appreciate if we can get to the bottom of this one - it’s the kind of edge case that only dedicated hardware access can debug.

Kind Regards

Gelo5 · May 20, 2025, 7:14am

Next test (tested files: DSD - 1/2.82 and Flac-16/44.1)
*1
DSD files, Mixer type: NONE
http://logs.volumio.org/volumio/ZrcX888.html
44.1/16 files, Mixer type: NONE
http://logs.volumio.org/volumio/42sS0QS.html
This is what it displays on my DAC (MX-DAC, JF Digital)
None

Everything is correct: Mixer - none

*2
DSD files, Mixer type: Software
http://logs.volumio.org/volumio/v9GzdbH.html
44.1/16 files, Mixer type: Software
http://logs.volumio.org/volumio/DrhgKjj.html
This is what it displays on my DAC (MX-DAC, JF Digital)
Soft
Volumio displays incorrect data, Mixer Software: 24/352- it should be 1/2.82 and 24/44.1 - it should be 16/44.1

*3
DSD files, Mixer type: Hardware
http://logs.volumio.org/volumio/Rp8byQz.html
None2
Displays correctly but outputs only noise

44.1/16 files, Mixer type: Hardware
http://logs.volumio.org/volumio/j6oBqwp.html
Hard44
Volumio displays incorrect data, Mixer Harware: 32/44.1 - it should be 16/44.1

Best regards

Robert.Hecht · May 20, 2025, 8:21am

Hi @nerd ,

excuse me, I uploaded the wrong file. As it is a .gz the forum does not accept it so I put it in wetransfer.com and included the link in the original post above.

Cheers,
Robert

SimonE · May 20, 2025, 9:06am

Hi @nerd,
The first log - here it is again I posted was just after the system restarted itself after updating, when the display failed to restart and the network drive wouldn’t play music.

Here is the log when everything is working.

And here is one after a new restart, with screen not working again. This time I can play NAS files - so maybe that was an anomaly after the update.

gkkpch · May 20, 2025, 9:07am

@nerd @Rui_C
I believe my fix in the souncard-init service is not included or otherwise erroneous.
The log shows the service has been started and deactivated, but there is no sign of processing for the ALC879 device, which should have been logged. Further analysis is necessary.
@Rui_C please execute the amixer command as @nerd suggested, it may show whether I missed something.

gkkpch · May 20, 2025, 9:28am

Also @Rui_C, could you do a factory reset and then instead of doing the alsamixer fix, do

amixer sset 'IEC958' unmute

JohnR · May 20, 2025, 10:03am

At last I figured that the ~ key gave me | , here’s the log file for 0.67
http://logs.volumio.org/volumio/knFRVQ4.html
still can’t get SSH to work

Best Regards

Robert.Hecht · May 20, 2025, 10:10am

Hi @nerd ,

after flashing a 0.067 freshly I see that the size of the /imgpart is now 4.2G (3.7G previously). So I’m looking forward to performing an OTA from the 0.067 to the next beta version.

Cheers,
Robert

nerd · May 20, 2025, 11:46am

Hey @Gelo5,

Thanks for sharing these thorough test results. We’ve now analyzed all six logs you linked, extracted the actual playback parameters, and correlated them with the expected outcomes. Here’s a complete, fact-based breakdown.

Test Environment Summary

Device: HU300 HiFi 2.0 (USB, XMOS-based DAC)
Platform: Raspberry Pi (Volumio 0.067 on Bookworm, Kernel 6.12.27)
Audio Path: card 2: H20, hw:2,0 via USB
Test Files:
- DSD64 (1-bit / 2.8224 MHz)
- FLAC 16-bit / 44.1 kHz

Results Table: Playback Verification vs Log Facts

Test	Mixer	Format	User Report	Volumio UI	DAC Display	Actual ALSA Output	Log	Discrepancy
1a	NONE	DSD64	Correct	DSD	DSD64	`DSD_U32_LE @ 2822400Hz`	`ZrcX888.html`	None
1b	NONE	16/44.1	Correct	44.1/16	44.1/16	`S16_LE @ 44100Hz`	`42sS0QS.html`	None
2a	Software	DSD64→PCM	Volumio shows 24/352	24/352.8	“Soft”	`S24_3LE @ 352800Hz`	`v9GzdbH.html`	DSD converted to PCM
2b	Software	16/44.1	Volumio shows 24/44	24/44.1	“Soft”	`S24_3LE @ 44100Hz`	`DrhgKjj.html`	Bit depth upconverted
3a	Hardware	DSD64	Noise output	DSD/DoP	“None2”	`DSD_U32_LE @ 2822400Hz`	`Rp8byQz.html`	DSD via mixer is corrupted
3b	Hardware	16/44.1	Volumio shows 32/44	32/44.1	“Hard44”	`S32_LE @ 44100Hz`	`j6oBqwp.html`	Bit depth mismatch

Technical Notes (per test)

1a / 1b - Bit-perfect path confirmed. ALSA sends raw DSD and 16-bit PCM without resampling.
2a - DSD must be decoded to PCM (352.8kHz) due to incompatibility with softvol. This resampling is expected.
2b - Even though the FLAC is 16-bit, softvol enforces a 24-bit PCM stream. Common ALSA behavior.
3a - DSD is sent over DoP as DSD_U32_LE, but volume cannot be applied; this results in noise due to invalid stream after mixer interference.
3b - FLAC output is reported as 32-bit, while the DAC displays 16-bit; likely the DAC truncates or internally handles the stream.

Additional Note - Bookworm vs Buster

These tests were performed on the Bookworm-based Volumio build. Since we’re working on a like-for-like Buster-to-Bookworm evaluation, it’s worth confirming whether this behavior was identical under Buster.

If you or another tester have access to a Buster-based Volumio image, please consider replicating these tests and sharing logs.
This will help determine whether the discrepancies (especially with mixer types) are legacy issues or Bookworm regressions.

Facts

Your reporting is fully accurate.
The discrepancies stem from ALSA mixer pipeline behavior, not from file format misinterpretation.
For bit-perfect playback (especially DSD), always use Mixer: NONE.
Software and hardware mixers will alter stream format, particularly for DSD and FLAC 16-bit.
If Bookworm introduces any additional deviation, we’ll detect that clearly by comparing against matched logs from Buster.

Kind Regards,

nerd · May 20, 2025, 11:50am

Hey @Robert.Hecht,

Thanks for the clarification and for providing the correct file via WeTransfer.

I’ve reviewed the situation and have forwarded the findings to the development team for further analysis. There may be additional tests or questions as we investigate further - I’ll share those with you as soon as they come up.

Appreciate your detailed reporting and support in tracking this down.

Kind Regards,

Robert.Hecht · May 20, 2025, 12:02pm

Hi @nerd ,

you’re always welcome. I’m proud and lucky to help you making Volumio better. And I very much appreciate your excellent work and communication!

Cheers,
Robert

nerd · May 20, 2025, 12:03pm

Hey @SimonE,

Thanks for your detailed follow-up and for sharing all three logs. I’ve reviewed them carefully to understand the screen blank issue and its relation to the network drive behavior following the OTA update to version 0.067.

Observations from the Logs

System Environment Confirmed:
All three logs show the system is running on Debian Bookworm with kernel 6.12.27-v7l+. There are no version mismatches or partial updates.
Touch Display Plugin Status:
The touch_display plugin is installed and marked as started. There’s no indication of failure from the plugin manager itself.
Chromium is Running:
Chromium starts in kiosk mode, launched by volumiokiosk.sh, and is visible in the process list in the failing state. However, its presence alone does not confirm successful rendering.
Network Connectivity Resolved Automatically:
The initial post-update boot may have experienced a temporary network stack delay. In subsequent boots, NAS playback and SMB mount behave correctly.

Working Hypotheses

Display Rotation Conflict:
The file /boot/userconfig.txt contains both display_lcd_rotate=2 and display_hdmi_rotate=2. On Raspberry Pi with the newer KMS stack used in Bookworm, this can cause conflicts or delays in display initialization. These directives might be racing against each other at early boot.
X/Chromium Starting Before Display is Ready:
It is possible that the graphical stack (Xorg and Chromium) is being started before the DSI display is fully initialized. This would result in Chromium rendering to a non-existent or unavailable framebuffer.

Recommendations

Modify Display Rotation Settings:
Edit /boot/userconfig.txt and comment out the HDMI rotation line:
```
# display_hdmi_rotate=2
display_lcd_rotate=2
```
This ensures only one rotation directive applies, specific to the active display type.
Delay Chromium Startup:
If possible, delay Chromium in /opt/volumiokiosk.sh until /dev/fb0 or /dev/fb1 becomes available using a short loop or sleep. This prevents the UI from rendering before the framebuffer is active.
Verify Display Target:
From SSH, run xrandr --listmonitors and xrandr --verbose immediately after boot to confirm which output Chromium is using.
Collect Xorg Log:
Retrieve /var/log/Xorg.0.log (or ~volumio/.local/share/xorg/Xorg.0.log if applicable) from a failed state to see if the display driver failed or if rendering went to the wrong device.

Advanced:

Sample Snippet (Insert at the top of /opt/volumiokiosk.sh):

#!/bin/bash

# Alpha-only: Wait until framebuffer device is available
FB_DEV="/dev/fb0"
MAX_WAIT=10
WAITED=0

while [ ! -e "$FB_DEV" ]; do
  echo "Waiting for framebuffer $FB_DEV..."
  sleep 1
  WAITED=$((WAITED+1))
  if [ "$WAITED" -ge "$MAX_WAIT" ]; then
    echo "Framebuffer $FB_DEV not available after $MAX_WAIT seconds. Continuing anyway."
    break
  fi
done

# Continue with normal kiosk startup

Kind Regards,