Print

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

[yoyoc]

Regards.

I read a few days ago that at the begining of the 2013 the UPNP forum approved a guide or something like that for syncronized zone playback.

Here is the paper which includes it..   http://upnp.org/specs/av/UPnP-av-AVArchitecture-v2.pdf


As this has been a sore spot so far, is there anything on this coming to MC?

[AndrewFG]

I read a few days ago that at the begining of the 2013 the UPNP forum approved a guide or something like that for syncronized zone playback.

You are right that the UPnP AV architecture specifications have added features since v1. Some of the specifications are now on v4. The principle improvements are i) playlist loading and editing (and thus better gapless playback), ii) synchronized playback, iii) improved handling of TV tuners and program guides (essentially time dependent libraries).

This is all well and good in theory..

However even though the specs have advanced the feature set, in reality there are no renderers (at least none that I know of) that actually implement specification versions higher than v1. So it is no point for MC to support higher versions until actual hardware arrives that implements it too.

So if you are aware of any renderers that support UPnP AV v2, V3, or v4 please let us know about it here!!

[yoyoc]

Onecomes to mind immedietly......   

Anothe pc with MC that could act as a renderer in another part of the house.

[csimon]

Yep, then the JRiver Synapse sort of makes sense!

[Hendrik]

If you already have a Media Center box, why use DLNA instead of MC talking to each other directly.

[csimon]

a. Saves setting up an MC client/server relationship, loading remote libraries, data sync issues, unable to rip optical discs on clients, etc.
b. If enhanced as described, would provide synchronised playback. MC can't do that.

[Hendrik]

DLNA has equal potential sync issues, and it also cannot rip discs.
For enhancements, if there are improvements to be made, might as well have native MC interaction also use them!

[csimon]

DLNA has equal potential sync issues

Even with the UPNP enhancements which are designed to solve the problems??  Would they not be available for use in DLNA?

and it also cannot rip discs.

Why would you want to rip discs on a DLNA renderer?

I would want to rip discs on a specific PC, although it could be any, and send music in sync or independantly to any PC or renderer.

For enhancements, if there are improvements to be made, might as well have native MC interaction also use them!

Oh, absolutely. But I'd rather not have to use MC client/server just in order to use synchronised playback, it's too awkward, and introduces problems like you cannot rip discs on a library server client.

[csimon]

But having thought about this a bit more, I'm not sure that in practice I would use it...

You see, at the moment to get round the problem of synchronised playback, I've given up on doing it via software and am basically just distributing line-level audio around the house (matrix switch/distribution amplifier etc).

If synchronisation via DLNA was to be available then what I'd want is a small and cheap DLNA renderer to place at speakers around the house.  I wouldn't want to buy an MC PC for each set of speakers, even if it was a low-cost $400 NUC. I'd be wanting a $50-$100 renderer.

However, it would make sense if, for a particular room, I'd like quadrophonic or 5.1 sound - which is something you can't do with line-level audio, nor with existing DLNA renderers because you can't use MC mixing on them.

[JimH]

I wouldn't want to buy an MC PC for each set of speakers, even if it was a low-cost $400 NUC. I'd be wanting a $50-$100 renderer.

Do you know of a reliable UPnP / DLNA renderer you can recommend in that price range?

[csimon]

I've got two WDTV Lives, and old one and a new one. They work very well but the old one was prone to freezes and reboots, not regularly but every so often.

[JimH]

This one?
http://www.amazon.com/Live-Media-Player-Wi-fi-1080p/dp/B005KOZNBW/

That's one we would recommend also, but I don't believe it will do gapless playback.

[AndrewFG]

DLNA has equal potential sync issues, and it also cannot rip discs.

No comment concerning the second part of your sentence  

But the first part is exactly what the OP was addressing. The later revisions of the UPnP specifications added new methods on top of the v1 feature set to (among other things) solve the sync problem. So for example (if I remember it correctly) there is a new method called PlaySynchronized() in addition to the basic v1 method called Play().

The PlaySynchronized() method (if I remember it correctly) is called with extra arguments that specify an absolute time when the playing shall start. So you can already start to imagine some of the reasons why nobody has yet implemented a renderer with the PlaySynchronized() method...

• It requires that all renderers and control points shall have access to a common master clock server.
• It requires that the Control Point shall have a UI feature whereby it can tell all other parties the URL of the respective common clock server.
• To avoid latency issues it is preferable that the common clock server is local, and thus the CP would have to implement that clock server function.
• What happens if the CP clock server goes away?
• As implied by other posts, to do synchronized playing the CP must have a way of measuring delays between renderers.
• At which physical location shall it measure the delay?
• The CP must have a UI supporting the delay measuring, and allowing the user to tweak it.
• Even if PlaySynchronized() syncs the start time, it requires that all renderers shall keep in step, so all renderers must have exact sample clocks on playback.

Etc. Etc.

EDIT:  Oh. And by the way, the above refers to the newer versions (extensions) of the UPnP specifications. And I am not sure whether the DLNA community has got so far as adopting those extensions yet. (Somebody please correct me if I am wrong...)

[MrC]

Tight synchronization was a good amount of work for the SlimDevices folks back when they implemented it for exactly the reasons AndrewFG mentions (they had loose synchronization prior to that).  And they controlled their domain of devices and software.  I can't imagine more than a smattering of DLNA suppliers implementing this for a long, long time (look at the state of gapless support in 2014).

[csimon]

This one?
http://www.amazon.com/Live-Media-Player-Wi-fi-1080p/dp/B005KOZNBW/

That's one we would recommend also, but I don't believe it will do gapless playback.

Yes, that's the one (the newer model). No, I don't think it does gapless over DLNA.

[JimH]

I had lunch with Chris Connaker of Computer Audiophile yesterday.  I asked him what he could recommend without qualifications.  "Linn", he said, "but it's $5000."

[csimon]

In the $200-$400 price range (not sure exactly, I only know how much these things cost in the UK!) there are things like the Denon DNP-F109 (http://www.denon.co.uk/uk/product/pages/product-detail.aspx?catid=systems&subid=minimicro&productid=dnpf109), DRA-N5 (http://www.denon.co.uk/uk/product/pages/product-detail.aspx?catid=systems&subid=networkmusicsystems&productid=dran5) and Cambridge Audio NP30 (http://www.cambridgeaudio.com/products/np30-network-music-player) & Stream Magic (http://www.cambridgeaudio.com/products/stream-magic-6-upsampling-network-music-player), all of which offer DMR almost as a bonus, they have all sorts of other streaming and network features. The Denon ones, I believe from discussions in the past, have now got a firmware upgrade that does gapless, and the Cambridge Audio ones are reputedly audiophile quality.

[AndrewFG]

Tight synchronization was a good amount of work for the SlimDevices folks back when they implemented it for exactly the reasons AndrewFG mentions (they had loose synchronization prior to that).

It may be interesting the way that SlimDevices did it..

There are actually huge parallels between the SlimServer architecture and UPnP. This is the reason why I was able to write Whitebear, since I could essentially map every UPnP method onto an exact equivalent SlimServer method. The main difference is indeed as follows:

• In UPnP a push command passes a URL to the renderer which it pulls via an HTTP GET; and HTTP GETs are served asynchronously.
• In SlimServer when renderers are not synched, it works the same way using HTTP GETs.
• In SlimServer when renderers are synched, (or when transcoding), it flips to a push mode in which the stream is pushed synchronously.

In other words, the only, and fundamental difference is that in SlimServer the synchronization is a function of the server, whereas in UPnP newer versions supporting synch the synchronization is (would be) a function of the renderer.

PS if bob had a few minutes to spare, he might consider tweaking MCs HTTP server so that if parallel GETs for the same stream come from two renderers within a certain time window, the server would respond to both GETs in lockstep. This might increase the chances that both renderers actually play in synch; particularly if both renderers are the same make. The down side would be an added latency due to the above-mentioned time window. And also if different renderers have widely different downloading and buffering strategies then the results might indeed be totally fubar...

[yoyoc]

I am no programer, but sounds like a solution to me. ?