Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Matt]

Hi everyone,

We'd like to improve the zone sync experience, but we're not exactly sure where it's falling down for people.

We recently added the "Adjust Link Timing" dialog.  That allows adjusting the timing and also the playback rate.

Where does this system fail for you?  And even better, what can we do about it?

Thanks.

[blgentry]

Zone Sync across a local sound device and a DLNA device is essentially unusable.  I just tested it again and got essentially perfect sync until the first song change.  Then the timing was offset.  You can't adjust the offset if it changes every song.

I've had similar issues trying to do Zone Sync across two different local sound devices.  Sync will drift over time making them out of time.  I don't think you can adjust that either, but maybe with the right playback rate change.  Right now I don't have a compelling need for it right here, but I have several friends that want to do this with JRiver.  Because of the current limitations I'm advising them all to use single multi-channel sound cards, since those share a clock.  The rub, of course, is having to physically run RCA cables to every location where they want sound.  Kind of a big job in some of these houses.

What can you do about it?  I don't know how it all works, so I'm not sure.  Other than knowing that the lack of a clocking standard seems to be the issue.  I know AndrewFG has a white paper he wrote about DLNA sync.  I don't think that's going to help sync across local devices though.

It's nice to know that you guys are interested in this.  One of the "big wins" for a system like Sonos (where they control everything) is that everything is synced with no effort.  This sets Sonos apart from JRiver for the class of people that want that functionality and are happy with Sonos level sound quality.

Brian.

[JimH]

I believe that Sonos syncs all devices on every track change.  Would that work?  It means gapless might not work well.

[mwillems]

I believe that Sonos syncs all devices on every track change.  Would that work?  It means gapless might not work well.

I think, at least in some configurations, JRiver already does this.  When I play to two linked JRiver instances, they resync at the start of each track and then drift out of phase as the track goes on.  This means that one of the players stops for a second or so at the end of each track, so gapless already isn't ideal in that scenario.  Linking local and remote zones is even weirder with occasional track decoupling (both playing different tracks). Trying to skip forward a track (especially a few at a time) is a quick way to produce undesirable behavior.

As Brian noted, the sync difference is variable, so there's no way to just "dial it in."  I think some kind of automated syncing approach is needed.

I think something along the lines of Andrew's proposed approach with a master clock would be worth exploring.  Especially in the case of MC to MC linking you have complete control of the renderer and controller, and since the client server model already has a server as the hub, the server could easily host the master clock.  It would be somewhat less robust with non-MC renderers, but there's only so much you can do with them. Having sync work perfectly in an all MC ecosystem would actually be a selling point for Id's or JRiver licenses generally.

A less robust approach (which wouldn't work with most non-MC DLNA renderers) would be something like RTP multicasting: https://en.wikipedia.org/wiki/Real-time_Transport_Protocol.  The controller puts out the equivalent of a webstream and the clients "tune in."  That would solve variable sync issues more or less as clients are receiving audio at a fixed rate, and you'd only have to solve the initial sync problem. That would be another possible technical approach assuming you can deal with some of the wifi-packet-flood issues associated with some RTP implementations.

[drmimosa]

Matt, JRiver sync has gotten a lot better. I just tested it and two zones were playing in sync no problem. It used to drift and lose sync quickly over time.

That said, I use Tuneblade for multi room audio. Any time there is a drift of more than a few milliseconds it is corrected automatically. No need for any adjustments for link timing. It's just set and forget. It almost never drifts audibly, and when it does you can fix it with one or two mouse clicks (basically turn a zone on and off).

The last time I set up JRiver Sync I had to manually adjust three DLNA clients, and then the next day the audio sync was different and I had to change the numbers again. 10 minutes of adjustment each use isn't fun!

Plus, Tuneblade's audio capture and broadcast is very versatile. My Tuneblade system accepts audio capture from JRiver, Pandora, Spotify, or even Vinyl records via a sound card input. It then spits out synced audio to any source with airplay capabilities, which includes Apple Airports, Rasb Pi, and PC programs like Tuneaero.

Check out Hilton's thread on Audio Sync for another Tuneblade based system. http://yabb.jriver.com/interact/index.php?topic=95760.0

A JRiver set and forget audio clock based sync would be a good start, simply because it's available as a market standard for multi room audio. Multi source capture and broadcast through the JRiver windows driver could be another great use, then JRiver sync would match Tuneblade's capabilities.

Thanks!

[ssands]

I have Sonos at home and wanted to use JRiver to transcode and stream my hi-res music to the Sonos system. I didn't use the "Adjust Link Timing" parameter because it seemed to be too trial and error. Plus, there are times when we want to play to 3 or more rooms simultaneously and that just multiplies the hassle.
I just don't have the time to mess with that. Not when I can click on Sonos and have it play.
The sad work-around is to transcode material ahead of time that I want to play over sonos, but removes any immediacy of wanting to hear something I haven't transcoded. It's also consumes disk space (as I'll keep the hi-res for computer and stereo).
Thus, introducing my son to new music is typically predicated with "Sorry I can't play that on Sonos yet".
I can't offer any technical suggestions, as that is not my area of expertise, but I'm happy to beta test over a multi-room Sonos system if that will help.

[dtc]

My problem has been with client/server (Tremote) syncing.  The Adjust Link Timing helped, but the two systems still drift over time. I have pretty much given up trying to sync them exactly.  From what I have read two zones on the same computer seem to sync pretty well,, but whenever their are two systems and a network involved (like Tremote or DLNA), the syncing breaks down.

If I remember correctly, I think I have read that Sonus does the sync well, but the data may not be bit perfect when they do that. I do not know the details, but I doubt anyone can tell whether it is bit perfect or not. Some Sonus experts may know more.

[Hilton]

Everything has pretty much been said already.

Since you guys like open standards the DLNA sync play option I think is the best option for the MC eco system as well as other playback systems that might, over time, include this feature.

Building your own standard seems like a waste, so the only other option is to implement another widely adopted standard, AirPlay, or license TuneBlade as a server and client module and build it into zones as an option for sync play with their APIs. 

Obviously much more work to be done either way you look at it, however AirPlay is already robust and works very well and there's no precedent or proof that DLNA sync will actually work at all.

If your prepared to invest in DLNA sync and keep at it till it works great, otherwise I'd license TuneBlade and make it an add-on license and module. They seem to have a good model and attitude with quite functional software. The API is available and works - I've played with it and got it doing basic stuff already.   I'd pay extra for it as an integrated option with zones!

[blgentry]

[...]so the only other option is to implement another widely adopted standard, AirPlay, or license TuneBlade as a server and client module and build it into zones as an option for sync play with their APIs.
[...] 
otherwise I'd license TuneBlade and make it an add-on license and module. They seem to have a good model and attitude with quite functional software.

The only "problem" with that is sync would only work on AirPlay capable devices, which is a small number compared to what's out there.  I suppose if you have airplay devices, this is great.  Or if you are looking to buy everything from scratch, it would be nice to know that MC supports AirPlay, so you could buy just those devices.  But it certainly doesn't address the issue of using non-airplay devices.  Just saying all of this for clarity, not to be critical or dismissive.

Brian.

[mattkhan]

Where does this system fail for you?  And even better, what can we do about it?

IME attempting to do this involves faffing around manually trying to work out the correct offset between two rooms and then my wife saying "wtf are you doing" and using another device instead. ie it fails in that it just doesn't work without manual setup every time (which means it is never used)

I might be missing something here but why would licencing some other product built on airplay make sense for a proprietary cross platform app? I have never used airplay so perhaps I am missing something about it.

[jmone]

I've faffed around for years trying to get in-sync audio working in a whole house environment with a mix of rendering devices (MC, Airplay, DLNA) with little success using MC as the server (incl sync adjustment).  As mentioned the Tuneblade soln does work but it adds an extra layer of control (turn zones on/off and adjust vol) that can be a PITA and is currently restricted to Airplay devices only.

1) To start with it would be ideal for MC as the server to see and control all the devices as Zones, be it other MC instances, MC Remotes, DLNA and Airplay devices.  This last one is currently not available.  I'm sure others would also like other devices to appear as zones (Sonos etc)

2) The next would be to be able to keep the audio automatically in Sync regardless of the mix and match between MC instances, MC Remotes, DLNA and Airplay devices.

If I was to jump to tech soln mode, I'd suggest:
- Add Airplay Support (it includes sync as part of the spec) either directly or using Tuneblade as a plug in.  This also opens up the range of Airplay Devices to MC.
- Upgrade MC's DLNA support to UPnP AV Architecture 2 (it now includes sync as part of the spec).  I "think" MC uses DLNA to currently for MC to MC server / client playback and it so it would then address the sync between MC Instances and also any DLNA V2 device (none that I know of at this stage however)

The "other" bits that would need some thought would be:
- How to sync between the DLNA and the Airplay streams to keep them in sync
- How to fudge the sync with DLNA V1 devices

Thanks
Nathan

[apgood]

The other option my be something like DTS Play-Fi but don't know what the licencing costs are.

Also it's starting to get a bit of support on barious types of devices from a variety of manufacturers.

Sent from my LG-D802T using Tapatalk

[OverTheAir]

Have JRiver looked at how the Slimserver/Logitech Media Server (LMS) and software clients maintain sync?  Note that I am not referencing any hardware, only the pure software clients.

When I want whole house audio I use LMS hosted on Linux (can also be on Windows) and play back using Squeezeplay software clients on Windows and Linux machines.  There are other clients I haven't played with, I just use Squeezeplay. The only time I have found this solution to go out of sync was using a poor wifi connection to a really old laptop barely able to run Ubuntu 12.04LTS and the Squeezeplay client, so i put that down to old hardware issues.  If it helps any, when it does go out of sync on this one machine it didn't recover/resync but did stay consistently out of sync and didn't drift.  I use this solution for both my own FLAC CD rips and also for various TuneIn radio stations.

The Slimdevices repos for the server and clients are linked below but are old. I have no idea what licensing option there is if any, assuming that path were to be of interest versus just understanding how sync is managed, but thought I would mention this solution as I have not seen it discussed in sync threads here.  Both the server and the client software seem to be maintained by the community of Slimdevice users now.

Repos: http://svn.slimdevices.com/repos/
Server s/w:  http://downloads.slimdevices.com/nightly/index.php?ver=7.9
Client s/w: https://www.mediafire.com/folder/4q8dvq20iyz9e/Builds#4kr6np846nlb0
 

[ssands]

Perhaps another interesting datapoint.

I had a hi-res album that I wanted to play on sonos and thus needed MC to transcode. Previously, when I tried using MC zone sync to play to two sonos units, they drifted out of sync and that was the end of that.
Yesterday, however, I already had the two sonos units grouped. I played MC to one of the grouped sonos units and they both played the music perfectly in sync.

So, at least in this case, if the grouping is done in Sonos and I play to one of the group, I get sync'ed sound out of both units.

[beburi]

A few thoughts on the interface for synchronized audio playback:

For the first time I set up sync'd audio playback on two computers running JRiver with a separate NAS as the server. It works, but I spent most of my time in the two interfaces trying to figure out how not to do what I don't want to do. The rest was easy.

Here's what I want to do:

1) On machine A, define a virtual library that points to a NAS
    --Most simply, this just contains a library specification (i.e. server, file paths etc.)
    --Note, I am intentionaly defining a 'virtual library' to distinguish it from a streaming media server (a 'virtual library' could be just an .xml spec; it doesn't necessarily do anything)
2) On machine A, choose to share the virtual library on the network
3) On machine A, define a Linked Playback 'Group' (or 'Linked Zones')
    --Again, I'm inventing some terms
    --This machine chooses which library the Playback group uses; it could use the virtual library (loose sharing mode) or a local library (server mode)
4) When I select the Linked Playback Group, all I want to see is the music that's playing and I can choose to change the music or change other features related to sync'd group playback.
    --Note that all of my Zone's are local -- I don't want to see a bunch of Zones automatically messing up my interface when I am just trying to create a sync'd playback group
5) On machine B, connect the shared virtual library.
    --Ideally, this should be a minimally invasive connection -- It does not populate all the 'Zones' on the sharing computer and doesn't make other invasive changes to my local interface. I just point to that virtual library and can then access it, provided that the specification is accessible from and playable by machine B
6) On machine B, I select a local Zone, then choose to join my local Zone to the playback group
7) Any machine joined to the playback group can change the song or the playback list, as well as playback features like shuffle (including the machine that defined the playback group, which doesn't work for me--I can control music from the client but not from the server--at least server control of clients is not working as well as the other way around)

If machine B, cannot access a playback group's specified library, or can't play the formats, only then does machine B need to choose a shared zone that can access and play the library.


The above is a very rough stab at what I'm after. This is not an integration problem; I'm trying to get at a more intuitive interface for synchronized audio playback.

A few problems I had:
--setting up a Media server. To start, I had to navigate to a strange place to set up a media server (Media network under Services). I don't what to set up a media server for this use case. Everything should be managed by setting up a shared library and a shared playback group. If I need transcoding, streaming, a shared zone, etc., these should be options organized around simpler abstract sharing concepts.
--I had to be very careful that each machine plays on a local zone and is not streaming or transcoding or using other server-related features that are not needed. If, from machine B, I click on 'Linked Zone' and start playing, it automatically defaults to using a 'There' zone on the 'server' (machine A), simply because that zone is at the top of the linked zone list. This is very bad, because all my zones are local-configuration dependent. If I need to share a zone, that should be a separate downstream task (e.g. define a shared zone on machine C and choose to use it on machine A). I never want machine B to default to using a zone on another machine.

In this brave new world:
 machine A could define a shared 'virtual library' (CoolTunes), machine B could define a shared 'playback group' (PartyTime) that points to CoolTunes (as shared from machine A), then machine C could join PartyTime, using by default the current local zone (i.e. zones are not even a key concept for synchronized playback). Then, machine C could define a shared Zone to enable transcoding and streaming to machine D, which either can't see the library or can't play its formats. Realistically, it may be practical for machine A to define the shared Zone's exclusively since it is sharing the library. But any machine should be able to define and share a playback group and join such a group without having to fuss with remote zones and media servers. There may be some features that have to be associated with the machine that shares a particular virtual library.