Print

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

[JohnT]

Summary
This new feature allows simultaneous playback of Linked Zones.  At this time, it works best with zones that run JRiver Media Center.

Details
Build 24.0.5 introduces more precise syncing of audio playback over multiple Media Center zones.  If all zones within a zone link group have this version or newer, they will start playback at the same time. 

Requirements
1. Windows only (at this time)
2. Use WASAPI audio, with a buffer size between 25 and 100 milliseconds, exclusive access.
3. Set playback options for each zone to match the image below.
4. Avoid Bluetooth or wifi audio zones or complicated output chains.
5. Play songs at the same sample rate with the same channel setup (stereo).
6. Turn off conversion in Media Network / Add or configure DLNA servers... / Audio / Mode: "Original"
7. No DSP filters.
8. Important: Make sure the DLNA "SetNext" command is not disabled on your remote zones.  On your main zone computer, right-click on the remote zone and make sure the menu choice "DLNA Controller Options / Disable SetNext support..." is NOT checked.  See image below.

There will be a short pause (a couple seconds) for every Play, Pause, Seek, Next, Previous etc. command.  We expect to be able to shorten this pause in the future.

The zone that starts playback is "main" zone and time server for the remote zones.  If it is running an NTP time server, it will use that.  Otherwise it uses MCWS web service to set the times. 

On the main zone computer, you can manually adjust the timing using the right-click "Adjust link timing" menu option.

Thanks!


Audio settings




Make sure "Disable SetNext ..." option for remote Media Center zone does NOT have a check-mark by it.

[AndrewFG]

This sounds very interesting. (Its been on my MC “todo” list for years..)

Are you using the UPNP SyncPlay() command, to ensure the Synchronised starting? If so, are you using it just on JRiver own renderers, or did you find any other third party renderers out there that also support SyncPlay?

[JimH]

We wrote it. It's our extension of UPnP / DLNA.  John did it. Hat's off to John.

I hope that we can make the protocol available to other DLNA manufacturers.

[RoderickGI]

Some clarification please.

Is this just for DLNA Servers/Renderers, or does this work over a MC Media Network as well.?
Or did synchronised playback always work over linked Zones on a MC Media Network?
Or is playback over a MC Media Network actually playing media using DLNA anyway?

Just a little education for me.

I am interested to test this between my HTPC and Workstation, so that I can wander between the two rooms and hear audio in sync. In future, I would like to be able to do the same with video, particularly Live TV, for example having the news on the HTPC and in a Detached Display on my Workstation.

EDIT1: So it is using UPnP / DLNA, but my questions still stand. 
EDIT2: Based on your answer Jim, I take it that this will only work between MC Renderers, since only they will have the UPnP / DLNA extensions.

[Hendrik]

It only works between different MC instances, not third-party DLNA servers (for now).

[mattkhan]

I don't think I have the hardware to test this personally until either asio or linux is supported but I'll ask anyway, are there any particular scenarios that should be tested? or any test signals to use? or do you just want it used day to day to see what happens?

Does the "MCWS web service" translate, in practice, as "we assume you have configured all your hosts correctly with respect to time sync so will just make calls to the system clock and expect to get answers that are in sync"? if so, I don't see the relevance of the main zone having an ntp server on it.

[JohnT]

I don't think I have the hardware to test this personally until either asio or linux is supported but I'll ask anyway, are there any particular scenarios that should be tested? or any test signals to use? or do you just want it used day to day to see what happens?
can you expand on this pls?

It's working well on Linux for us, so when the next Linux build is posted, give it a try.  You can just test it with your music collection.  Something with prominent percussion, bass hits, piano, etc. makes it easier to tell quickly if it's in good sync.  The "timing adjust" option on the context menu for zones is working in the new system so you can use that to tweak the sync manually if it's off.  Just let us know how much it's off and what audio sub-system you're using (e.g. ALSA on Linux, and what kind of output: USB, analog, which DAC, etc.).

Does the "MCWS web service" translate, in practice, as "we assume you have configured all your hosts correctly with respect to time sync so will just make calls to the system clock and expect to get answers that are in sync"? if so, I don't see the relevance of the main zone having an ntp server on it.

The main computer acts as the time server for all zones.  They are provided with a URL to call  so they can synchronize themselves to the main computer's clock. 

If you have an NTP server running on the main computer, it will provide its NTP time server URL to the zones.  Otherwise it will provide an MCWS url pointing to its own web service. 

It should just work out of the box for all Media Center zones running the latest software.  We added a custom DLNA call which asks if a DLNA zone supports our JRiver DLNA sync protocol and only zones running the latest Media Center software will answer in the affirmative.

[JimH]

I don't think I have the hardware to test this personally until either asio or linux is supported  ...

ASIO might work.  Linux should be supported by the end of this week.

[JohnT]

By default, Windows only runs an NTP client, not server.  It's easy to enable the server though, I think I used the instructions on this page to do it:

https://www.interfacett.com/blogs/creating-standalone-ntp-server-windows/

It's pretty trivial on Linux/Mac also.

You may have to re-boot afterwards, not sure.  It's not necessary to run an NTP server to use the new sync system.  If NTP is not available, it will instead use a new MCWS web service "Time" call  (e.g. http://localhost:52199/MCWS/v1/Time).  The Time function returns a 64 bit integer compatible with the "timeval" struct representing the current system time.  At the client end, offsetting by half the network round-trip time gives a "close enough" value for good sync unless the network is VERY slow and the send/receive timings are very asymmetrical.

[AndrewFG]

Can you please give me the details of your “custom DLNA call(s)” and the underlying architecture of how you set the clocks?

[JimH]

John can give you the details, but I don't think we do anything with the PC's clock.  We're just using the time internally.  There is also an adjustment made for the latency of the audio device.

The master machine then gives the others a time to start, so that they all start at the correct time (not the same time, because of latency).

[drmimosa]

Great news, fantastic work! Can't wait to test this on the setup described above.

Quick suggestion, if you add the capability for an MCWS toggle for Disable SetNext it could help automate the setup for users.

[AndrewFG]

The master machine then gives the others a time to start, so that they all start at the correct time (not the same time, because of latency).

If you have created a new UPNP soap command that gives the renderers a time to start, then you have reinvented the wheel. The DMR V2 UPNP DLNA standard specification defines a UPNP soap command called PlaySync (or SynPlay) that is exactly the same as the regular Play() command except that it adds an extra argument providing the time to start.

Before you release your home made version, I seriously and strongly advise you to look at the existing UPNP DLNA V2 standard, and if possible simply rename your custom special command as PlaySync (or SyncPlay).

If you go your own way you will have a proprietary solution. Which being a copy of an already existing standard, will not be attractive for other vendors to adopt. So you will be on your own.

Whereas if you adopt the already existing standard as a first mover, you will be onto a runner.

[jmone]

Andrew, your DMRA reports SyncPlay as "NOT Supported"

[jmone]

Did a quick test between two MC instances.  Works as advertised and the Sync is perfect.    I did not even have to "Adjust link timing".... though, you really do need to make sure the settings are the same on both PC's as JohnT outlines or the sync falls apart on a track change. 

Couple of things I noticed:
1) If you do a Sync right at the end of a track (say the last 10 sec) then sync falls apart (the remote machine started playing the next track quicker the the local).  A seek fixes it
2) Oddly, I'm hearing a "click" on track starts with these settings for some reason (even when not linked)
3) The Delay in Seeks is (as reported) slooooowwww

I'll get a bunch of PC's, DLNA Speakers etc all linked up on the weekend and see how it goes!

[AndrewFG]

Andrew, your DMRA reports SyncPlay as "NOT Supported"

Yes. Obviously. Because MC does not yet support it. But it could easily do so now. This is a new feature added in DMRA specification V2..

[jmone]

Sorry - I thought you were asking if this new feature was reported as SyncPlay.  FWIW I too agree that it would be best as advertised as DLNA-SyncPlay

[AndrewFG]

Below is an extract from UPNP:AVTransport v3..

http://upnp.org/specs/av/UPnP-av-AVTransport-v3-Service.pdf

+++++++

5.4.26 SyncPlay()

..

This action behaves the same as the Play() action except that the playback of the current content binary shall be synchronized with the device’s internal time-of-day clock as specified by the ReferencePosition and ReferencePresentationTime input arguments.
..

The renderer shall start rendering the content at the ReferencePresentationTime argument at an offset inside the content specified by ReferencePosition argument.

The ReferencePositionUnits argument identifies the format of the ReferencePosition argument, for example, time vs. frame count, etc.

The ReferencePosition argument identifies a specific location within the content binary, for example, 1 hour, 10 minutes, and 34 seconds from the beginning.

The ReferencePresentationTime argument identifies a precise time of day at which the ReferencePosition is to be played for example, June 6, 2009 at 21 hours, 14 minutes, and 36.152 seconds (past midnight).

++++++++++

[JohnT]

If you have created a new UPNP soap command that gives the renderers a time to start, then you have reinvented the wheel. The DMR V2 UPNP DLNA standard specification defines a UPNP soap command called PlaySync (or SynPlay) that is exactly the same as the regular Play() command except that it adds an extra argument providing the time to start.

Before you release your home made version, I seriously and strongly advise you to look at the existing UPNP DLNA V2 standard, and if possible simply rename your custom special command as PlaySync (or SyncPlay).

If you go your own way you will have a proprietary solution. Which being a copy of an already existing standard, will not be attractive for other vendors to adopt. So you will be on your own.

Whereas if you adopt the already existing standard as a first mover, you will be onto a runner.

Thanks Andrew.  Do you have or know of a device that supports that PlaySync command?  I'd like to get hold of one and test it out.  It would be trivial to modify the DLNA commands we're using if we decide to support that standard, the hard part for now is getting the system working well in a variety of environments and playback scenarios.

[JohnT]

Did a quick test between two MC instances.  Works as advertised and the Sync is perfect.    I did not even have to "Adjust link timing".... though, you really do need to make sure the settings are the same on both PC's as JohnT outlines or the sync falls apart on a track change. 

Couple of things I noticed:
1) If you do a Sync right at the end of a track (say the last 10 sec) then sync falls apart (the remote machine started playing the next track quicker the the local).  A seek fixes it
2) Oddly, I'm hearing a "click" on track starts with these settings for some reason (even when not linked)
3) The Delay in Seeks is (as reported) slooooowwww

I'll get a bunch of PC's, DLNA Speakers etc all linked up on the weekend and see how it goes!

Thanks for testing!  I've noticed the occasional "click" on a pause or seek, but not starting a new track.  Do you hear it on starting a new track?  I've got the seek problem (#1 on your list) on my list to look into.  The delay is hard coded right now, but we'll add some code to gather latency information from remote zones and use that info to shorten the delay as much as possible.

[jmone]

Yup - I get the click on the start of new tracks but not on a seek.

Also did some testing using a Library Server Client on which I linked two zones (one local and one on the server).  Music started playing on the server, but the Client hung and then the server said something was wrong with playback.  Log attached

[jmone]

Some more testing:
Video : Does not work (asks to unlink zones)
Web URL (eg Web Radio) : Works and is in sync.  I presume MC is just handing off the URL anyway to all clients
3rd Party DLNA Devices : Only initial testing.  I guess as expected, this is still a PITA.  Sync is all over the place.  Worse, MC keeps pausing the Audio every 30 sec or so on all devices (2xMC, 1xDLNA AVR) for a couple of seconds (like it is doing a sync).

[JimH]

Thanks for the testing.  We haven't given much thought to devices other than MC at this point.  There's no way to tell them when to start.

We're still in very early stages with this.  It's complicated.

While you wait for something to happen, here's an article on The French Revolution.

[jmone]

Always fun testing.  The issues with std DLNA devices is that they always seem to have a "different" delay.  You can get it "dialed in" but then then on the next track, or next play they will be out of sync again.  You just chase your tail then end up using Airplay (which just works).

[JimH]

You just chase your tail then end up using Airplay (which just works).

With a variety of DLNA devices?

[jmone]

Nope with Airplay Devices as follows:
MC --> Audio Device (Captured by TuneBlade) --> Multiple Airplay

This works well and allows you to push any Audio (including that from a playing Video) to multi speakers in Sync.... So I thought, I also try a similar path using all MC as follows:
MC --> MC WDM Driver --> MC Link Zone --> Multiple MC

Result was not so good.  My local zone would play the audio but it keep cutting out and freezing.  The remote MC zone never played.

[Hendrik]

WDM cannot be played to any remote zones. Not with sync/linking, or without.

[jmone]

So far I've got configured:
- MC Zone Sync 2: Can now play to other MC instances in sync... but only Audio (not Audio from Video playback)
- MC DLNA : Can play to DLNA devices but not in sync
- MC / Tuneblade : Can play to Airplay devices & PC's (running TuneAero) in sync (also works well with Audio from Video Playback) ... but devices are not exposed in MC
- MC / BubbleUPnP Server : Exposes Chromecast devices as DLNA Clients in MC including Grouped speakers in sync
- Airspot : Exposes Airplay and DLNA Devices (including MC) as Spotify Connect devices

Taking a big step back I just want to open up MC.... See All potential renderers (DLNA, Airplay, Chromecast, Spotify Connect etc) and play to any/or a group of them and have the audio in sync.  I'd even scrap many HW devices to get it working easily, but unfortunately I'm thinking that DLNA is the weak link.  Even if Zone Sync 2 morphs into SyncPlay, the HW out there just does not support it...and unless HW Mfr provide new Firmware, it never will.

For what it is worth, I'd suggest:
1) Complete Zone Sync 2 as a DLNA SyncPlay as a core MC feature to sync between MC Instances
2) Contact Apple and Google about Licencing Airplay / Chromecast and sell these as an add-on plug in for those that want it.
3) Weave some magic so you can mix and match these devices and still have them play in sync!

[JimH]

Walk before you run.  We're only just getting MC to MC working.  If you want a global solution, this isn't it.

[jmone]

Sorry was not trying to come off as negative to the work being done, trying to work out how to best make it all work.

[jmone]

Adjust Link Timing does not seem to work if you have 2 MC instances linked.  But if I throw in a 3rd DLNA device then it does.

[AndrewFG]

Thanks Andrew.  Do you have or know of a device that supports that PlaySync command?  I'd like to get hold of one and test it out.  It would be trivial to modify the DLNA commands we're using if we decide to support that standard, the hard part for now is getting the system working well in a variety of environments and playback scenarios.

Hi John. Unfortunately I am not aware of any devices for testing. I guess that in lack of any control point manufacturers supporting it, the renderer manufacturers haven’t felt the need to do so. Chicken and egg. But if you take this step, I think you would be a first mover, and probably trigger an avalanche of followers.

[mattkhan]

I have been trying to get setup to test this with the kit available but have been struggling on this topic -> https://yabb.jriver.com/interact/index.php/topic,114937.0.html

the way MC is presenting zones from other MC instances doesn't seem entirely reliable in two ways

1) it doesn't seem to refresh when options are changed without going round and reconnecting instances from the library
2) the combination of DLNA options in Options > Media Network don't always seem to work in the same way each time I check them

2 might be a function of 1 though

can anyone comment on that thread to explain how it is meant to work?

[mattkhan]

can I also check the UI for this? https://yabb.jriver.com/interact/index.php/topic,114618.0.html says that "We expect to be able to start synchronized playback of a zone group." but this is not implemented yet right? i.e. I have to link zones first and then start playback

[JimH]

can I also check the UI for this? https://yabb.jriver.com/interact/index.php/topic,114618.0.html says that "We expect to be able to start synchronized playback of a zone group." but this is not implemented yet right? i.e. I have to link zones first and then start playback

That's correct.  You can't currently start playback of a zone group.

[JimH]

1) it doesn't seem to refresh when options are changed without going round and reconnecting instances from the library

Make sure you have 24.0.7 installed.  It's possible you may need to restart both sides.  We expect to make the settings automatic, so that the master zone controls the client settings it needs.

2) the combination of DLNA options in Options > Media Network don't always seem to work in the same way each time I check them

I don't know what you mean.

[mattkhan]

I do have .07 on all machines

I don't know what you mean.

for example

open 2 MC instances (A and B) with the DLNA Renderer option unchecked
check that each MC shows the local zones only
check the option in A
check that B sees A's zones quite quickly
uncheck the option in A
B still sees A's zones
click the "refresh dynamic zones" option in B
A's zones are still present
completely kill B and restart it
A's zones are no longer visible in B

actually this only seems to happen with the 24 clients or possibly it is a windows thing. I have 1 23 linux instance left and that one does get added/removed from the zone lists as soon as I check/uncheck that option. I'll try a 24 linux client later to see if it is an OS thing or not.

[mattkhan]

I also notice that the "device webpage" option for an MC zone doesn't seem to function correctly, specifically (with auth enabled on the MC instance) it takes you to Panel on some other port and you are unable to login but no error is displayed, it just sits at the login page. If you go to panel on the usual port and login then return to the address given by the "device webpage" then you can access panel without issue.

[mattkhan]

FWIW I tried a linked zone where 1 zone talks to an ASIO device, playback started on the remote zone normally but the server mc instance hung (UI whited out) and didn't start playback. I had to restart MC on the server.

I know you said "use WASAPI" but I tried it inadvertently so thought I'd report it anyway.

[mattkhan]

I gave this a try however I don't have windows clients on a wired network so this is over wifi albeit both devices with strong signals and with consistent ping times from one device to the other. The sync was quite a way off though, at least a second out.

Both of the MC instances involved have now become rather crashy after fiddling with DLNA options, they no longer seem to  want to see each other. The one that had logging on said

Code: [Select]

0293203: 3552: Playback: CPlayerZone::Stop: Start
0293203: 3552: Playback: CPlayerZoneDisplayInfoUpdateThread::Destructor: Start
0293203: 12072: Playback: CPlayerZoneDisplayInfoUpdateThread::Thread: Finish (158047 ms)
0293219: 3552: Playback: CPlayerZoneDisplayInfoUpdateThread::Destructor: Finish (16 ms)
0293235: 3552: General: TopLevelExceptionFilter: Unhandled exception -- program crashing
0293235: 3552: General: TopLevelExceptionFilter: Message: 275, wParam: 1, lParam: 0
0293235: 3552: General: RunProgram: Start
0293235: 3552: General: RunProgram: Filename: C:\Program Files\J River\Media Center 24\JRCrashHandler.exe / Parameters: JRCrashInfo13804
0293235: 3552: General: RunProgram: Performing ShellExecute...
0293250: 3552: General: RunProgram: Running process...
0293250: 3552: General: RunProgram: Waiting for completion
0000015: 16120: General: JRCrashHandlerApp::Run: Start
0000015: 16120: General: JRCrashHandlerApp::Run: Opening Shared Memory: JRCrashInfo13804
0000015: 16120: General: JRCrashHandlerApp::CreateMiniDump: Start
0000015: 16120: General: JRCrashHandlerApp::CreateMiniDump: Trying to set dump privileges
0000015: 16120: General: JRCrashHandlerApp::CreateMiniDump: Creating dump output file at C:\Users\mattk\AppData\Roaming\J River\Media Center 24\Crash.dmp

I can send you the dmp if you like

[mattkhan]

curiously I had changed this setup so that I just had a simple server with 1 client relationship and was attempting to link a server zone with a client zone. I imported a single test track to that library, played that file, one side played it ok, the other complained about a missing library entry and failed. I then looked on my usual server (which should not have been involved in this chain at all) and it was showing the same error message. This means the server was actually involved after all. I don't know why as neither client had that library loaded. I suspect the issue with the client option (show servers zones on client) might be involved.

Is there any way to get MC to print out the network topology? It seems quite confusing atm as you don't seem able to actually pick and choose places to play to/from (rather you have to set various options to get zones to show up on remote MC instances and then that introduces the possibility of a kind of mesh network that you can't directly control).

[mattkhan]

actually this only seems to happen with the 24 clients or possibly it is a windows thing. I have 1 23 linux instance left and that one does get added/removed from the zone lists as soon as I check/uncheck that option. I'll try a 24 linux client later to see if it is an OS thing or not.

tried this with a 24.0.2 linux client and checking/unchecking that box affects the other MC instances rapidly (within a second) so seems more of a windows thing than an 23 v 24 thing

btw unchecking the "show playback zones from the server on the client option" seems to rarely work, they just stay in the list  (and similarly, on other occasions, checking it has no effect)

[AndrewFG]

Thanks Andrew.  Do you have or know of a device that supports that PlaySync command?  I'd like to get hold of one and test it out.  It would be trivial to modify the DLNA commands we're using if we decide to support that standard, the hard part for now is getting the system working well in a variety of environments and playback scenarios.

John, it just occurred to me that I have a copy of the official UPNP certification test application (albeit an old version) and this includes the test suites for AVTransport versions 1, 2, and 3 of which AVT:2 and AVT:3 include the SyncPlay command. And I am sure that UPNP.org would not mind too much if I were to “lend” you my copy of this — all in the interests of furthering the take up of the technology. Please PM me if you are interested..

[JohnT]

John, it just occurred to me that I have a copy of the official UPNP certification test application ....
 Please PM me if you are interested..

PM sent.  Thanks!