RFC on Pi/Hat type for audio application.

Ok. My 'lets connect some hifi gear to the network' project is picking up pace.

At this stage I want a cheap solution, so this is as far as I have got.

What the PI has to do: =====================

- Boot headless.

- Connect to the house network by wifi on a fixed IP address

- Mount some drives via NFS

- Start a minimal web server as control panel for...

- Reading audio files off the internet (radio stations) or the server. and spit them out of a high quality DAC. RCA jacks to a rack mounted preamp + power amp.

Files will be MP3 and FLAC - will use mpg123 for the MP3 and flac to pop the flac files out.

I will PROBABLY code the website in actual real C for low CPU cycles and memory, though it might be PHP.

What looks like a sensible option is a Pi ZERO W with a pHAT DAC (HifiBerry DAC+ Zero)

Questions: ==========

1/. Is 512MB RAM enough to run the most minimal of web servers headless? I did run apache on 384M on *86, but I sometimes went into swap... 2/. Should I use apache or run on something smaller? 3/. Is a Pi Zero/W man enough to stream audio without stuttering (it surely must be?). 4/. In order to bootstrap the install without a monitor or keyboard (I COULD use Ethernet, for initial booting), I would like feedback on whether the following method would work to get 'up and running'? (a) format and install raspian on an SD card using SD USB adapter on host computer (b) Whilst still attached to the host computer, edit the config files to set up ssh access, wirless networking and a fixed IP address. That is, enough to get an accessible bootable headless pi on the network in a 'well known' place? 5/. Apart from logging issues, I see no real reson why the SD card ever will need to be written to in use, unless I need swap. Has anyone ever tried running a Pi with what amounts to a read only mounted root partition? Can one disable logging?

Hope these questions are intersting to the community.

--
The biggest threat to humanity comes from socialism, which has utterly  
diverted our attention away from what really matters to our existential  
survival, to indulging in navel gazing and faux moral investigations  
into what the world ought to be, whilst we fail utterly to deal with  
what it actually is.

Personally I wouldn't bother. The high level scripting langauges will go together twenty times faster for something like this especially compared to C where string handling is fairly primitive and the system load will still be fairly trivial. I assume of course you are offloading actual playback to standard software rather than rolling your own within the CGI software.

For your use case I would think it'll be fine. X and especially modern desktop environments use a decent chunk of memory by themselves and they're not needed here. It doesn't sound like you'll be running general apps on the system either, i.e. no Firefox, VLC etc...

I'd make that working assumption in the first instance. If you need something lighter there's always the likes of thttpd which I've used in the past: if it had better support for PHP it's probably still be my default web server. However, like I said I'd start with Apache first if that is what is familiar, no point optimising that kind of thing prematurely when it is easy enough to swap later if need be.

Yes, I'd have no concerns about that at all. I'd prefer a wired connection but wouldn't expect problems with even a half-decent wifi signal. It was doing something vaguely similar to this twenty years ago on a 486, MP3 decoding was the most demanding aspect and amounted to around 30% CPU even on that.

In principle yes, and I have done things like this in the past. In my experience it's always useful to have some form of console access (either a serial console or hooking up a monitor temporarily) in the first instance though, it saves a lot of head scratching if things don't work first time.

Yes, be prepared for a lot of tinkering though. I've done this on NetBSD with a slightly different aim (creating a stateless thin client image) and I could send over notes to give you something to thing about but doubtless there are more focussed write ups already on the net. Typically you'll begin by paring down services to the minimum you actually need and then identifying where those will write to in normal operation. Then mount a smallish RAM disk on tmp and symlink those locations to subdirectories - you may be to copy over an initial set of files on boot.

Disabling syslog is easy enough but any random apps that do their own logging will need handling separately. When I was doing this I didn't really bother since the terminals would get powered off at the end of the day, resetting the logs. That may be an option to consider if scheduling a reboot e.g. overnight would be acceptable to you.

--
Andrew Smallshaw 
andrews@sdf.org

Don't bother with NFT connections from the Pi. Just run Logitech Media Server (LMS) on your server and have it stream your music to the RPi.

- support is here:

- downloads here:

LMS is a Perl application that streams music from local disks and has plugins that can stream internet radio. It presents a web interface on port 9000, so you only need to run a web browser and a suitable program for driving the DAC on you RPi. Works just great with FLAC (and MP3 if you must) music files.

I'm running LMC and Apache under Fedora 28 on a 4GB dual Athlon PC. Apache is my main home web server so its convenient to put a link to LMS on one of its web pages.

Others can give details of what to run on the RPi - I would have suggested VLC or Mplayer, but there don't seem to be any RPi ports.

Instead I use a Logitech Touch (there are several on eBay for under

system over a lineout link. The Touch can also stream directly from the internet. It has both a touch screen and a remote controller. Mine is connected to my wired home network, but they support ethernet, wifi and USB connections.

--
Martin    | martin at 
Gregorie  | gregorie dot org

Andrew: Thank you. Top posted so there is no need to read the excellent reply

--
"I am inclined to tell the truth and dislike people who lie consistently. 
This makes me unfit for the company of people of a Left persuasion, and  
all women"

I'd disagree. It really does depend on how much use (number of concurrent sessions etc) is being made of the services. I run a a Pi3B as a home server that serves DNS, DHCP, imap, smtp, NFS, web, ntp, syslog-server, ssh, openvpn for our, small, home network - and does some backup stuff. And it doesn't have swap and runs for months and months and never crashes.

I'd say go for it with a pi W Zero, but watch what happens - and if it is struggling, then try a 3B. But my guess is you'll be fine.

On Thu, 24 Jan 2019 09:45:59 +0000, The Natural Philosopher declaimed the following:

What features does the web-site need? You might be able to use something like FLASK (fairly lightweight) or DJANGO (heavier) to code the site application (both are Python-based). If the unit is only for internal usage, and relatively low traffic, you might even be able to run using the "development server" (heavy traffic deployments tend to use nginx (sp?) and/or apache.

Not with a Windows box, at least... Most if not all of the config files will be on an EXT# partition, and Windows can not see such (the NOOBS installer starts on a FAT partition, but during install converts the rest of the SD card to EXT2/EXT3/EXT4 [I've not kept track of what the current common variation is]).

Suspect it may be easier to connect to a local router, SSH in to make configuration changes, then move the unit to the final location.

Pi-Star

runs in just that mode (logging goes to a "ram disk" temp filesystem, and gets rotated periodically).

{USE FIXED WIDTH TO VIEW} pi-star@pi-star-3b(ro):~$ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 15213412 2447856 12111872 17% / devtmpfs 492508 0 492508 0% /dev tmpfs 497116 0 497116 0% /dev/shm tmpfs 16384 13104 3280 80% /run tmpfs 5120 4 5116 1% /run/lock tmpfs 497116 0 497116 0% /sys/fs/cgroup tmpfs 4096 2176 1920 54% /var/lib/samba/private tmpfs 1024 464 560 46% /var/cache/samba tmpfs 64 0 64 0% /var/lib/php5/sessions tmpfs 1024 0 1024 0% /var/lib/nginx/body tmpfs 16 4 12 25% /var/lib/ntp tmpfs 16 4 12 25% /var/lib/logrotate tmpfs 16 0 16 0% /var/lib/dhcp tmpfs 16 0 16 0% /var/lib/sudo tmpfs 16 4 12 25% /var/lib/dhcpcd5 tmpfs 65536 15252 50284 24% /var/log tmpfs 65536 8 65528 1% /tmp tmpfs 16384 0 16384 0% /var/tmp /dev/mmcblk0p1 64456 22312 42144 35% /boot pi-star@pi-star-3b(ro):~$ pi-star@pi-star-3b(ro):~$ ls /var/log apt daemon.log.1 kern.log mail.log.1 php5-fpm.log unattended-upgrades auth.log daemon.log.2.gz kern.log.1 mail.warn php5-fpm.log.1 wtmp auth.log.1 debug mail.err mail.warn.1 pi-star wtmp.1.gz boot.log debug.1 mail.err.1 messages samba btmp dpkg.log mail.info messages.1 syslog btmp.1.gz dpkg.log.1 mail.info.1 messages.2.gz syslog.1 daemon.log exim4 mail.log nginx syslog.2.gz pi-star@pi-star-3b(ro):~$

Of course, this does mean that if one needs to review the logs, one will need to SSH into the running system -- can't shutdown and move it to someplace to examine it as the logs will be lost.

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

?

Yes, as long as we aren't talking more than a few dozen simultaneous clients.

I prefer nginx, it's better on the single core machines as it doesn't create threads for each clients.

Well my Pi-0W is up to streaming Pi Camera video from an nginx web server, so audio should be OK.

sing

, edit the

working

headless pi

That's what I do.

ed swap.

If all the pages are static, there shouldn't be any writes, but if they are generated by scripts, their will be.

s to a read only

It has been done, but I've always kept a minimal amount of logging, to be able to diagnose any problems.

---druck

Yep. I think I will be.

there is so little running at all.

--
Climate Change: Socialism wearing a lab coat.

No windo9ws in here m8!

Linux all the way.

Wasnt gonna use noobs anyway. Just dd the raspian image onto the SD

Well if I have to I have to..

I could copy them to the network server..

--
Climate Change: Socialism wearing a lab coat.

On Thu, 24 Jan 2019 20:19:12 +0000, The Natural Philosopher declaimed the following:

Which still presupposes a network connection and SSH to get to the unit.

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

The Natural Philosopher wrote, on 24-01-2019 10:45:

This works fine on a 1B or ZeroW, with Lighttpd or even Apache:

(not much setup documentation, sorry).

My idea was to make an internet radio player, so only tailored to play streams not local files. Could easily extend but I haven't bothered. I never used mpg123 so I can't compare but mpd is great and controlling it with mpc over the (local) network is also great. This is without a DAC, just directly plugged in to an AV receiver via hdmi, because also occasionally used to play videos on the attached TV.

This is way out of date, I'm afraid, especially the AirTunes section, I think:

This is my mini-mini setup directions text file for the Pi:

/boot/config.txt disable_overscan=1 hdmi_force_hotplug=1 hdmi_ignore_edid=0xa5000080 hdmi_group=1 hdmi_mode=31 hdmi_drive=2 dtparam=i2c_arm=on dtparam=spi=on dtparam=audio=on dtoverlay=pi3-disable-bt audio_pwm_mode=2 apt-get install mpc mpd shairport-sync omxplayer mplayer2 youtube-dl streamripper alsa-tools lighttpd php7.0-cgi apache2-utils at bc imagemagick ffmpeg /usr/local/bin

/etc/rc.local radiocontrols.py & /var/www/html sudo visudo www-data ALL=(ALL) NOPASSWD: /usr/bin/at, /usr/bin/amixer, /sbin/shutdown sudo adduser mpd audio sudo adduser www-data audio /etc/mpd.conf music_directory "/home/pi/Music" user "mpd" group "audio" bind_to_address "any" zeroconf_enabled "yes" zeroconf_name "MPD RPi" /home/pi

Thanks for that...but I am committed to rolling my own. Why? Isn't that what the PI is for?

--
"I am inclined to tell the truth and dislike people who lie consistently. 
This makes me unfit for the company of people of a Left persuasion, and  
all women"

no. It presumes cron and a network. Or syslogd and a network.

"This syslogd(8) provides full remote logging, i.e. is able to send messages to a remote host running syslogd(8) and to receive messages from remote hosts. The remote host won't forward the message again, it will just log them locally. To forward messages to another host, prepend the hostname with the at sign (''@'').

Using this feature you're able to control all syslog messages on one host, if all other machines will log remotely to that. This tears down administration needs. "

--
"I am inclined to tell the truth and dislike people who lie consistently. 
This makes me unfit for the company of people of a Left persuasion, and  
all women"

Of course, that's what I did as well. Wasn't meant to be "copy this" at all, but maybe there were some ideas there you could use. E.g. It took me a while to figure out that & how I needed to use visudo.

Ah well.

I am sketching the software architecture out in my head...realised I can talk with spawned daemons using tmpfs stuff so that saves a LOT of messing around.

Still going to be some dirty low level C system hackery to get the thing to work the way I want though.

--
?It is dangerous to be right in matters on which the established  
authorities are wrong.? 

? Voltaire, The Age of Louis XIV