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

Volumio Development Volumio Beta Testing
, ,
348

Hey @jacobacci,

Thanks again for your outstanding contribution. Your detailed testing and documentation across multiple USB storage enclosures, chipsets, and Volumio versions has uncovered critical compatibility insights. This kind of deep, methodical feedback is highly valued and directly informs how we improve platform stability. Here’s a full summary of the findings:

1. USB Storage compatibility: Volumio 4 vs Volumio 3

  • Testing with a 28TB RAID0 NTFS volume using a JMicron JMS56x (VID:PID = 152d:9561) USB-SATA bridge:

    • Volumio 4.0.17: Scan consistently halts at 3292 tracks, with repeated ntfs_attr_pread I/O errors.
    • Volumio 3.819: The exact same drive scans successfully. After factory reset, scan progressed to 141,084 tracks without issues or powered USB hub.

  • Errors in Volumio 4:

    ntfs_attr_pread failed: Input/output error
ntfs_attr_pread error reading '/music/...flac' at offset ...

  • This confirms a functional regression in how Volumio 4 interacts with large NTFS volumes and FUSE I/O error handling.

2. Controller-specific behavior across multiple enclosures

  • JMicron JMS56x (152d:9561) - Partially working:

    • Detected but fails under Volumio 4 without quirks.
    • Known to misbehave with UAS on RPi unless usb-storage.quirks=152d:9561:u is applied.

  • ASM235CM (RaidSonic GT1670-BA31) - Not detected:

    • Entire enclosure fails enumeration in Volumio 4 (lsblk empty), despite being known-good.

  • ASM1153E - Fully working:

    • 4TB SSD in exFAT format is detected and scanable under Volumio 4.

  • These differences strongly suggest that Volumio 4’s USB stack, UAS support, or kernel timing has changed and is less tolerant of chipset-specific quirks.

3. Background: Known USB controller Issues on Raspberry Pi

Your observation aligns with a known, documented class of issues covered in the Volumio community:

Reference:
https://community.volumio.com/t/guide-prepare-raspberry-pi-for-boot-from-usb-nvme/65700/46

Summary of Problematic Chipsets:

  • JMicron JMS578/JMS583

    • Require usb-storage.quirks=152d:0578:u or 152d:0583:u

  • ASMedia ASM1153/ASM235CM

    • Quirks: 174c:1153:u, 174c:235c:u

  • Realtek RTL9210 (early firmware versions)

  • VIA VL716/715

These chipsets may fail detection after soft reboots or cause instability during enumeration and are documented to affect not just boot devices but runtime-attached storage as well.

4. Quirk application barrier: Volatile cmdline.txt

  • Workarounds involving UAS quirks rely on modifying /boot/cmdline.txt
  • However, Volumio overwrites this file on every OTA update and discards it during fresh installs.
  • This makes it impossible for users to persist USB controller fixes long-term.

5. Request: Persistent kernel parameter override support

To resolve this sustainably, I will internally propose that Volumio support a user-editable kernel parameter override file such as:

/boot/usercmdline.txt

This would:

  • Be ignored by default
  • If present, its contents would be appended to the bootloader command line
  • Provide a safe and persistent path for users to declare USB quirks or other device-specific workarounds

This is low-priority, but technically feasible, and would improve robustness across all SBC platforms Volumio supports. However, no promises that this will be implemented at all.

Thanks again for taking the time to run these tests and provide controller-specific diagnostics. This kind of high-effort input directly supports real-world usability improvements.

Kind Regards,

1 Like