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.
EDIT
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. 
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 opensuse.org 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):
Memory
I/O
CPU
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.
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: https://de.rs-online.com/web/p/micro-sd-karten/2034767 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.
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.
@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:
/dev/sda1:
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.
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
exit
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.
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.