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

I figured it had to have been me (but a good chunk of the 20 downloads was actually me), but of course it is the simplest solution. I just unzipped the archive. Haven’t written it to disk yet, but I am sure it is fine. Thank you for the quick reply. I do have another issue when trying to build the image:

I attempted to build the Volumio image in WSL2 Debian Bookworm using the following command:

sudo ./build.sh -b arm -d pi -v 4.010

However, I ran into the following error:

[ .... ] Stage [2]: Creating Image
[ .. ] Image file: .//Volumio-4.010-2025-06-03-pi.img
[ .. ] Using DEBUG_IMAGE: no
4683+0 records in
4683+0 records out
4910481408 bytes (4.9 GB, 4.6 GiB) copied, 3.97863 s, 1.2 GB/s
Error: Partition(s) 1, 2, 3, 4, ... 64 on /dev/loop2 have been written, but we have been unable to inform the kernel of the change, probably because they are in use. 
As a result, the old partitions will remain in use. You should reboot now before making further changes.

[ error ] Imagebuilder script failed!!
[ error ] Error stack [source] <= [main] <=  [ 65 /home/sean/build/scripts/makeimage.sh ]
[ .. ] Unmounting chroot temporary devices at
umount: /sys: umount failed: No such file or directory.
[ warn ] umount sys failed
[ .. ] Cleaning loop device /dev/loop2
/proc/devices: fopen failed: No such file or directory
Failed to set up list of device-mapper major numbers
Incompatible libdevmapper 1.02.185 (2022-05-18) and kernel driver (unknown version).
Command failed.

Steps Taken:

  • Tried running the build multiple times.
  • Ensured there were no other processes locking /dev/loop2.
  • Verified my WSL2 setup and checked for missing dependencies.

Questions:

  • Has anyone successfully built the Volumio image in WSL2 Debian Bookworm?
  • Could the partition error be related to WSL2’s virtualized kernel limitations?
  • Are there recommended workarounds for handling loop device errors in WSL2?

Would love any insights from the community! Thanks for your help. :rocket:

Hardware (x86):

  • Manufacturer: Dell Inc. Dell-3198 (0VG3TM)
  • Wifi
  • Processor Pentium® N4200
  • CD-rom => OK
  • Topping E30II => OK
  • Topping DX3Pro+ => OK
  • Topping E50 => OK
  • NAD D3045 => OK
  • Touch display => OK
  • FN Keys:
    • Brigthness up/down works
    • Volume up/down/mute works
  • HW Volume keys works
  • Powerbutton works
volumio@dell-3189:~$ lsusb
Bus 002 Device 002: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 056a:4854 Wacom Co., Ltd Pen and multitouch sensor
Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
Bus 001 Device 002: ID 0bda:5689 Realtek Semiconductor Corp. Integrated Webcam
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Installation:

  • V4.010 => Clean install installation get stuck at “Done”. After forced restart it boots and get stucked in grey screen. Needed to press F5 to continue
  • Wifi adapter not scanning network on initial install. (Known issues). Work arround Disable HS and you can connect to network
  • Restart works
  • NAS Mount via CIFS, Options blank => OK
  • NAS Mount via NFS, Options blank => OK

Sound:

  • DSD 64, 128, 256, 512, 1024 => OK
  • MP3 => OK
  • MP4 => OK
  • Flac 44.1kHz (16, 24, 32 Bit) => OK
  • Flac 48kHz (16, 24, 32 Bit) => OK
  • Flac 96kHz (16, 24, 32 Bit) => OK
  • Flac 192kHz (16, 24, 32 Bit) => OK
  • Flac 384kHz (16, 24, 32 Bit) => OK
  • WAV 44kHz-16bit, 48kHz-16bit, 88kHz-24bit, 96kHz-32bit, 176kHz-32bit, 192kHz-32bit => OK
  • Tidal => OK
  • Qobuz => OK

Plugins:

  • FusionDSP => OK
  • System Info => OK
  • Radio Paradise => OK
  • 80s80s Radio => OK
  • Spotify => OK
  • PeppyMeterBasic => OK
  • PeppySpectrum => OK
  • Randomizer => OK

Hey @seanvan,

You’re running into a known limitation of WSL2: the virtualized kernel cannot reliably propagate loop device partition table changes, which causes failures like:

we have been unable to inform the kernel of the change

This affects all builds that rely on direct use of losetup, parted, or kpartx, as is done in the Volumio image creation script (makeimage.sh). The problem stems from how WSL2 abstracts devices and lacks support for kernel re-reads of partition tables on loop devices.

Hint on Approach:

There is an alternative image creation method proposed in volumio3-os PR #247 which avoids raw loop device handling. Although it was originally created for Volumio 3.x (Buster), the same technique can be adapted for Bookworm-based 4.x builds.

The PR #247 method:

  • Does not rely on losetup or loop partitions
  • Compatible with Docker Desktop for Windows using the WSL2 backend
  • Avoids the kernel partition sync problem entirely

Important Notes:

  • This method is not officially supported for Volumio 4.x (Bookworm)
  • You will need to manually adapt the method into the volumio-os Bookworm build system
  • Do not attempt to use the existing makeimage.sh with loop device logic inside WSL2 - it will fail consistently

If building natively on Linux is not possible, the safest supported alternative is to run the build in a full VM (e.g., Debian Bookworm in VirtualBox or QEMU) with proper kernel loop support.

Kind Regards,

Hi,

I just ran into a state where Volumio refuses any playback from Tidal (directly from the Volumio UI). Version 4.010 (AMD64)

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

After playing WebRadio, Tidal does work again:

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

Cheers,
Robert

Toshiba Click Mini not tested due to the splitscreen issue

Hey @Robert.Hecht,

Thanks for providing both logs and clearly describing the sequence.

From the first log (q2XJCGQ), we see that after selecting a Tidal track via the UI:

  • TidalConnectService::handlePlay is triggered
  • stateService::play and musicLibrary.play are executed
  • But no pushState with status play follows, and no actual playback starts
  • There are no visible errors from Tidal or MPD
  • The player remains in an inactive or paused state

Then in the second log (cudvJf3), after starting WebRadio:

  • The player enters a valid play state (CoreStateMachine::pushState status: play)
  • Tidal is selected again afterward and now plays correctly

This indicates that the WebRadio playback caused the system to reset its internal playback state, which allowed Tidal to work again. There was no MPD restart or system reboot between these events.

Non-conclusive:
The logs support that playback state logic became stuck when attempting to play Tidal directly. Starting a WebRadio stream corrected this condition, likely by forcing a clean state transition. There is no evidence of backend or streaming errors - only a failure to transition into a valid playback state.

This may point to a state synchronization hiccup between the streaming logic and the state machine in Volumio 4.010 (AMD64).

It would be helpful to monitor the situation here.

Kind Regards,

Hey @Robert.Hecht,

Thanks for sharing the log (fE9DC2W) and clear description of the behavior.

From the log:

  • The music library scan proceeds normally up to track 6450.

  • The last logged scanned file is:

    /media/music/.../Various Artists/Back To The Future (Original Soundtrack)/08 - Back To The Future - Alan Silvestri.flac
    
  • After this point, there are no further scan log entries.

  • There are no error messages, crashes, or USB device disconnects.

  • The USB drive (/dev/sda1) remains mounted and accessible.

  • No evidence of file corruption, unsupported formats, special character issues, or I/O failures appears in the logs.

Inconclusive:
The scan stops silently with no logged cause. The reason for the interruption is not visible in the current log.

Kind Regards,

I have made a new installation of Volumio 4.010 on Raspberry Pi 4. It boots and configures well, and is running fine. I have a Qobuz account which I have logged into and it shows up on Sources Visibility. However, Qobuz Connect is not showing in Functionalities Control. I notice that it says under the topic “Known Issuse Tracker” that Qobuz Connect is “Under developer review”. Is it not enabled yet? I notice that Tidal Connect is showing up in Functionalities Control, but I don’t have a Tidal account and am not logged into Tidal.

So, is Qobuz Connect temporarily disabled as a source?

Qobuz connect is not enabled yet on the Beta releases. This will be done in a later stadium. No ETA yet.

1 Like

Thank you. I’ll monitor the situation and continue to test the BETA.

1 Like

Hey @RedEyeNinja,

Thanks for the update and full data set from your Pi4 with HiFiBerry Digi running Volumio v4.010.

Facts

1. DAC Not Detected on First Boot

From your log E9u53qn.html, the file:

/data/updatesHistoryFile

shows:

Tue Jun 03 2025 22:22:49 GMT+0700
{"systemversion":"4.010",...}

This confirms the system was booted immediately after an update.
There are no prior entries, meaning the HiFiBerry Digi overlay had not been configured or loaded yet.
The absence of card index (hw:2,0) and resulting aplay failure:

aplay: audio open error: No such file or directory

is consistent with the DAC not being set up yet, not a runtime detection failure.

After a power cycle, the overlay was loaded correctly and the DAC appeared in aplay -l.

2. Format Capability and Test Results

From:

aplay -D hw:2,0 --dump-hw-params /dev/zero

Reported:

  • RATES: [32000 192000]
  • FORMATS: S16_LE, S24_LE
  • S32_LE is not supported

Your speaker-test used S32_LE, which the DAC rejects:

speaker-test ... -F S32_LE
→ Invalid argument

This explains why 192/24 playback may be silent in Volumio: MPD defaults to S32_LE unless constrained, and the DAC simply ignores unsupported data.

3. Playback Behavior Summary

  • 44.1/16 → OK
  • 96/24 → OK
  • 192/24 → Silent (but DAC displays 192kHz lock)
  • DSD → Not supported (expected)

Matrix Entry: Pi4 + HiFiBerry Digi

Test Result Message / Behavior
aplay --dump-hw-params Rates up to 192000, formats: S16_LE, S24_LE
aplay 192kHz WAV (pending) ? Please confirm with -f S24_LE
speaker-test 192kHz S32_LE Format not supported
Volumio playback Partial 192kHz displayed, but no sound

Next Step: Confirm Playback with Valid Format

Please run:

aplay -D hw:2,0 -f S24_LE -r 192000 /path/to/test-192k.wav

If this succeeds, it confirms Volumio’s MPD pipeline must be told to avoid S32_LE for this DAC.

Looking forward to the Pi5 results as well.

Kind Regards,

1 Like

HW:

  • Raspberry Pi 5 Model B Rev 1.0, version: c04170
  • Innomaker DAC Pro
  • 3.5 inch Resistive touch screen (dtoverlay=waveshare35a:rotate=90,speed=41000000,fps=50)
  • Booted from ID 0781:55a3 SanDisk Corp. SanDisk 3.2Gen1

Tested:

  • Updated from V4.005 to V4.010 => OK
  • NAS Mount via CIFS, Options blank => OK
  • NAS Mount via NFS, Options blank => OK

Plugins:

  • Rotary encoder (GPIO 5-6) => OK
  • IR Controller => OK
  • System Info => OK
  • Touch display => OK
sudo apt-get -y install xserver-xorg-video-fbturbo
sudo apt-get -y install xserver-xorg-input-evdev
sudo cp /usr/share/X11/xorg.conf.d/10-evdev.conf /usr/share/X11/xorg.conf.d/45-evdev.conf
sudo curl -L https://raw.githubusercontent.com/goodtft/LCD-show/master/usr/99-calibration.conf-35-0 -o /etc/X11/xorg.conf.d/99-calibration.conf
sudo curl -L https://raw.githubusercontent.com/goodtft/LCD-show/master/usr/99-fbturbo.conf -o /usr/share/X11/xorg.conf.d/99-fbturbo.conf
sudo sed 's/"fbturbo"/"fbdev"/' -i /usr/share/X11/xorg.conf.d/99-fbturbo.conf
sudo sed 's/fb1/fb0/' -i /usr/share/X11/xorg.conf.d/99-fbturbo.conf
  • Radio Paradise => OK
  • 80s80s Radio => OK
  • Spotify => OK
  • FusionDSP => OK
  • PeppyMeterBasic => OK
  • PeppySpectrum => OK
  • Squeezelite MC => OK
  • Randomizer => OK

Sound:

  • DSD 64, 128, 256, 512, 1024 => OK
  • MP3 => OK
  • MP4 => OK
  • Flac 44.1kHz (16, 24, 32 Bit) => OK
  • Flac 48kHz (16, 24, 32 Bit) => OK
  • Flac 96kHz (16, 24, 32 Bit) => OK
  • Flac 192kHz (16, 24, 32 Bit) => OK
  • Flac 384kHz (16, 24, 32 Bit) => OK
  • WAV 44kHz-16bit, 48kHz-16bit, 88kHz-24bit, 96kHz-32bit, 176kHz-32bit, 192kHz-32bit => OK

Fail:

  • Qobuz => Playlist => Search => Volumio crashes. Same behavior as web radio.
  • Tidal => Genre/moods => Search => Volumio crashes. Same behavior as web radio.
  • DSD 1024 => Plays but when moving slider Volumio gets stuck
  • Rotary encoder (GPIO 17-27)

@nerd

Pi5 8gb w/ NVME on 4.01 outputting thru i2s/HDMI, installed fine and no issue adding plugins, but when adjusted settings in Now Playing, it crashed the display system upon saving and I’ve reported that with a log on the other thread. Here’s the Pi5 192/24 tests as requested, after 192/24 show locked on DAC but no sound:

  1. Running [aplay -D hw:0,0 --dump-hw-params /dev/zero]:
aplay: main:831: audio open error: Unknown error 524
  1. Run [speaker-test -D hw:0,0 -c 2 -r 192000 -F S32_LE]:
speaker-test 1.2.8

Playback device is hw:0,0
Stream parameters are 192000Hz, S32_LE, 2 channels
Using 16 octaves of pink noise
Playback open error: -524,Unknown error 524
  1. Playback on volumio:
  • Thru i2s/HDMI, 44.1/16 played fine, 192/24 shows 192kHz on DAC but no sound and similar for DSD
  • Thru coax, 192/24 played fine
  • no error messages on screen

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

EDIT:

  1. Running “aplay -D hw:2,0 -f S24_LE -r 192000 test.flac”:
aplay: main:831: audio open error: Unknown error 524

Just a reminder that the context for this is that at some point in the alpha, 192/24 played fine on both devices thru i2s/HDMI and DSD as well. Was there and will there be active effort to suppress capabilities of widely available DIY hats?

On the pi4, running this command on the 192/24 file:

aplay -D hw:2,0 -f S24_LE -r 192000 test.flac

shows

Playing raw data 'test.flac' : Signed 24 bit Little Endian, Rate 192000 Hz, Mono
aplay: set_params:1358: Channels count non available

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

Hey @RedEyeNinja,

Thanks for the new log TcpgAl4.html and the command output related to aplay. The log itself doesn’t contain the CLI test, but your terminal output gives us a clear picture.

What Happened

You ran:

aplay -D hw:2,0 -f S24_LE -r 192000 test.flac

and got:

Playing raw data 'test.flac' : Signed 24 bit Little Endian, Rate 192000 Hz, Mono
aplay: set_params:1358: Channels count non available

This failure occurred because aplay treated the input file as raw uncompressed PCM, based solely on forced format options.

The file test.flac is a compressed container and must be decoded first. When passed directly to aplay, it cannot be interpreted correctly - resulting in a mono stream that the HiFiBerry Digi rejects, since it requires stereo at minimum.

What we have not yet verified

We have not confirmed the actual format of test.flac. Before attributing the issue to the DAC or format negotiation, please validate the file with one of the following:

ffprobe test.flac

or:

flac -a test.flac

Please post:

  • Sample rate
  • Bit depth
  • Channel count

This will confirm whether the file is indeed 192kHz, 24-bit, stereo FLAC, and suitable for playback over S/PDIF.

Next step

Once confirmed, decode the file to WAV:

ffmpeg -i test.flac test.wav

Then test with:

aplay -D hw:2,0 test.wav

This will send properly formatted uncompressed audio directly to the DAC.

Let us know what you find from the file check. That will determine whether we’re dealing with a format mismatch or a DAC/driver constraint.

Kind Regards,

Output from “flac -a test.flac”:

frame=0	offset=86	bits=127688	blocksize=4096	sample_rate=192000	channels=2	channel_assignment=INDEPENDENT
	subframe=0	wasted_bits=0	type=LPC	order=10	qlp_coeff_precision=15	quantization_level=12	residual_type=RICE2	partition_order=4

After running “ffmpeg -i test.flac test.wav” and then “aplay -D hw:2,0 test.wav”, the DAC shows 192kHz but no sound.

Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 192000 Hz, Stereo

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

Hey @RedEyeNinja,

Thanks for running the flac -a and playback tests. Here’s what we now know from this phase.

1. Confirmed file format

From:

flac -a test.flac

You confirmed:

  • Sample rate: 192000 Hz
  • Channels: 2
  • Bit depth: not explicitly reported but implied from encoding structure (valid for 24-bit)

This confirms that test.flac is a valid stereo 192/24 FLAC file, suitable for playback on HiFiBerry Digi via S/PDIF.

2. Decoded playback test

You decoded to WAV and ran:

aplay -D hw:2,0 test.wav

Result:

  • DAC shows 192kHz lock
  • No sound
  • No error messages

This implies the stream is accepted at the hardware interface level (clock lock achieved), but the content is not being rendered as audible output.

3. Log review: BIPEg9Z.html

The log contains:

  • No ALSA-level playback errors
  • No underrun events
  • No snd_soc_pcm_trigger or DMA allocation issues
  • No codec or I2C errors

In short: the system believes playback was successful.

Interpretation

The HiFiBerry Digi is likely accepting the 192kHz PCM stream but your connected S/PDIF receiver is silently rejecting it - this is common behavior if the receiving DAC or AVR:

  • Has a sample rate limit (often 96kHz over TOSLINK)
  • Only supports certain bit widths (e.g., 16 or 24 bits, not 32-bit containers)
  • Requires proper preamble or channel status bits (beyond ALSA’s concern)

This is also consistent with your earlier observation:

192/24 plays fine on coax/spdif but not DSD…and thru i2s/HDMI, DSD and 96/24 and below plays fine except 192/24.

Next step

Please confirm:

  • Is the output you’re testing over optical (TOSLINK) or coaxial?
  • Can your receiver confirm support for 192kHz input on that interface?

You’ve now successfully proven that:

  • The file is correct
  • ALSA can transmit it
  • The DAC accepts it
  • But the chain beyond the DAC may not be rendering it

We’ll keep tracking this to help resolve output format constraints across different sinks.

Kind Regards,

Testing over i2s/HDMI as stated and clarified prior.

  • coax/optical plays fine up to 192/24…my DAC can handle high bitrate and DSD playback.
  • the issue, I will repeat again…is that i2s/HDMI outputs all formats in the alpha at some point and now i2s/HDMI will not output sound to the same DAC at 192/24 and maxing out at 96/24 thru i2s HDMI. Please let me know if I can make this any more clear by stating it some more.

In addition, here’s another log of the Hifiberry Digi not being recognized after reboot. This is not a first reboot after flash but rather, after several reboots where it worked before, and stops recognizing it randomly after reboots from my observations.

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

Hey @RedEyeNinja,

Thanks for the update, log P8TYhho.html, and clarification regarding HDMI/I2S playback.

1. Playback behavior over I2S/HDMI

Understood: you’re reporting that 192/24 playback via HDMI/I2S no longer produces sound in your current setup, while the DAC locks to 192kHz.
You’ve also stated this worked on a previous Alpha version.

However, at this point, we have:

  • No reproduction from other community members
  • No controlled regression reference version
  • No physical access to your hardware to rule out partial failure or external chain issues

So this remains an issue specific to your environment only, and cannot be classified as a confirmed regression until more data is gathered.

To trace the delta precisely, we need:

That will allow us to identify any build, firmware, or pipeline change involved.

2. DAC and source file are valid, but playback is silent

Your decoded test file:

  • Was correctly identified as 192kHz stereo FLAC
  • Was converted to WAV
  • Plays with no error via aplay, and DAC shows clock lock at 192kHz

Yet: no audio output occurs at that rate via I2S/HDMI in your setup.

Nothing in the logs indicates underrun, DMA failure, or codec error.

This behavior may be due to output format mismatch, pipeline change, or device-specific limitation - but again, this cannot be generalized without further test reports.

3. HiFiBerry Digi detection failure

From P8TYhho.html, it’s also noted that:

  • The HiFiBerry Digi overlay sometimes fails to load across reboots
  • This is no longer limited to first-boot conditions

This intermittent behavior will be tracked, but also remains a single-device report for now. No conclusive system-wide pattern exists yet.

Closing note

Just to clarify - I’m not Volumio staff, nor serving in any support capacity.
Like you, I’m a community contributor volunteering time around other responsibilities.

When detailed input is requested, it’s to maintain technical accuracy, not personal convenience.

Looking forward to the version reference so we can properly resolve this.

Kind Regards,

2 Likes

If it hasn’t come across, I want to be clear that by participating in the community, spending my time testing and sending in logs, is in hope that Volumio will be used by more ppl. There is a possibility that I AM THE SINGLE ONE PERSON ON EARTH USING THIS AUDIO HAT and using Volumio, testing alpha/beta…or the more likely possibility is that I’m just using a commonly available and affordable audio HAT that also works with Volumio, like a large portion of other current and potential users.

If my time and continued efforts despite the frustration isn’t enough appreciation…well, here’s a sincere thank you for your hard work.

Unlike you tho, I am not aware of the goal of my continued participation and contributing my time and efforts to testing alphas and beta in hopes of also helping others come onboard…I am wondering out loud whether what I’m testing and contributing will be used to actually create a new version that works better? Or am I/are we beta testing a potentially premium only offering that will never work right for my hardware? Am I/are we beta testing for Volumio premium offerings with features that will not be available to the average non-premium user?