reply


On 24/01/2019 11:33, Andrew Smallshaw wrote:
> 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.
>


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

--- SoupGate-Win32 v1.05