andrewrk / andrewrk/groovebasin
Syncing multiple daemons
- Dominant language
- JavaScript
- Stars
- 2k
- Forks
- 119
- PR merge metrics
- No merged PRs in 30d
Description
I just discovered groovebasin, and I really like it. I was having problems with MPD not handling replaygain correctly on some tracks, clipping and distorting them really badly. I think it was probably a bug that could be fixed, but GB handles it fine, so I'm giving GB a try as a drop-in replacement. I like that I can use mpc and Cantata and my mobile MPD clients. :)
I have MPD running in two different rooms, and sometimes I use [mpdsync](http://github.com/alphapapa/mpdsync/tree/python-mpd2) to sync them. One of the things I've been fiddling with is trying to keep them playing in sync so that there's no echo effect. With MPD this is hit-and-miss at best: some tracks seek consistently and quickly, while others seem to seek with varying latencies. Also, MPD's buffers are big and its latency is high by design. And it also doesn't seem to report the elapsed track time very consistently. So the result is that it's very hard to sync two MPD daemons, and it seems impossible to do so consistently.
Since GB can be a drop-in replacement for MPD, I tried it with my mpdsync script. At first I noticed that the reported elapsed time was much more consistent, within a few tens of ms every time, instead of jittering by a few hundred ms. But then I noticed that sometimes GB seemed to have strange network latency: sometimes it would only take a few ms to reply, but other times it would take a few hundred ms. I admit I can't be certain yet whether it's GB causing that or something else on the machine, but I haven't noticed this issue with MPD.
Anyway, the whole process of seeking a slave daemon to a master over and over again until they nearly match, and doing so every time the track changes, is not a very clean way to do it, resulting in a lot of audible pops and interruptions in the slaves' audio output.
So I was wondering if you would be interested in considering this as a future feature, to sync multiple daemons over the network. The idea, of course, is that each daemon has its own local, identical copy of the music library. (I guess it doesn't matter whether it's a local copy or a mounted network share, but I use local copies on mine.) I've tried HTTP streaming with MPD (not yet with GB), but it doesn't work well because of the latency.
There's an interesting project and article here: https://snarfed.org/synchronizing_mp3_playback It concludes that to really do it right, you need to have the slaves sync their clocks with the master over the network (NTP-style I guess), and then begin playing a track at the same moment in time, adjusted for local latency.
Maybe that could also be done for seeking within a track (it would seem necessary to support seeking), but sometimes I have wondered if one of the problems is with seeking itself. I don't know how seeking works on the decoder level, but I have wondered if seeking tends to seek to the beginning of frames, and as a result is imprecise at a low level (which wouldn't be noticed except when trying to seek very precisely), and also perhaps seeks with unpredictable latency. If so, maybe GB could use this information when seeking slave daemons, seeking to frames instead of a certain time reference.
Anyway, thanks for groovebasin, and thanks for any thoughts on this idea.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.