USB flash or HDD storage?

speed is not an issue frankly

HDD still more storage for yer dollar And a little more power consumption

--
The lifetime of any political organisation is about three years before  
its been subverted by the people it tried to warn you about. 

Anon.

Amplifying: even with 4 channel surround-sound and uncompressed WAV, the audio data rate is 2.8 Mb/s (assuming CD-quality - 44.1 KHz sample rate,

16 bits per sample for each channel). In computing terms that is only 0.35 MB/s - miniscule compared with the speed of SD cards (12.5 MB/s min), USB2.0 (35 MB/S for USB2) or SATA SSD or hard drives (150 MB/s min).

A more important consideration: how much storage does your audio collection need? If less than 120 GB, a single 128GB SD card should hold both the RPI software and your music. This is the simplest approach, but

Above that size you'll need to use a SATA SSD or hard drive, so add on the cost of a USB-SATA adapter and enclosure.

A quick glance shows that 120GB SATA SSD drives start at about the same price as SD cards while 320 GB hard drives (the smallest generally available) are under half that cost.

--
Martin    | martin at 
Gregorie  | gregorie dot org

Granted, an SD card looks like it should be able to outperform any demands made of it by a music player, but in practice, having the music files stored on the SD card (that the Pi booted from) didn't work well at all.

I don't know why, but it struggled to keep it playing smoothly.

Daniele

I use Volumio on my PiZero and have all my music on my local network server. The server is then linked to Volumio by it's network settings

Some classes of card give poor performance, though that may well be related to fragmentation. Don't forget that SD cards were designed for large reads and writes (still images, videos...) and not for the type of random access needed for good Linux filing system performance, and this is probably exaggerated by the RPi's relatively small RAM, which reduces its ability to cache data. But, if it doesn't work for you, fair enough.

Bear mind that the USB and Ethernet are relatively slow on an RPi because all connect through the same USB hub, though if streamed output doesn't go near these connections this may not be a problem, i.e. you're using HDMI or a 3rd party DAC on an expansion card, this should not be a problem.

If you have a USB-SD card reader it may be worth moving some music onto another SD card and, connecting it via the card reader to see if that also stutters. If it does not, then using a second SD card becomes a possibility to compare with SSD and HDD solutions or simply keeping the music files on a house server / NAS box (if you have one) on cost grounds.

--
Martin    | martin at 
Gregorie  | gregorie dot org

d t

I wouldn't use a single 128GB SD card, too much risk of it becoming corrupted, and then you've got to copy a new OS image and all the data back on to it, which for even a fast SD card is going to take hours.

Instead use a normal 8GB or 16GB SD card for the OS, and put all the data on a USB3 pen drive, which can be mounted as read only. USB3 is no advantage over USB2 in the Pi, but it will be hell of a lot quicker to copy the music to it from a PC.

If it was data which is likely to be written to, I'd also recommend a small SSD. But I'm assuming a music collection will be largely written in one go, and occasionally added to.

---druck

... in which case, a backup is the obvious answer - for all types of storage and regardless of whether the IP uses one storage volume or two.

First backup will take hours, but if the OP uses something moderately clever for doing backups, i.e. rsync, then subsequent backups will be quick. Provided he does reasonably frequent backups then little or nothing will be lost and recovery from a failed SD card/SSD/HDD will take no longer than unplugging the dead one and replacing it with the latest backup.

Followed by making a replacement backup - of course! But that should run OK overnight or as a background process.

--
Martin    | martin at 
Gregorie  | gregorie dot org

I should have added that, if I wanted a bootable backup, I'd do the initial backup with dd, check that it booted successfully, and then do all subsequent ones with rsync.

--
Martin    | martin at 
Gregorie  | gregorie dot org

ld

ut

Personally I'd keep the OS and media library on different drives. Makes switching OS or upgrading far less painless.

I have Pi 2 running Kodi, so mostly HD video streams rather than tiddly little audio ones. The library is stored a 2 GByte USB3 portable hardrive. Not a problem playing back. Finding a PSU that has the grunt to meet the demands of the Pi booting and the HD spining up was the tricky bit, needs about 3.5 A. The GUI is a bit slow on a Pi2, one day I'll try the Pi3+ I have.

--
Cheers 
Dave.

I think the real solution was the WD pidrive package - usb3 drive with adequate power supply. Unfortunately, they seem to have discontinued it.

Fair comment. I was thinking more of minimal cost, at least until the OP decides how he wants to organise his system, than anything else.

FWIW all my (linux) systems are using single drives, but with a nonstandard partitioning scheme that puts everything I really want to back up in one partition and the rest in another three.

--
Martin    | martin at 
Gregorie  | gregorie dot org

I've had Kodi/OSMC running on B+, 3 and 3+. Believe me, switching to the

3+ was really worth it. 2x DVB-T, 1x DVB-T2 and 1x 5Tb Seagate Expansion Drive. Plus it runs DNSMasq, Lighttpd (was Apache, but I didn't need the power of Apache). Standard RPi power supply.

--

Chris Elvidge, England

On Sun, 3 Jun 2018 16:29:33 +0000 (UTC), Martin Gregorie declaimed the following:

Classes 2/4/6 are based upon I/O on fragmented file systems as would be found on still image cameras (small files with random deletions by the user). Class 10 is based upon streaming a single video file on a freshly formatted card. Though also take into account that the standard format for SD cards is FAT/exFAT -- not a journaling system.

As a result, a Class 10 card could have atrocious behavior when working with multiple small files. If the file system is read-only, it may not be that noticeable, but if the file system is undergoing updates (log files, configuration files [current play list position?]) then a card that handles, say, 2 allocation units at a time will be doing a lot of closing/opening/copying/erasing of data from allocation unit to allocation unit -- whereas a card that can handle around 6 allocation units at once may not need to do rewrites, but can buffer changes to multiple files for later flushing.

I really should have bookmarked the article about this...

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

would be

working

I, for one, would appreciate your posting a link to the article if you can find it again. Relying on Wikipedia and the tattered remnants of my memory doesn't cut it.

--
Martin    | martin at 
Gregorie  | gregorie dot org

On Thu, 7 Jun 2018 22:13:32 +0000 (UTC), Martin Gregorie declaimed the following:

Presuming the links are still good, from my archived post of March 2016 (Arduino forum). Obviously the reports are a bit dated when it comes to currently marketed cards, but the general information is still useful.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/