On 2019-01-24, The Natural Philosopher  wrote:
>
> 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.

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.

> 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...

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...

> 2/. Should I use apache or run on something smaller?

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.

> 3/. Is a Pi Zero/W man enough to stream audio without stuttering (it
> surely must 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.

> 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?

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.

> 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?

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

--- SoupGate-Win32 v1.05