RogerBW's Blog

Music for Barbecues 03 May 2019

I've been improving the ways people can get access to the local music server during my barbecues and similar events.

I was already running mpd, the Music Player Daemon, which is a server that separates the process of controlling what's played from the actual production of sound. This is controlled by a pleasantly text-like protocol over a TCP port (there are lots of clients available), and it copes well with cataloguing nearly a million audio files with a total play time of over four years, even if it does insist on calling them "songs" when they might be audio books, radio programmes, sound effects, etc.

I've written a command-line client to do things like switching tracks, clearing the queue, and so on, because it's quicker to type "mp stop" than to load up an interactive program and then tell it what to do. (And I can set a command-line program to run at a particular time – for example, "stop whatever else may be playing, then play the alarm noise".)

The first improvement to the mpd setup was that it had been feeding an icecast2 (streaming MP3) server, but it can now generate an MP3 stream directly. So that's an awkward piece of software removed from the chain (it's intended for more complicated jobs than this one), less buffering, and fewer potential security problems.

Some time ago I write a basic web interface to mpd called yokosou, because all the web-based clients I could find at the time needed dodgy server configuration or PHP (which I regard as a special case of dodgy server configuration). It's designed to be extremely lightweight rather than pretty, but since nobody except me has ever taken advantage of that (e.g. by driving the server from an ebook's basic browser), I've now replaced this with Bragi-MPD on a virtual host, which is more functional and much more pretty.

That client had a secondary function of controlling a daemon to keep the music queue filled, and I've now rewritten that daemon from scratch as a stand-alone program; a particular problem was that, if the daemon had filled the queue, people's requests for particular tracks would be delayed until all those songs had been played. That's been fixed; the new daemon keeps track of which songs it has added to the playlist itself (by using their playlist ID, which should be unique as long as mpd doesn't restart), and if any other songs appear after them, it'll delete them and re-add them at the end. (It also tries to choose songs off its internal playlist that are unlike the ones currently in the queue or recently played, based on similarity of filename.)

And lastly… I've set up multiple channels, which means multiple instances of mpd running on different ports. So I can have a set of speakers by my bed (and I do, driven by a Raspberry Pi) that's not playing the same thing as the main channel (which a guest might be listening to in their room). A small periodic job takes care of restarting the various mpd instances when one of them has updated its database, so that they all run off the most recent data without having to update each one separately. (This is is an interesting exercise in designing program flow: check the last update time for each of them, aborting the process if any of them is currently updating; then restart anything with a last update older than the most recent one, except for ones that are currently playing because you don't want to interrupt the audio stream.)

Now all I need to do is to find a use for "stickers" (a way of attaching persistent data to an audio file, accessible to any mpd client). It seems as though it should be a really useful feature, but…

I've cleaned these tools up a bit and uploaded them to github.

Actually all this started because the MP3 player I was using at the time didn't have a command for "keep playing to the end of the current track, but then stop". If I have some music on while I'm working on something, but then I finish the thing, I don't want to cut the music off in mid-stream… which seems kind of obvious to me but apparently it's not a usual thing to want. Then I got the Touchpad, which could only play MP3 and some proprietary formats, so a streaming server seemed like a good idea…

Comments on this post are now closed. If you have particular grounds for adding a late comment, comment on a more recent post quoting the URL of this one.

Search
Archive
Tags 1920s 1930s 1940s 1950s 1960s 1970s 1980s 1990s 2000s 2010s 3d printing action aeronautics aikakirja anecdote animation anime army astronomy audio audio tech base commerce battletech beer boardgaming bookmonth chain of command children chronicle church of no redeeming virtues cold war comedy computing contemporary cornish smuggler cosmic encounter coup cycling dead of winter doctor who documentary drama driving drone ecchi economics espionage essen 2015 essen 2016 essen 2017 essen 2018 existential risk falklands war fandom fantasy film firefly first world war flash point food garmin drive gazebo geodata gin gurps gurps 101 harpoon historical history horror hugo 2014 hugo 2015 hugo 2016 hugo 2017 hugo 2018 hugo 2019 hugo-nebula reread humour in brief avoid instrumented life kickstarter learn to play leaving earth linux mecha men with beards museum mystery naval non-fiction one for the brow opera perl perl weekly challenge photography podcast politics powers prediction privacy project woolsack pyracantha quantum rail ranting raspberry pi reading reading boardgames social real life restaurant reviews romance rpg a day rpgs science fiction scythe second world war security shipwreck simutrans smartphone south atlantic war squaddies stationery steampunk stuarts suburbia superheroes suspense television the resistance thirsty meeples thriller tin soldier torg toys trailers travel type 26 type 31 type 45 vietnam war war wargaming weather wives and sweethearts writing about writing x-wing young adult
Special All book reviews, All film reviews
Produced by aikakirja v0.1