advertisement


Raspberry Pi as headless streamer

finphil said:
I tried raspyfi but I found that I needed to understand what I was doing - so went back to the standard debian distro.
Click to expand...

Which raspyfi did you use? The latest version with the WEBUI or an earlier one? Did you give feedback to the rapyfi developers about it's shortcomings as you saw them?

thommy said:
Hence my reply and accompanying EDIT ;)

Still it's a project computer not a retail product so if RaspyFi turns out to be a simple plug and play streamer everyone's onto a winner. Quite a few of my friends want what I have but are put off by the fact that it needs to be configured.
Click to expand...

I didn't see your edit. I imagine they would. I've been wondering how you managed to get 24/192 playback working glitch free from the rpi. The USB/ethernet on one bus seems a serious hardware limitation. As is anything that would need sox, as that appears to bog it down at 100% CPU usage.
 
Thanks thommy...will look at the NFS thing. Also wondered if the fact that my pi was one of the early ones might have something to do with it - didn't they tweak it after starting production, or something?
 
There have been various versions of the pi. I've only had Ver. B Rev. 2.0 boards so can't really comment on any of the others. Having said that there's over 300MB of RAM free so a 256 should be able to do audio streaming just as well.

I detailed my tweaks on Bemused's RPi LMS thread (which I can't find now) a couple of months ago. Didn't have to do much to it, just used stock Wheezy image and set up the disk read buffers properly. I'm not sure about sox, wasn't something I've had to touch.
 
PegLeg said:
Which raspyfi did you use? The latest version with the WEBUI or an earlier one? Did you give feedback to the rapyfi developers about it's shortcomings as you saw them?

I used the earlier version without a web ui. I never said there were any shortcomings. I made a personal choice that I had to learn about config files and so on. Each to his own.
Click to expand...
 
finphil said:
PegLeg said:
Which raspyfi did you use? The latest version with the WEBUI or an earlier one? Did you give feedback to the rapyfi developers about it's shortcomings as you saw them?

I used the earlier version without a web ui. I never said there were any shortcomings. I made a personal choice that I had to learn about config files and so on. Each to his own.
Click to expand...

This is always the trade off between the pre-packaged system ( which in the case of RaspyFi is at least open source) and self install and configure. The latter would be my personal choice too. That's why I spent a few hours looking at the content of the latest RaspyFi image and lifted their WEBGUI for my own use on a standard Linux desktop.

thommy said:
I detailed my tweaks on Bemused's RPi LMS thread (which I can't find now) a couple of months ago. Didn't have to do much to it, just used stock Wheezy image and set up the disk read buffers properly. I'm not sure about sox, wasn't something I've had to touch.
Click to expand...

I'll have to look for that. I did make a few contribs to one of Bemused threads about using a beaglebone black. I don't really have a pressing need for such a device, so I'm still dithering between Rpi, BBB, and o2 joggler.
Click to expand...
 
The USB bandwidth isn't a limitation. Consider that even a 24/192 file only has a data rate of about 6mbit/s, sending that both ways at the same time is 12mbit/s. No sweat for a 100mbit interface. In fact mine runs a torrent client at the same time and allows for remote control via ethernet.

The issue is the read block size. Stuttering occurs when the data can't be read and written fast enough, i.e. if it's "biting off more than it can chew" in one go. If the problem persists with a USB hard drive, it will be because the block size with which the drive was formatted (amount of data read in one go) is too high. I formatted my drive with a small block of 1024 bytes and have perfect playback.

So basically give it smaller bite sized pieces so that it can "chew and swallow" fast enough to feed the data smoothly on into the USB DAC.

This is the one thing that I haven't seen mentioned on a single Pi based music server thread anywhere, and it's fundamental.
 
Thanks thommy I had to reread this a few times before I got it, and also check back on the other thread - I was being dense. I thought you were on about fstab - but its the drive format as you say. In my case I just checked and the drive reports physical sector size as 4096:

sudo hdparm -I /dev/sda |grep siz
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytes
device size with M = 1024*1024: 953869 MBytes
device size with M = 1000*1000: 1000204 MBytes (1000 GB)
cache/buffer size = 8192 KBytes

So it looks like a reformat is needed....But if you are right - and I guess you are - this is the cause of the stutter I experienced on playback. I imagine it will help server performance too. Amazed I didn't catch this on any other thread on this topic, and I have read a few - thanks :)
 
Having slept on this I am not sure how you go about setting the read block size - any tips? I use gparted and ext4 and I cannot see how you go about this.
 
finphil said:
Having slept on this I am not sure how you go about setting the read block size - any tips? I use gparted and ext4 and I cannot see how you go about this.
Click to expand...

You need the -b option in mkfs.ext4

from 'man mkfs.ext4' :

-b block-size
Specify the size of blocks in bytes. Valid block-size values are 1024, 2048 and 4096 bytes per block. If omitted, block-size is heuristically determined by the filesystem size and the expected usage of the filesystem..
Click to expand...
 
I believe the "block size " mentioned by thommy is a characteristic of the filesystem used, and not the underlying disk hardware. In Linux hdparm is showing your hdd characteristic. To get the fs block size, use something like:

dumpe2fs -h /dev/sdax | grep "Block size"

where x is the partition your interested in. This value may, or may not, be the same as the drive's physical sector size as reported by hdparm.

IIRC gparted does not provide a means to set the block size when formatting a partition. The CLI program mkfs.ext4 does.

e.g. mkfs.ext4 -b 1024 /dev/sda2

You could use gparted to first set up any partitions and then use mkfs.ext4 to format them. Or simply do it all at the CLI by using a combo of fdisk and mkfs.ext4. If you just want to reformat an existing partition then you only need to use mkfs.ext4.

Edit: I'm as slow as my internet connection this morning.
 
Thanks guys, I confirmed the fs block size is indeed 4096 using dumpe2fs.

I also just practised on an old usb stick. Gparted formats to ext4 by default with a block size of 4096 - I don't think there is an option in the gui to change this. Using mkfs.ext4 I could reset it to 1024 as suggested.
 
It's also known as cluster size sometimes, and is created upon the formatting of the partition, rather than the creation of the filesystem on that disk.
 
Learned something new today with this. Now backing up the data so it will be a while before I can test again with mpd.

Incidentally, would resetting the block size like this benefit video file performance on the pi as well?
 
I doubt it would improve things much as the audio track on video files is usually 48khz, and the HDMI port is not sharing the USB bus so that bottleneck won't apply.

Video stuttering is more down to the CPU overhead decoding the video, and the efficency of related codecs. I bought a Cubieboard2 for AV duties, twice the pi in every way (price, memory, cpu) and that works just fine for video without any tweaks.
 
Thanks, I thought so. I was also looking at the new Cubox now that the DIY bug has bitten. I would love to replace my home made htpc with something smaller and less power hungry.

Are you using Cubieboard2 as a server or player? My ideal would be to have a device sitting behind the TV so it can output directly over HDMI, controllable from Android, and also serving the video over dlna or something to other android tablets etc.
 
I hadn't realised NewIT were selling the Cubieboard2 in the UK - 2 USB host ports + 1 USB OTG and Realtec 8201CP MII PHY chip and SATA etc. Have you made use of the SATA port? Did you use "berryboot" to get Debian on it?
 
Update:

Playback stutter seems to be cured. Playback chain is USB hard drive -> pi -> usb dac -> headphones. (Flac files). So far no pausing and it passed my gapless test (DSOTM). Only issue is the client seems to crash a bit too often :) but will work on that.

Thanks guys.
 
Nice to have +ve feedback.

Out of interest, are you using a powered USB hub? What DAC are using? What is the client that is crashing?
 
PegLeg said:
I hadn't realised NewIT were selling the Cubieboard2 in the UK - 2 USB host ports + 1 USB OTG and Realtec 8201CP MII PHY chip and SATA etc. Have you made use of the SATA port? Did you use "berryboot" to get Debian on it?
Click to expand...

I got mine from the supplier in HK, for £43 posted. Using SATA with a 2TB drive. No issues with audio at any point, would get another one for the hifi but the pi is doing the job just fine thankyou very much :)

Can't remember what I did to get Debian on it, but am using the 4GB internal flash for the OS, and the drive just stores all the data.
 
You must log in or register to reply here.


advertisement


Back
Top