Issue with playing music from Micro SD (Solved)

The I/O performance of an SD card in the LIbrem 5 is grim but should should still be plenty enough to provide uninterrupted playback of common audio formats, unless there are a number of processes all accessing the card at the same time.

I’m inclined to suspect that perhaps the card reader is idling down for power saving, and that the second or so interrupts are due to the time involved in the card reader coming back up, have you tried disabling any power saving on the card reader? It wouldn’t be a long term solution as I would think it would quite detrimental to battery life but for issue isolation it may help narrow it down or rule it out.


That’s a good suggestion.

Let me add to my report that my files are .FLAC, and for those who might not know, that’s a lossless compression that typically is 50% as large as the original .WAV.

1 Like

@amosbatto already provided link to this info: “The dedicated flash media reader is internally attached to a 3rd downstream port of the hub as a USB compound device. This combo solution supports today’s popular multi-format flash media card formats. The flash media interface can support sustained transfer rates exceeding 35 MB/s if the media and host support those rates.

EDIT: I’ve just made three different partitions on my microSD card and few .MP4 identical 200MB files (from some Android device) doesn’t pull normally either (just useless attempt from my side to watch those from some microSD card, to the integrated slot inserted one). Actually just confirmed to myself what @shopping4purism already explained here.

Try a wav file. It may not be the transfer rate but rather something to do with the compression?

I was able to repro the interrupts issue with Silverjuke using .flac audio files, disabling power saving on the card reader and restarting Silverjuke helps (the interrupts appear less frequent and for shorter duration) but it does not completely resolve the issue.

I’d guess that the files are being read in small chunks with no (or very little) buffer and is presenting some incompatibility with the card read/access performance.

Sorry, I’ve missed your request.

Here it is.
fdisk -l /dev/sda returns:

Disk /dev/sda: 238,3 GiB, 255869321216 bytes, 499744768 sectors
Disk model: Ultra HS-SD/MMC 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xbfc7eccd

Device     Boot Start       End   Sectors   Size Id Type
/dev/sda1        2048 499744767 499742720 238,3G  7 HPFS/NTFS/exFAT

blkid /dev/sda1 returns:

/dev/sda1: UUID="be0a6235-cd28-4fbe-a960-897ef3d33529" BLOCK_SIZE="4096" TYPE="ext2" PARTUUID="bfc7eccd-01"

and hdparm -t /dev/sda1 returns:

Timing buffered disk reads:  18 MB in  3.00 seconds =   6.00 MB/sec

As for your request:
Your reply might help others huge only if you participate in my proposed approach, I cannot help any further, it is simply that @tracy and I do believe that both of your microSD cards are usable but not ready nor capable to deliver with your current setup of them.

I’m always willing to try out the options you suggested, but somehow I’m not sure that these actions are the root of the problem.

I see that others are experiencing the same issue with other types / sizes / brands of memory cards.

1 Like

Hi Steve,

I have been using Silverjuke for many years now.
I tried several other players but never have been able to find a better solution.
for my purpose.

You are right that the current skin is not an ideal skin for using on the L5.
However, creating your own skin is one of many things I like about Silverjuke.

I’m seriously thinking of making a skin optimized for the L5, but I’m reluctant to spend time into such project because of the discovered problem.

So, I do hope we can find a solution for the playback problem.

Can you let us know how you can disable power saving on the card reader (just for testing)?

To simplify my previous post (regarding. memory, I/O, & CPU), if you eliminate hardware as the problem, it’s gotta be the software.


To disable power saving on the card reader you need to write to the devices power/control file. To find the required file path you can check lsusb -tvv your looking for the details of the 'media card controller`.

From the terminal…

loki@sikozu:~$ lsusb -tvv
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    /sys/bus/usb/devices/usb2  /dev/bus/usb/002/001
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    /sys/bus/usb/devices/usb1  /dev/bus/usb/001/001
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M
        ID 0424:2640 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
        /sys/bus/usb/devices/1-1  /dev/bus/usb/001/002
        |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
            ID 0424:4041 Microchip Technology, Inc. (formerly SMSC) Hub and media card controller
            /sys/bus/usb/devices/1-1.1  /dev/bus/usb/001/003
        |__ Port 2: Dev 4, If 3, Class=Vendor Specific Class, Driver=option, 480M
            ID 2020:2060  
            /sys/bus/usb/devices/1-1.2  /dev/bus/usb/001/004
        |__ Port 2: Dev 4, If 1, Class=Vendor Specific Class, Driver=option, 480M
            ID 2020:2060  
            /sys/bus/usb/devices/1-1.2  /dev/bus/usb/001/004
        |__ Port 2: Dev 4, If 4, Class=Vendor Specific Class, Driver=qmi_wwan, 480M
            ID 2020:2060  
            /sys/bus/usb/devices/1-1.2  /dev/bus/usb/001/004
        |__ Port 2: Dev 4, If 2, Class=Vendor Specific Class, Driver=option, 480M
            ID 2020:2060  
            /sys/bus/usb/devices/1-1.2  /dev/bus/usb/001/004
        |__ Port 2: Dev 4, If 0, Class=Vendor Specific Class, Driver=option, 480M
            ID 2020:2060  
            /sys/bus/usb/devices/1-1.2  /dev/bus/usb/001/004

From the above output you’ll see that the path for the Microchip Technology, Inc. (formerly SMSC) Hub and media card controller is /sys/bus/usb/devices/1-1.1

You can check the current value (which should be “auto”) with…

cat /sys/bus/usb/devices/1-1.1/power/control

To disable power saving set the value to “on”…

sudo -i
echo on > /sys/bus/usb/devices/1-1.1/power/control 

This setting is not persistent and rebooting the phone will reset the option back to the default “auto”, echoing the default “auto” to the file will also revert the change.

1 Like

Yes, even though WAV is about as inefficient as it gets, it does not take much bandwidth. For CD quality, WAV should need about 176 KB/sec, which is well well below the admittedly underwhelming speed of the uSD card in the Librem 5 (about 10 MB/s, give or take).

High quality MP3 (320 kbit/sec) is about 3 to 5 times compressed, compared with WAV.

I would suspect a software problem in the player e.g. no buffering or e.g. poorly implemented producer / consumer architecture.

I’m not familiar with that particular player but some give you a visual indication of the producer and consumer so, knowing the size of the MP3 (in my case), you can guesstimate the buffer size - and observe the behaviour. For example, the MP3/MP4 player within Firefox does this (but then in that case I can monitor the behaviour from the web server anyway).

So, properly done, even if the producer goes off into la la land for 1 second, it should not cause any interruption with the consumer.

I believe that the uSD card reader is being power-saved.

Presuming that the player is open source, or otherwise, it might pay to look into whether there are any tunables relating to buffering behaviour.

One minor additional issue … there have been some reports of playback via Bluetooth speakers being stuttery (although I don’t experience that). So you should confirm that you are playing back via the internal speaker or the headphone jack.

I can confirm that I’m using the internal speakers of the L5.

A bit more info on Silverjuke:
It’s a while since it is open source software.
Just take a peek at: and at

Hi Carlos,
What you say sounds interesting.
Do you know if an issue has been created at Purism for this?
If so, can you point me to it (I am unable to find it).

1 Like

Today I tested it with disabled power saving settings.
And I agree, the playback interuption is now less longer (perhaps half a second) as when power saving is enabled.

Thank you Loki for showing me how to do this. :beers:

So how to proceed from here.


  • Is it because of a poor caching of some music players (like Silverjuke) or is it because of a problem with the SD card interfacing software, or is it a combination?

  • What can be done to find the issue causing the problem?

  • Do I need to create an issue at Purism, or is it far too early to do so?

1 Like

Do you do source code?

I’m afraid my coding skills for C, C++ etc. are zero.
Scripting is the field where I have some experience with (and with Visual Basic from the last century).

For MS Windows there are troubleshooting tools like those from SysInternal.
I’m not sure if you are familiar with those tools, but I was wondering if something like those tools are available for Linux.

But source isn’t thing to “do”, it is a thing to be “compiled”! (Humor)

I only wish this stuff were done in C or C++, it seems like every package is done in its own obscure language (I can’t even figure out what Squeekboard was done in), with its own obscure replacement for make.

The source of Silverjuke is mostly written in C/C++ according to their Git hub pages.