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

[ClaesM]

Hi @nerd

Rapberry Pi 5
running Volumio 0.065 on Nvme
Rasperry Touch Display 2

Booting up works fine
Wifi hotspot and setup Volumio works without problem

Sources
Mount network attached NAS works
Mount USB storage attached to a Rpi4 on same network works
Usb storage connected to Rpi 5 works
Bluetooth works

Audio
I tested 3 different usb connected dacs so far and they all work.
I have not tested any I2S dacs yet but I will do it soon.

Plugins
Fusion dsp works
Now Playing works
Touch Diplay works (except for virtual keyboard)
System Informaton works
Radio Paradise works
I don´t use any streaming services at the moment so I can´t say anything about them.

Btw, I have no problem with Time sync

Thank you for your fantastic work! This is a big step forward for Volumio!

Best Regards / C

[Robert.Hecht]

Hi @nerd ,

excellent work. Test report on an AMD64

log: http://logs.volumio.org/volumio/sIMRO26.html

OTA from 0.063 to 0.065
WEB UI is working at HDMI.
Zoom factor seems to have no effect on the elements on the HDMI interface
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 works fine via SPDIF (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
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
NFS time sync

Fabulous! I’ll be testing the 0.065 some hours further and add some of the “not tested” ones above. So far it feels very good.

Cheers,
Robert

[Robert.Hecht]

just after sending this test report playback of web radio stopped…
http://logs.volumio.org/volumio/O7X6olF.html

after 1 or 2 minutes suddenly web radio starts playback again…
http://logs.volumio.org/volumio/BWa5t5M.html

all this happened during rescanning the music lib adding files from the NAS location…

There’s still a little instability during the rescan, I fear.

[Gelo5]

@Robert.Hecht

Playback of high resolution files works fine via SPDIF (WAV 352.8 kHz 32 bit, DSD 2.82 MHz 1 bit, DSD 5.64 MHz 1 bit, DSD 11.28 MHz 1 bit)

SPDIF (Sony/Philips Digital Interface Format) can output audio at a maximum resolution of 24 bits and 192 kHz

[Robert.Hecht]

Hi @Gelo5 ,

that’s right, there’s a resampling then to 192kHz@24bit.

Cheers,
Robert

[nerd]

Hey @JohnR,

Thanks for the update and the log.

You’ve helped confirm a recurring issue with some USB WiFi adapters - in your case, the RT5370 dongle - where the interface is soft-blocked by rfkill, preventing the hotspot from coming up automatically. Even though our early unblock service runs, it seems it’s not effective or runs too early for this chipset.

I am taking note of this and will revise the startup logic to better handle these cases. This may involve reordering or deferring rfkill unblocking after kernel modules are fully loaded.

Really appreciate your persistence and clean logs - they help us pinpoint things we can’t always catch internally.

Kind Regards,

[nerd]

Hey @ClaesM,

Thanks a lot for the detailed feedback - really valuable!

Great to hear that boot, storage sources, Bluetooth, and multiple USB DACs all worked flawlessly on the Pi 5 with NVMe. It’s especially encouraging that the WiFi hotspot and network discovery performed smoothly, as those are common pitfalls during alpha phases.

Your plugin report helps confirm that our backend changes are holding up well under varied setups. We’re still working on polishing the on-screen keyboard, so your mention is noted and appreciated.

Also, good to know time sync behaves correctly in your environment - we’ve seen the opposite in some edge cases, so every confirmation helps.

Looking forward to your I2S DAC tests when you get the chance.

Kind Regards,

[nerd]

Hey @Robert.Hecht,

Great follow-up and sharp eye on that playback glitch. From the logs, it appears that the web radio stream entered a silent state during the music library rescan - without fully breaking the stream or triggering a player error. This is actually in line with Volumio’s intended self-recovery logic: if buffering stalls or load delays output, the system tries to ride it out and resume cleanly without a full restart of the playback chain.

This behavior avoids aggressive resets that could make things worse, especially for online streams. In your case, it looks like the recovery worked, as playback resumed a couple of minutes later without manual intervention.

That said, we agree this still represents unwanted disruption. If possible, try reproducing the scenario without stressing the system - skip the scan while streaming - and check if audio stays clean. This helps us isolate whether the issue is rooted in resource contention, network I/O, or something deeper.

Thanks again for the outstanding testing and clear reporting.

Kind Regards,

[nerd]

Hey @Josh2000,

That’s excellent news. Getting the Allo Kali with Piano 2.1 to behave correctly - especially in dual mono mode - under kernel 6.x took weeks of low-level debugging and upstream kernel re-work for the hardware abandon by the manufacturer, so your confirmation it still works on v0.065 with the Pi3 is both a relief and a win.

We’ll continue to watch this closely, but your result confirms that our kernel patches and overlay adjustments are holding up as intended in Bookworm.

Thanks for reporting back and for sticking with us through the evolution.

Kind Regards,

[Robert.Hecht]

Hi @nerd ,

@nerd

Great follow-up and sharp eye on that playback glitch. From the logs, it appears that the web radio stream entered a silent state during the music library rescan - without fully breaking the stream or triggering a player error. This is actually in line with Volumio’s intended self-recovery logic: if buffering stalls or load delays output, the system tries to ride it out and resume cleanly without a full restart of the playback chain.

This behavior avoids aggressive resets that could make things worse, especially for online streams. In your case, it looks like the recovery worked, as playback resumed a couple of minutes later without manual intervention.

I see - this behavior is much more robust than the one before that causes many restarts of the player and sometimes ended up in a stage where playback wasn’t possible anymore.

When the library rescan is done everything works fine and clean without any interruption.

How can I skip the running rescan process?

Cheers,
Robert

[jocoman]

Sorry. Got it running today. My bad. finger problems.
Having said that i was hoping to use my EDUP ax3000 wifi dongle, but no joy.
I brought it up on a wired lan and this is what lsusb says:
volumio@gatewayv2:~$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
|__ Port 1: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 2: Dev 4, If 0, Class=Vendor Specific Class, Driver=mt7921u, 480M
|__ Port 4: Dev 5, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 4: Dev 5, If 2, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 5, If 0, Class=Audio, Driver=snd-usb-audio, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
|__ Port 1: Dev 3, If 0, Class=Video, Driver=, 480M
|__ Port 1: Dev 3, If 1, Class=Video, Driver=, 480M
|__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=ums-realtek, 480M

[Wheaten]

Tested with V0.065

Hardware:

• Manufacturer: TOSHIBA
• Model: 0700 / Type2 - Board Version /
• Atom™ Z3735F
• SanDisk Corp. Ultra Fit 15GB
• 10.1inch Capacitive Touch Display, DS1-1, 1920x1200 (WUXGA)
• iFi Zen DAC V2
• Internal Sound card

[Wheaten]

Tested with V0.065

Hardware:

• Brand: Dell Latitude 3189 (x86)
• Native resolution: 1366x768 (WXGA Wide)
• Connected: eDP-1
• SanDisk Corp. Ultra Fit 15GB
• Rotation: 0Deg
• iFi Zen DAC V2
• Internal Sound card
  
  

[nerd]

@Wheaten

• Manufacturer: TOSHIBA
• Model: 0700 / Type2 - Board Version /
• 10.1inch Capacitive Touch Display, DS1-1, 1920x1200 (WUXGA)

Display shift - this is very interesting indeed. Can you share logs and dmesg form this system please?

Kind Regards,

[SimonE]

Bluetooth test issues.
Played a YT video from my phone (Android v15) via BT on my Volumio system. This worked properly and connection was very stable. When I locked the phone it stopped playing and showed “Not Provided” on the Volumio display - as expected. However when I then played flac files stored locally on INTERNAL, these played properly, but when I locked my phone, the play stopped and the “Not Provided” message was displayed. Same goes for web radio when BT is connected.

So in summary, if Volumio is connected to my phone via BT, local playback stops when locking my phone, regardless of the source.

logs

[Wheaten]

Yes I can:
http://logs.volumio.org/volumio/6XV9cFa.html

dmesg.txt (55.2 KB)

[nerd]

Hey @SimonE,

Thanks for the update. In the current state, when your phone is connected via Bluetooth, bi-directional capabilities are negotiated between the phone and Volumio. This means that if your phone allows control from Volumio, it can send and receive playback commands (play, pause, etc.).

However, when the phone is locked, and if it is configured to block media playback on lock (a typical setting for Android devices), it will stop sending control commands to Volumio. As a result, playback pauses or halts because Volumio can no longer control the playback through the phone’s Bluetooth connection.

Next Steps:

1. Disconnect Bluetooth: Please disconnect Bluetooth from your phone and test playback with the same sources (local files, web radio) while locking the phone.

2. Observe the behavior: Check if playback continues without interruption when the phone is locked. If playback continues without issues, it would confirm that the phone lock and its control settings are causing the problem when Bluetooth is connected.

HINT: Bluetooth “Party Mode” is on the roadmap…

Kind Regards,

[nerd]

Hey @Wheaten,

And there is the silence - I think I will need to locate the exact panel details. No error in panel init = Front Porch in kernel module source is shifted - interesting!

Kind Regards,

[Wheaten]

guess just mention “It’s about this big” and “about this thick” will not do the job?

[SimonE]

Hi @nerd
Yes, playback continues as normal on all sources once Bluetooth to Volumio is disconnected.
Thanks,
Simon