Print

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

[JimH]

I've asked Matt to see if we can improve the audio sync.

If you have had this problem, please describe it here or link to a thread where the problem was reported.

Thanks.

[mwillems]

I have had issues with this.  The basic behavior I observe is that two linked zones will begin more or less in sync, but drift slowly apart over the length of a song, and then resync at track change.  The drift, on long songs, can get to be more than a second (clearly audible).  

I should make clear that I see this sync problem when using two of the exact same USB DAC on the same computer, which should be a "best case" for sync (i.e. both zones are local and playing back to the same brand of hardware).  When I attempt to sync remote zones or using DLNA, the sync is noticeably less tight.  

Some users (e.g. jmone) have reported that two different renderers will wind up playing two different songs at the same time, which I have not personally experienced.

Here's a few useful threads that I've personally been in (the first linked thread is about UPnP sync, but includes useful info on zone link generally, and also includes some records of user experiments and some good info on some technical issues):
http://yabb.jriver.com/interact/index.php?topic=91208.0
http://yabb.jriver.com/interact/index.php?topic=88762.0
http://yabb.jriver.com/interact/index.php?topic=88173.0

[Matt]

I have had issues with this.  The basic behavior I observe is that two linked zones will begin more or less in sync, but drift slowly apart over the length of a song, and then resync at track change.  The drift, on long songs, can get to be more than a second (clearly audible).

I'm not sure there's going to be much we can do about the drift within a song.  The timing of playback is controlled by the output plugin and there's just no way to monkey with it.  I suppose we could introduce a VideoClock like rate changer, but that's a huge change!

[mwillems]

I'm not sure there's going to be much we can do about the drift within a song.  The timing of playback is controlled by the output plugin and there's just no way to monkey with it.  I suppose we could introduce a VideoClock like rate changer, but that's a huge change!

I know what you mean, but that's a big chunk of the issue that everyone is trying to sort out with Tuneblade, Sonos, et al.  The more pressing problem is probably the fact that remote zones/DLNA renderers aren't necessarily even always playing the same songs, but within-track-sync is part of the package that folks seem to be trying to achieve.

Airplay's spec is to get playback within a 2ms tolerance during songs and sends a sync packet once a second to enforce it; I don't own any of the devices, but folks (Hilkton and Jmone) are reporting in the tuneblade threads that they're getting tight sync that way.  Sonos apparently does something similar (again I don't have the hardware so can't test). You probably don't need a tolerance that tight, but anything over about 40ms is going to start echoing.

[dtc]

When trying to sync 2 zones using one local zone and one zone on another system using Tremote it is usually out of sync. Matt worked on this a few versions ago, but never got it to fully sync. I know it is a hard issue, but wanted to report it again. It can be many seconds out of sync in just two tracks.

[jmone]

Here is the current state of play as I see sync between multiple end points
1) Initial Sync : MC Zone Link caters for this but I find it is not a fixed constant.  What values work one day may not work the next
2) Sync Drift  : Stuff gets out of sync over time due to clock differences.  Varies by devices, but can be audible within 1 song and over tiem you can even end up with devices on different songs
3) De Synced : You can also seem to get a sudden change in sync caused by an end point missing some bit say over a WiFi connection

This all makes MC less than Ideal for Whole Home House Audio (aka Sonos) etc. 

There would seem to me to be a few options:
1) Modify the Existing Zone System and Transport Layer : You could ensure that each track starts at each device by not buffering tracks ahead and contain any drift to that on one song (not going to help with anything having a long duration).
2) Add Timing to the Existing Zone System and Transport Layer : You could role your own timing info in and allow that could be used by Gismo and other MC Instances (but obviously would not work with 3rd party devices)
3) Implement the Existing / Upcoming Standards : Airplay / DLNA 2 / Sonos API :  I like this one as it gives you not only a set of standards but also a much wider ecosystem of end points that then work.  You would still need to modify Gizmo and MC to use this info as end points.

To me #3 makes sense.  One thing I don't know is what each of these standards support however, as I would have thought you would want a transport layer to handle Multiple Channels at high Bit & Sample Rates, eg 5.1 @ 96/24 etc. 


Thanks for Thinking about this!

[6233638]

One of the issues that I have noticed with sync is that sample rate changes often break sync entirely.
I think this depends on the device, as some DACs seem to buffer the audio stream during a sample rate change, while others simply cut off the first second or so of audio during the switch.
 
The former is what messes with sync. If my DAC is already at 44.1khz and I play a 44.1kHz file, it starts almost instantly.
If my DAC was at 192kHz and I play a 44.1kHz file, there's a half-second delay which causes there to be a sync error.
I'm not really sure that there is a good way to solve this, without having control over the DAC's behavior in that scenario. (which, I assume, is how Apple handles it with their AirPlay hardware)
 
Thinking out loud, one way you could solve it—though there are many potential issues with this approach—would be to resample all files in a zone to a fixed sample rate (to avoid changes), play a second or two of silence to ensure that the DAC is currently operating at that rate, stop playback again and then start playing music.
That way you avoid breaking the initial sync as the DACs switch sample rates.
 
It won't do anything to help with sync after the fact, but it's the only thing I can come up with which solves that part of the problem.
And I know that it's a messy solution, but I'm not sure that there's a better way when trying to link multiple devices together like this.
 
 
Of course you still have to deal with drift, and it would be preferable to support existing protocols/devices that can handle sync well, but when linking a number of local devices together it seems like the only option.

[Matt]

One of the issues that I have noticed with sync is that sample rate changes often break sync entirely.

Couldn't you just set DSP Studio to resample for all the zones in the link then?  That way there won't be sample rate changes.

[6233638]

Couldn't you just set DSP Studio to resample for all the zones in the link then?  That way there won't be sample rate changes.

Well I don't use the device exclusively for that one zone.
I have separate zones for music, video, and it's used outside of MC.
For music, I prefer to avoid resampling where possible.
Video is always resampled to 192kHz.
 
So even if I have DSP Studio resample the linked zone to 192kHz, the device may not be starting at 192kHz.

[paul.raulerson]

I'm not sure there's going to be much we can do about the drift within a song.  The timing of playback is controlled by the output plugin and there's just no way to monkey with it.  I suppose we could introduce a VideoClock like rate changer, but that's a huge change!

How does Airplay do it? Or Sonos?  You can play those all day long and they stay in perfect synch. Even going to different devices and DACs in the case of Airplay.

Perhaps it is some technique that can be adapted for JRiver MC.

Songs do drift in and out of synch while playing for me. This is especially true on long tracks of classical music.

-Paul

[JimH]

We're still working on this.

[glynor]

My main problem with Linked Zones isn't really related to Sync (though improvements here would certainly be welcomed).

I can't use Linked Zones basically ever because they unlink when you add video to the Playing Now list, and the main reason I'd want to use a Linked Zone is to route audio from my HTPC's main zone out onto the porch or into the kitchen.

In these circumstances, the sync doesn't matter that much (you can't see the TV from the kitchen or the porch), but the fact that it doesn't work at all makes this useless for me.  Even in a "music-only" playback session, I tend to add music videos to the playback queue here and there.

So, not really directly related, but I figured it was worth throwing out there.

[Hilton]

I'll comeback and comment later.
I have a few ideas that most of you have heard, but I'd like to give it some more thought so I can give you something achievable to consider.

 

I will say, after considering everything I've said before and read here.... I think Matt's on the right track here, as hard as that may be to swallow.
That's kind of how shairport-sync works, it deletes and adds samples to keep the streams in sync. I believe that is the foundation of AirPlay.
You still need a master clock to do this.

I'm not sure there's going to be much we can do about the drift within a song.  The timing of playback is controlled by the output plugin and there's just no way to monkey with it.  I suppose we could introduce a VideoClock like rate changer, but that's a huge change!

[paul.raulerson]

It is interesting. Just playing around tonight, I observed that four airport extremes driven as a zone from MC v20 stayed in synch with each other perfectly, but the main system drifted in and out of synch. Since in this case, everything was being sent to the airports as 16/44.1 ALAC files, my brain boggled at following the entire chain.

However, it might be possible to send the loacl audio through the same chain somehow, and make it look like another remote device. Of course, that would only work on Macs right now I guess.

[AndrewFG]

I guess you are talking about syncing of DLNA push, right?

Just to refresh on the background, in DLNA push MC sends either one of the following command series...

• SetAVTransportURI, Play (repeat)
• SetAVTransportURI, Play, SetNextAVTransportURI (repeat)

And then the renderer fetches each track with an HTTP GET.

So some of my tips for improving Sync would be as follows:

1) Don't use a mix of the two types of push above. If both renderers support SetNext then use it for both. Otherwise use Set for both renderers.

2) Do send the above series of UPnP commands always pairwise together for both renderers, as close to simultaneously as possible.

3) Do wait for the HTTP GET from both renderers to come in before starting to serve the stream to either of them. In other words hold back the faster renderer until the slower one makes its GET. Or to say it again differently, do start sending the stream pairwise for both renderers as close to simultaneously as possible.

4) Do always serve the same exact same byte stream to both renderers. Do not serve different media formats, bit depths, sample rates or whatever. This means basically always either serve the original file to both renderers if supported by both. Or fallback to L16. Or in the worst case fallback to MP3. Note: this requires that MC must check GetProtocolInfo (SinkProtocolInfo) on both renderers to find the highest common denominator between source and the two sink formats.

5) Concerning the pairwise serving in point 3) above, watch out for byte range seeks. Probably it is best to return HTTP headers without Accept-Range headers, in order to avoid any byte range seeks at all...

6) Do not allow the issuing of UPnP Seek commands when playing to synced zones.

7) Do not allow the issuing of UPnP Pause/Play commands (other than the first Play) when playing to synced zones.

8) The above measures will all help to ensure the starting of playing the tracks will be tightly synchronised. It does not solve the issue that some players may play through faster than others. So even if the start is tighter, the endings may float apart. To ameliorate this issue on longer tracks, do not serve media files with cue files as a single track. But rather break the track into individual separate serves based on the cue file.

EDIT: Furthermore, I suggest a possible additional "smart" enhancement as follows:

9) Test the latency of the two renderers, by attempting a Sync Play as described above, and checking the Player Status on both players. Take note of the time difference between the issuance of the Play command and the return of State=PLAYING on each renderer, and apply the delta between those two values to the "simultaneoues" pairwise commands described above. EDIT: you should probably also allow a user setting to turn off this automatic latency detection, and indeed allow a manual input instead.

10) Note by the way, that there may also be a case of sync linking between a DLNA render on one hand, and a local DAC on the other hand. In that case, just hold off pushing the stream to the local DAC until you have received the HTTP GET from the DLNA renderer for that DAC. You may need to push silence while waiting for the remote GET in order to keep the local DAC "warm"..

11) Further to 10) if the GET comes before the Play command has been issued, then ignore the above, but instead syncronise the pushing of the stream to the local DAC with the issuance of the Play command to the renderer...

NOTE: be aware that topics 2) and 3) above could lead to a race condition: if one renderer type does its GET before it receives a Play command, and another renderer type holds its GET until after the Play command. You would need to create a state table for handling this. And a pre test like 10) above would allow you to identify what each renderer's behaviour is...

[Matt]

A coming build will allow setting a playback rate for each zone in the link.

You'll need to monkey with it by hand, but 10.0 plays 10% faster and -10.0 plays 10% slower.

We're hopeful that this will allow disparate hardware to play in step.

[Matt]

A little more here:
http://yabb.jriver.com/interact/index.php?topic=90659.msg661335#msg661335

[ssands]

My 2 cents:

I have Sonos and wanted to use MC with it because Sonos doesn't deal with hi-res music. I got it working fine for one Sonos "zone", but syncing them did not work. I don't recall if their was drift (I think so), but it was annoying enough that I stopped pretty quickly.

All the sonos units are hard-wired, by the way.

[Hilton]

A coming build will allow setting a playback rate for each zone in the link.

You'll need to monkey with it by hand, but 10.0 plays 10% faster and -10.0 plays 10% slower.

We're hopeful that this will allow disparate hardware to play in step.

Look forward to trying it out!

[dtc]

A coming build will allow setting a playback rate for each zone in the link.

You'll need to monkey with it by hand, but 10.0 plays 10% faster and -10.0 plays 10% slower.

We're hopeful that this will allow disparate hardware to play in step.

Is this aimed at using Tremote, client-server systems as linked zones? As I remember it there were issues with both a individual track being in sync and with the startup of each new track. I thought at the time that they were separate issues.

[B17NNS]

Are you guys any more advanced with this?

I'm able to link two zones using JRemote but they're not in sync

[JimH]

We're working on it.  Making progress.  Not yet ready.

[B17NNS]

Appreciate the update Jim.

[michmartin]

Any suggestions on how to get a Sonos stereo5 speaker pair to play both speakers as a stereo player using MC 22?  I have to unlink the speakers as a stereo player in sonos to get them to both play....When the speakers are linked as a stereo pair in sonos, I can only link one of the stereo 5 speakers in MC...linking the second paired speaker creates a DNLA error...