MPD?

[Joshua Judson Rosen]

Derek Atkins <warlord at MIT.EDU> writes:
> Joshua Judson Rosen <rozzin at geekspace.com> writes:
> >
> > I've setup multicast RTP with latency-matching across all nodes
> > in the network; I have only one `channel' right now (in the radio-tuner
> > or input-switching sense, not in the `mono vs. stereo' sense), but it's
> > possible to define multiple channels/sources by giving them separate
> > multicast addresses, and then switch a given receiver to another channel
> > just by changing the multicast address on which that receiver listens.
> >
> > Because of the latency-matching, multiple receiver-nodes, to the
> > extent that the ear can tell, all have their playback perfectly
> > *time-synced* such that there's no `echo' or `reverb' effect
> > when standing between two adjacent rooms with separate receivers.
> >
> > I actually compared this against how well two (different) FM radios
> > in adjacent rooms sync to the same radio station, and the RTP system
> > did better. :)
> >
> > (multicast RTP over ethernet + dynamic resampling-algorithms
> >  with latency-analysis on pentium-class CPUs with network time-sync...
> >  provides quite a convincing emulation of speaker-wire!)
> >
> > That it's MPD-based means that I can have a single playback- and
> > playlist-control server for the entire house, accessible from anywhere
> > on the network; in other words, I have multiple `single points of control'--
> > client UIs are available for desktop and laptop computers of all OSes,
> > Android devices, my friends' Apple iThings, etc. There's even
> > a central volume-control.
> >
> > Using MPD *also* means that I can use all of the tools/plugins that exist
> > for MPD--like last.fm/audioscrobbler support, gmpc, and the `mpdjay'
> > autojockey that I'm now running on my NanoNote (actually, I originally
> > wrote that to deploy in the whole-house system, and it didn't even occur
> > to me that I could run it on the NanoNote until my wife said, `OMG it's
> > so awesome! Can you make me a portable version‽'). And MPD does gapless
> > playback, with ReplayGain to automatically adjust for differences
> > in overall volume between different tracks/albums, etc.
> 
> Okay, I'll bite...
> 
> Could you give more details on how you set this up?  I'd not heard of
> MPD until this email, so I just looked it up.  It certainly exists in
> Fedora 12 (my current desktop -- yeah, yeah, I know) and from my minimal
> reading it sounds pretty cool.
> 
> What I'm more interested in learning about is how you set up MPD to
> perform your multiple room synchronization, what clients you use, and
> how/where you store your music and playlists on the network?

Sure.

MPD manages playlists on the server--it can be told by the clients
to load them, and also to create and store new ones. We generally
run GMPC on our desktop/laptop systems, though sometimes I like
ncmpc for its keyboard-friendly nature (and it's what I run
on my NanoNote..., but that's mostly another story).

MPD runs on the machine hosting all of the audio-files
(along with my mpdjay script, and GJay--and hopefully
 some other modules for auxiliary smarts, soon) which is
setup as an RTP *sender* and without any local speakers.

All of the actual `audio output' is done on receiver-nodes
elsewhere on the network.

In /etc/mpd.conf, I tell it to use PulseAudio for output with
a stanza like:

    audio_output {
            type            "pulse"
            name            "MPD Stream"
            sink            "rtp"
            description     "what's playing on the stereo"
            mixer_type      "software"
    }

... where "rtp" is the name of a sink defined in /etc/pulse/default.pa via:

    load-module module-null-sink sink_name=rtp format=s16be channels=2 rate=44100 description="RTP Multicast Sink"
    load-module module-rtp-send source=rtp.monitor


Keep all of the system clocks tightly synchronised so that PulseAudio
can actually determine the network latency (by comparing the source
timestamp on the RTP packets to the system time on the receiver), and
then it's just a matter of also running Pulseaudio on the other hosts--
but with those PulseAudio instances setup as *receivers*, which can
be done in the respective /etc/pulseaudio/default.pa files with...:

    load-module module-rtp-recv

... or, if you have a GUI running on the receiver machine(s), you can
just toggle-on the `enable Multicast/RTP receiver' setting in paprefs.


Except..., it actually turns out to be a little more complicated,
because:

    - PulseAudio defaults to doing something clever that *should*
      make playback better (look up "glitch-free audio") but which,
      as I understand it, tends to trigger bugs in ALSA; so any
      "load-module module-udev-detect" directives in default.pa may
      need to be modified to be "load-module module-udev-detect tsched=0"
      on each host.

    - There were major problems in PulseAudio's latency-matching code
      that weren't resolved until this past January; so you want
      PulseAudio 0.9.23, but it doesn't actually exist yet....
      On Debian 6.0, I just grabbed src/modules/rtp/module-rtp-recv.c
      from git and spliced it into the version of PulseAudio that Debian
      already had (there were a couple of minor wrinkles, there, that I
      needed to smooth out--nothing hard, though). Figuring out that
      this module was buggy and needed to be updated was probably
      the biggest problem that I ran into.


I installed ptpd for super-accurate clock-sync between hosts, though ntpd
would probably be sufficient. Not sure--I haven't got around to
trying to run this with NTP in stead of PTP.

I also installed rtkit, which PulseAudio can use to get realtime scheduling
(in Debian, I had to get this from Wheezy/testing; it installed fine
on 6.0/Squeeze, though).

If your RTP-broadcasting machine has multiple network interfaces,
make sure you're routing the multicast packets out over the correct one--
I did run into a problem with that :)

Oh--the system does hiccough when the hosts go through DHCP cycles,
so you'll want to find a way of setting your network up such that
your audio-system doesn't decide to renew its DHCP leases
in the middle of a party... ;)

-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."