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

Thank you, kind sir!

EDIT: Just to add, after I switched to the “Test” channel, I didn’t have to reboot, and “checking for updates” brought up the prompt to do so. Also had to reauthorize Spotify after the update.

@nerd

Pi5 8gb w/ NVME, updated to 4.014 via OTA, everything works fine. I also got DSD to play over PCM thru i2s/HDMI but there’s quite a bit background hissing. I know it may be some voodoo coincidence or I’m running some forbidden combo, but I remain hopeful. Audio HAT overlay used is the Audiophonics Sabre option. One thing to note but I didn’t get to test it, unfortunately…on 4.013, while choosing playback options, mine popped up with an option for the Sabre DAC QM-something, WITHOUT choosing I2S option, eventho this hat is connected via GPIO.

Here’s a log from 4.014 right after playing back 2 DSD files over PCM thru i2s/HDMI, with the hissing.

http://logs.volumio.org/volumio/9XLXuFq.html

EDIT: WOOHOO! Successful, flawless playback of 192/24 FLAC thru i2s/HDMI.

http://logs.volumio.org/volumio/0DmaZgV.html

EDIT 2: I celebrated too soon. After the last successful playback of 192/24 FLAC thru i2s/HDMI of 2 songs, I stopped the song to get the log and afterwards, 192./24 FLAC will no longer play back, along with loud a click at manual song start and stop.

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

@Rui_C
I built a specific image to trace your unmute issue. Please download Volumio-0.001-2025-06-30-x86_amd64.zip and let us (@nerd and me) know the outcome by submitting a log. The log holds extra information to help us identify the mixer name mismatch.

Hey @RedEyeNinja,

Thanks again for the comprehensive logs and updates. Based on the latest findings, it’s now clear that your tests on 4.014 were not isolated to core ALSA/driver behavior, due to active plugin layers.

Clarified scope

You are validating core audio pipeline functionality:

  • I2S output over GPIO using an Audiophonics-style DAC
  • DSD (DoP) and high-res FLAC (192/24) playback
  • ALSA stability and overlay compatibility on kernel 6.12.27

This is not a plugin compatibility test. However, your current logs include:

  • FusionDSP: active, modifies stream
  • PeppyMeterBasic: active, intercepts audio for visualization
  • Now Playing: active, possible Chromium hooks

These must be disabled for conclusive analysis of core behavior. A clean asound.conf must route pcm.volumio directly to hardware via volumioOutput.

We will continue isolating issues to determine if any regression is due to:

  • DAC overlay mismatch
  • DSD framing errors
  • ASoC driver changes in 6.12.x

If plugins are found to interfere after core issues are resolved, those aspects will be directed to the relevant plugin developers. Our priority is to fully decouple and validate the base audio transport layer first.


Clarification request sent to the R19 HAT supplier

Following detailed investigation and confirmation by multiple developers and users in the Volumio community, I must highlight serious issues with the board you sold, labeled as i-sabre:

  • False driver claim: The IC is sanded, no proof of genuine i-sabre. dtoverlay=i-sabre-q2m fails on kernel 6.12.x with I2C errors. This breaks expected HAT initialization.
  • Misleading representation: Saying it uses “third-party drivers to output IIS” is incorrect. It is I2S, and your board falsely identifies as i-sabre without supporting its protocol.
  • No supportability: This board fails across all recent Raspberry Pi distributions, not just Volumio. Without a real codec or documentation, we cannot support it or recommend it.

Please clarify the exact codec used. If no response, I will formally report incompatibility to community support threads.


Silence so far.

Kind Regards,

1 Like

Hey @Rui_C,

To help resolve this, @gkkpch has already built a dedicated trace image for your setup:

Image:
Volumio-0.001-2025-06-30-x86_amd64.zip

Please flash and boot this image, then submit a full log via:

http://<your_volumio_ip>/dev

The log includes extra debug information that will allow us (@gkkpch and @nerd) to confirm whether there’s a mixer name mismatch or other config issue.

Also, since you previously mentioned needing to make a manual change in alsamixer, please clarify:

  • Path and file name you are changing
  • Original content before the change
  • Modified content after your change

We are treating this seriously, but we need complete data. Without these logs and details, we have no basis to proceed, and this will be marked as resolved (no further response).

Kind Regards,

Hey @Gelo5,

Can you show the content of the alsa state?

cat /var/lib/alsa/asound.state

Kind Regards,

Hey @nerd
asound.state is empty

@nerd

Thank you and I’m glad you reached out to the supplier, but I don’t have much hope for contact from them. They sent my item late and it sat in customs for no good reason for over 2 weeks. I’ve turned off the plugin’s you requested and rebooted.

I was able to play a DSD over PCM thru i2s/HDMI but it had the same background hiss/noise. Trying to play the 192/24 file I’ve been using for testing, it plays but there’s no sound out to the DAC eventho the DAC shows 192kHz and there was also a very loud click and pop when I tried to play it. I tried another 192/24 file and it played but started with a very loud cut/pop eventho I had volume turned down and then it wouldn’t output another 192/24 file again after. I also tried other different bitrates. Here’s a log.

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

Hey @Gelo5,

Eureka… or maybe half-Eureka.

What started as a volume mystery might just come down to something surprisingly simple:
Shell-initiated reboots bypass Volumio’s shutdownd sequence, which is the part responsible for gracefully saving system state before power cycles.

But here’s the catch - this is not the whole story.

Through recent internal audio paths forensic work, I’ve been revising how systemd services interact at shutdown and boot:

  • Ensuring alsa-restore actually has valid state to restore,
  • Fixing timing so that hardware (like sound cards) is ready before anything tries to touch it,
  • Adding ordered dependencies and drop-in override fragments that guarantee services like volumio.service and mpd.service don’t fire out of sync.

So yes, if /var/lib/alsa/asound.state is empty, that’s a clue.
But the underlying fix isn’t just “always use the UI” - it’s ensuring the shutdown and boot paths are predictable, persistent, and safe, even under shell reboot or power events.

This work is ongoing, and while the surface behavior seems simple, the real cause has always been hiding in the complexity of systemd sequencing and unhandled shutdown paths.

In short:
Baking - for Saturday’s weekly beta.

Kind Regards,

Hey @RedEyeNinja,

Thanks for disabling the plugins and providing a clean test log.

Findings from vc3SbzJ.log

  1. DSD Playback (DoP) over I2S/HDMI

    • Still results in background hiss
    • ALSA shows the stream is handled via S32_LE format, and the DAC locks to 176.4 kHz - standard for DoP
    • No ALSA errors reported, which means the stream is “technically” delivered
    • The hiss strongly suggests DoP packet framing is not being interpreted correctly by the DAC, likely due to invalid or misaligned LSB markers
  2. 192/24 Playback

    • First 192/24 FLAC file: DAC locks at 192kHz, no audio output, loud click/pop on playback start
    • Second 192/24 file: plays once (with loud transient), then fails on the next attempt
    • These symptoms are classic signs of DAI desynchronization or incorrect codec configuration
    • No clear ALSA buffer underruns or transport errors - it’s a hardware-level framing or stream handling problem

This confirms

  • The issue is not due to FusionDSP, PeppyMeter, or other userland processing
  • The failures are happening within the core I2S transport path, between ALSA and the HAT

Current working theory

  • The i-sabre overlay is binding to a board that does not properly support it, resulting in:

    • Broken clock config
    • I2C timeouts (seen in earlier logs)
    • Unreliable hardware handshakes after stop/restart
  • This board is not using a legitimate i-sabre chip, and is not properly supported in kernel 6.12.x


Since you’re now fully decoupled from plugins, and the symptoms persist - confirming this is a core compatibility fault between the HAT and the system.

Will bake a kernel version with full debugger and perhaps this way I can interrogate R19 to get some answers.

Kind Regards,

1 Like

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

@Rui_C
Please use this test image instead: Enhanced Realtek HD soundcard init for ALC897
I believe this one will solve your problem.
Let us know if this is the case, then we can add it to coming weekend’s beta version.

Hey @hifiswede,

From your Y6leWr8.html log I can see numerous challenge condition between onboard SoC WiFi and USB attached. The endgame is that non-managed interface is in an indefinite loop with locked dhcp request wait state.

What is missing in the log:

  • Unused WiFi interface is not disabled as discussed in this thread already.
  • No Bluetooth fail state reported, whereas full agent readiness is present.
  • No segfault evidence can be found

Please disable onboard WiFi and test again.

Kind Regards,

  1. Power supply model and specs (voltage, amperage, USB-C or GPIO powered) → Default Raspberry 27W power supply
  2. USB DAC port connection (USB 2.0 or 3.0) → USB 2
  3. Use of any USB hub (active or passive) → No, only direct connected to one of the USB2 ports
  4. How the display is powered (direct from Pi or external PSU) → directly from the Pi
  5. Any other connected devices (GPIO, HDMI, USB peripherals) → No
  6. Any cooling solutions or overlays in use (fan HATs, etc.) → Default Raspberry fan and the Geekworm X1001 M.2 NVMe SSD hat.
    I must say that after upgrading to the 4.014 release, both the systems runs much more stable without loosing Wifi credentials.

Hey @Plunder,

Thanks again for the detailed feedback and confirming the hardware layout. Since this thread centers on Wi-Fi instability, and your logs show repeated authentication rejections (status_code=16), we’re looking closely at all possible power-related contributors that might affect wireless stability.

In our work on NVMe boot support for Volumio, we found that the Geekworm X1001 HAT, while generally reliable, can under certain conditions silently underpower high-draw NVMe drives - especially during sustained I/O or system activity whilst powered down circuitry from USB.

This behavior is documented in the thread starting here (and below):
https://community.volumio.com/t/pcie-nvme-compatibility/65722/44

Although your system is not showing signs of direct NVMe failure, the manufacturer confirms the PCIe FPC provides only 5V at 1A (max 5W), and recommends using the 2-pin JST 5V input when in doubt.

To assess if this could be a contributing factor to your Wi-Fi symptoms, could you confirm the exact make and model of the NVMe SSD installed in the affected unit?

This will help us determine whether auxiliary power via the JST connector is required for your setup.

Kind Regards,

The SSD is the Kingston NV2 PCIe 4.0 NVMe M.2
SNV2S/500G
9907546 - 001.A02G
10283655 - 2405

Hey @Plunder,

Thanks for confirming all the hardware details.

Your setup - Raspberry Pi 5 powered via the official 27W USB-C PSU, with a Topping DAC on USB 2.0 and a touch display powered from GPIO - is well within spec under typical conditions. However, when paired with the Geekworm X1001 and Kingston NV2 SNV2S/500G, there’s a very specific electrical constraint worth clarifying.

Power path limitation:

  • The X1001 draws 5V from the PCIe FPC ribbon, which is limited to 1A max (5W).
  • The Kingston NV2 SNV2S/500G uses the Phison E21 controller, and under sustained write or burst activity can draw over 5.0W, momentarily exceeding what the ribbon can supply.
  • This drive has no onboard DRAM and relies heavily on controller and NAND activity, which increases transient power spikes.

Why this matters:

While everything might seem fine during idle or light I/O, your system is already operating at the absolute electrical limit for NVMe power delivery through the ribbon.

Facts:

  • The X1001 has no regulation or protection circuitry for the SSD 5V line
  • The Pi5 has to share USB and PCIe draw across a single input power bus
  • Your DAC and display both source from the same 5V domain

This creates conditions where the NVMe momentarily browns out, causing system instability in unrelated subsystems - like Wi-Fi. This would explain the crash symptoms, Wi-Fi config loss, and the absence of clear kernel or journal errors.

Required action:

To ensure full stability with the Kingston NV2 in this configuration, power the X1001 via the 2-pin JST 5V input. This bypasses the FPC power limit and ensures the SSD always receives clean and sufficient current, even during burst write or background I/O.

This is not theoretical - it’s a known behavior observed during NVMe boot development and matches both manufacturer guidance and our own internal testing.

Kind Regards,

Hi @nerd.
Thanks for this explanation. As soon as I can reproduce it again in 4.014 or newer beta releases I will give it a try with the addional 5V power to the X1001.

Great support!

ok thanks.
I did get it to work, dmesg prints some bt error but not crucial.
anyways this only works with cable plugged in.

using
dtoverlay=disable-wifi
dtoverlay=disable-bt
do disable rpi5-wifi disables volumios wifi stack or something.
wlan0 shows up in console but it does not connect. its been the same forever in volumio. so still not useable :frowning:

Jul 03 21:10:15 vardagsrumstereo systemd[1]: Starting networking.service - Raise network interfaces…
Jul 03 21:10:15 vardagsrumstereo ifup[983]: command failed: No such device (-19)
Jul 03 21:10:15 vardagsrumstereo iw[999]: command failed: No such device (-19)
Jul 03 21:10:15 vardagsrumstereo iwconfig[1010]: Error for wireless request “Set Power Management” (8B2C) :
Jul 03 21:10:15 vardagsrumstereo iwconfig[1010]: SET failed on device wlan0 ; No such device.
Jul 03 21:10:15 vardagsrumstereo ifup[1012]: command failed: No such device (-19)
Jul 03 21:10:15 vardagsrumstereo systemd[1]: wireless.service: Deactivated successfully.

doesnt look good!

here is full log
http://logs.volumio.org/volumio/LxP6ucT.html