AndrewFG wrote: 
> Well, I have spent more than a "bit of time" on it; more like ten years
> (which probably explains why it is "1990ish"). And yes, it does take
> hard work to master the protocol; you need to actually read the
> documents; and you need to make an effort...
> 
Believe me, I read the specs. Most of them at least. And I did make an
effort. I even implemented some of the more obscure parts of the spec
myself, I know it quite a bit by now.
> 
> I suppose belief is a matter of religion. The architecture considers
> three entities, the CP, the DMS and the DMR. Each such entity may be
> either on the same machine, or on another machine. The physical location
> does not make any difference...
> 
That's what the theory and the spec says. Real life, however, says that
you want to have your CP OFF for 99% of the time and that doesn't work
with DLNA, at least not with how it's implemented in >>99% of the
renderers and a "standard" which has it's implementation fail in >>99%
of the installations IMHO is a failed standard. Yes, you can call this
religious.
> 
> I don't doubt they are good people. If you want to do multi-player sync
> in UPnP then you have to either A) implement the UPnP push streaming
> model, and or B) implement the SyncPlay(), SyncStop() and SyncPause()
> actions. Your "good" people seem to be implementing the UPnP pull
> streaming model (HTTP GET), and  also implementing only the (non
> sync'ed) Play(), Stop() and Pause() actions.
> 
Nope. They started just like you and then they learned that life,
unfortunately, is not according to the spec and scrapped it after puttin
g a lot of work into it.

The spec says
> 
> The pre-condition is that the different MediaServers and MediaRenderers
> in the home are synchronized to the same master clock and support the
> appropriate clock synchronization protocol (such as NTP, IEEE 802.1AS).
> 
which equals to "Our spec is perfect. It's your job, dear developer,
through the use of unobtainium, to guarantee the ridiculous
preconditions we set for this system to work. If you just do that, you
will see that it works perfectly".

Apart from that iven this is not true because there is no way in the
protocol to compensate for clock drift which would even be an issue if
you managed to actively synchronize your clocks because this very
synchronization requires you to re-sync the audio, too.

Push streaming, btw, is another case of "unobtainium". I'm not talking
theoretical setups here, I'm talking real world CE devices.

Name one implementation where this works.
> 
> C'mon, get real!!
>


------------------------------------------------------------------------
pippin's Profile: http://forums.slimdevices.com/member.php?userid=13777
View this thread: http://forums.slimdevices.com/showthread.php?t=95603

_______________________________________________
discuss mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/discuss

Reply via email to