Issue with playing music from Micro SD (Solved)


I’m experiencing an issue with playing music stored on my SD card.
Playing is interrupted often for a split second but then continues to play.

This is my setup:
OS: Byzantium 5.17.5
Micro SD card: SanDisk Ultra 256GB and 512GB (both tried and both brand new)
FileSystem: exFAT
Music Player: Silverjuke (Skin: Silveriness Touched)

My 256GB SanDisk Ultra is of type XC I (Class 10) - 100 MB/s
My 512GB SanDisk is not Ultra but Extreme PRO V30 XC I (A2) - 170 MB/s read 90 MB/s write

While monitoring with top in the terminal, I noticed that the brief interruption occurs when a process with name usb-storage uses some CPU (not much, between 2 to 6%).
I’ve changed the priority for usb-storage to 19 (using renice), but that did not change anything.

What can I do to find out what is happening here?
Please some advice and thanks in advance.

I’m doubtful that it has anything to do with your problem, but could you check from your SD cards what is their speed class ratings (“new” does not tell that) as the issue may be related to how efficient the transfer of data is. Reason why I doubt it is that music (common mp3) should not take much bandwith - or are you using some heavy lossless filetype?

Have you tried, does this occur with other players (Lollypop, VLC…)?

Hi JR-Fi

Thank you for replying.
I forgot to mention that my music collection is in .wav format.

When using VLC I do not have interruptions.
One could argue why not switch to using VLC, but VLC has not all the very nice features of Silverjuke.
I’ve tried several players, some seem to have the same issue, others don’t, but they all miss the wanted features of Silverjuke and/or do not function or scale properly on the L5.

I also forgot to mention: Using Silverjuke for playing music stored on internal memory goes without any problems.

1 Like

Ok, that narrows it down for you at least.

For comparison, I have a similar size card (U3 speed, also with LUKS) and Lollypop has no problem playing mp3s. Didn’t have wavs at hand to test if they are that much heavier but I doubt it, as I can play movies from the card (MP4).

We do not know real read or write approximate speed of your microSD cards (those are all right anyway):

But you can test (actually erase) the microSD cards you mentioned here like this: Librem 5 Phone - SD Speed. Also and before here linked dd command you might like to start here, by adjusting related command as needed:

Afterwards just go back to already installed Librem 5 Disks app and format used microSD card up to your choice. Good preparation might help, with very same microSD card, I guess.

EDIT: sudo apt install pv

Please share with us your MB/sec result by executing (from inserted microSD card):
sudo fdisk -l
sudo hdparm -t /dev/sda

Hi Quarnero,

I have edited my first message and included the missing specs.
Thanks for pointing out.
I’m not sure why I would want to erase my SD card, writing is not my main concern here.
Silverjuke is only reading the files and not writing to them.
Can you explain why I should perform a write test?

Anyway, I’ve tested the 512GB SanDisk Extreme PRO V30 XC I (A2) using the Disk App.
Sample size used: 100 MiB
Avg read speed (after 70 samples): 12.1MB/s

That’s not the best performance isn’t it?

1 Like

hdparm command gives you read out times on your device (as microSD card inserted/mounted within Librem 5). Some apps indeed do not come right with slow reading speeds therefore my recommendation to erase it and make it sort of native, and even test if ext2 partition allows for better performance with silverjuke.

My current (just testing one) 64GB card reads: 6.25 MB/sec (not the good one).

EDIT: 4096×4=16384 (in order to speed up) therefore change to bs=16384 if no time (and no need to use Librem 5 for this). And one of this (old school) SanDisk Extreme Pro microSDXC UHS-I A1 cards might easily be the right one to chose (but not that I’m sure):

I didn’t have hdparm but instead ran Discs benchmark (10Mb sample x 100 times and 1000 accesstime tests). From disc benchmark I got 14,2Mb/sec as average read rate and 1,67msec as average access time. Running the same as unlocked mounted partition benchmark I get 13,8Mb/sec and 1,69msec averages. Looking at the graph there is variation on both.

1 Like

My former co-worker once had a job as a supervisor at linkedin, They had a daily regimen of swapping out SD drives. But then again constant read/write is not your issue.

What about allocation unit size? What if you reformat with bigger allocation units?

If a unit is smaller than your music file could there be a pause as it seeks the next unit? An analogy would be like the old hard drives, where the read/write head had to actually “seek” the next segment.

Then again if your unit sizes are too big you’ll waste space. Maybe it would be better with itty bitty unit sizes?

I doubt this hard disc analogy is the same when seeking a location on solid state media but it at least makes a good story.

P.S. “Former co-worker” … we are both retired.


Yes, very good point and easily could/should lead to the relevant solution here. Furthermore we know (but I’m no expert) that reading from TLC NAND Flash isn’t as simple or as advanced as we would like to have it with huge amount of storage space available on some microSD card. This one will confirm (although another topic) that your current thought about size of allocation unit here makes a lot of sense (when preferably ext2 partition used): “Reducing the amount of stored bits in each cell to one increases the reliability and lifetime of the NAND Flash memory.” As well:

I’m running some read/write tests now after formatting the Micro SD card: SanDisk Ultra 256GB with ext2.
I will report the results when ready.

The results are:
Average read rate - 12.2 MB/s (10 samples)
Average write rate - 14.3 MB/s (10 samples)
Average access time - 1.44 msec (1000 samples)

The formatting was done on the L5.
Next I’ve copied some music files to the SD card.
Playing them with Silverjuke: Problem occured again.
So the filesystem and not having formatted the card in the L5 was not causing the problem. :neutral_face:

It is same like me before when i tryed to play .flac from SD to Lollipop in L5 and the music played stutered so seems there is a bug on SD manager and as far i know Purism it working in this area, so i guess it will be fixed on nexts linux version.


We still do not have output of your sudo fdisk -l /dev/sda nor from sudo blkid /dev/sda1 (looking if BLOCK_SIZE="4096" there) but this polite link suits the purpose perfectly (0b would be the regular choice):

Hex code or alias (type L to list all): `0c`
Changed type of partition 'W95 FAT32 (LBA)' to 'W95 FAT32 (LBA)'.
Command (m for help):

For HPFS/NTFS/exFAT type of partition (07) options are (only one might be choosen/tested), but first please ensure that the target partition is unmounted:
sudo mkfs.exfat -s 4 -n Symbian /dev/sdX1
sudo mkexfatfs -s 4 -n Symbian /dev/sdX1

Second FAT32 approach (related options, -c option will add some time):
sudo mkfs.vfat -F32 -S512 -n SYMBIAN /dev/sdXn −− not the recommended one
sudo mkfs.vfat -c -F32 -S4096 -n SYMBIAN /dev/sdXn −− with the bad blocks check

Third (+others):
sudo mke2fs -t ext2 -b 4k -T news -L SYMBIAN /dev/sdXn
sudo mke2fs -t ext2 -c -T news -L SYMBIAN /dev/sdXn −− bad blocks check requested

Fourth, provide here some feedback on/if any of above formatting options helped you, as well:
sudo apt install exfat-fuse exfat-utils
sudo fsck.exfat /dev/sdXn
sudo blkid /dev/sdXn

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. If Disks is somehow doing proper formatting job for you I do not mind that either.

On my part, format was only a suggestion. It could be any number of things.

I dealt more with multiuser systems than PCs so I try to show analogies from experience:

There was always the “pregnant pause” at noon on my system. We determined it was the partial backup for the China database because THEIR database backup ran at midnight (our Noon). It froze memory for up to 5 minutes to get a snapshot of 5GB what was in memory, because memory use was common and ephemeral) to all databases. The pregant pause also shifted to 11AM for half the year because China doesn’t flip for daylight savings time. Good time for my users to take lunch instead of shipping, but sometimes they were under the pressure to make shipments before the midday truck arrived. There was also consolation in that the Chinese also had the same problem during OUR midnight backup (they also took lunch). The Chinese on our system also learned not to take a break at dinnertime because the European database backup was in their early evening.

Then there was the rare database “DEDLOK” because one sales person was trying to modify a sales order on their screen (like adding a credit) while some other schmuck in shipping was trying to ship it.

There was also the issue of managing database geometry on the disc. It was better keep the key files on a different disc than the detail files. It avoided latency because if the key file was on the same disc as a detail record, the read head had to get the key first, then move itself to find the detail record elsewhere on the same disc the key file referred to. If the key and detail records were on different discs, the read head on the detail file had a head start because it wasn’t just getting away from the key. While the read head on the detail disc was reading the read head on the disc with the key file could do something else.

The last situation should have gone away with SSDs, becase their seek time is radically different than on what we called “spinners”. (Our new nickname for old fashioned hard disc.)

The above being said, other things I can think of causing this problem is either faulty or “inefficient” software of some other business interfering on the CPU.

If you eliminate bad software, traditionally when optimizing a mainframe there were 3 things that were bottlenecks (and in some ways it helps PCs also):


Whatever was causing the bottleneck was usually solved by throwing more money at it. Either to “get more” in the case of memory or “upgrade” in the case of CPU. I/O was a little more tricky as one could either “get more” or “manage it” better.

1 Like

As we are talking here about microSD card within Librem 5 might be that less could easily be better solution (but didn’t get there yet by myself to confirm my earlier thought):

This link: even think that is based on MLC NAND-Type, and they understand things related to SD cards much better than I do. And if some people often throw away their money for capacity rather than for quality, I cannot help there.

For what it’s worth, I had the same issue trying to use Sayonara (which doesn’t scale gracefully in any case). I’ve yet to find a player other than Lollypop which will scale properly (I’m about to try silverjuke).

EDIT. I’m seeing the same random one-second pauses in Silverjuke.

PS I don’t like its user interface either, and it doesn’t scale gracefully. The “Album” view is closest to tolerable, but what I really want is an artist view, that shows you a TEXT list of albums (no space-hogging album art icons, please), which you can then scroll to open the album, then select a track. Album at least sorts by artist then album (a VAST improvement over lollipop which will show you only the album name, no artist–which can be useless when the album name is “Symphony #7”), but the problem is it horizontally scrolls, and the alphabet selector stops at K in portrait mode. Getting to anyone after Mozart (hundreds of albums; I rip each classical work as if it were an album) involves flipping to landscape mode, and sometimes my phone won’t “flip” properly.

I WILL give it props for this: It has a mode where it will play the currently selected song and then STOP. This is something that’s missing from everything else I’ve ever seen. (If I go to the trouble to find an artist, album, and specific track (e.g., track number eight on the album)…it’s unreasonable to assume I want to hear 9, 10 & 11 as well, it may be that I just wanted to play that track for someone, or maybe the rest of the album isn’t nearly as good as that one song. If I had wanted the whole album, I’d have selected the whole album.)

Than you might be the one to answer my question:

I’m afraid that I don’t even understand that question.

I do know my card is the 128 GB card that purism offers as an option when you buy the L5 USA.

1 Like