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.
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.
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.
@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.
You are validating core audio pipeline functionality:
This is not a plugin compatibility test. However, your current logs include:
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:
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.
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:
dtoverlay=i-sabre-q2m
fails on kernel 6.12.x with I2C errors. This breaks expected HAT initialization.Please clarify the exact codec used. If no response, I will formally report incompatibility to community support threads.
Silence so far.
Kind Regards,
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:
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
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.
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:
alsa-restore
actually has valid state to restore,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.
vc3SbzJ.log
DSD Playback (DoP) over I2S/HDMI
S32_LE
format, and the DAC locks to 176.4 kHz - standard for DoP192/24 Playback
The i-sabre overlay is binding to a board that does not properly support it, resulting in:
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,
@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.
Please disable onboard WiFi and test again.
Kind Regards,
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:
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:
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
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