Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Daniele Futtorovic Newsgroups: comp.lang.java.programmer Subject: Re: Is time an illusion? Date: Wed, 27 Sep 2017 04:26:29 +0200 Organization: A noiseless patient Spider Lines: 66 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Wed, 27 Sep 2017 02:26:58 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="bf011d76bb7f3389142412e3e614c47d"; logging-data="7943"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19EE3qzeJzHM4zDXYQpQ3eY" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: X-Antivirus-Status: Clean Content-Language: en-GB X-Antivirus: AVG (VPS 170926-8, 09/26/2017), Outbound message Cancel-Lock: sha1:2w8i31ubC2swm3EXM+MRpHoThDY= Xref: csiph.com comp.lang.java.programmer:37487 On 2017-09-27 03:00, Jerry Stuckle wrote: > On 9/26/2017 7:13 PM, Daniele Futtorovic wrote: >> On 2017-09-26 21:37, Eric Sosman wrote: >>>      I'm somewhat curious about why you need such lock-step agreement. >>> What are you trying to accomplish?  Why do you need to measure the >>> same interval on two independent stopwatches? >> >> I'm rendering audio over a network, in real-time, or as close to >> real-time as I can get. It's not just a matter of "render as much of >> this as you can, when you can"; I want to be able tightly to control the >> rendering, as well as have accurate measurement of the resulting latency >> -- possibly over multiple endpoints. >> >> The upside is that I'm not constrained by absolute time; I just need >> relative time. Also, the human ear is sufficiently forgiving that I can >> afford to be a couple milliseconds off -- but not too many (I think). >> >> Specialised equipment is out of the question for me, as the software is >> intended for general consumption. But based on the feedback here, I've >> incorporated clock synchronisation into my protocol, and it seems to >> work well enough, at least at low latencies. It's still an open question >> how well it will work when they get higher, but I'll burn that bridge >> when I get there. >> >> Thanks a lot for the assistance. >> > > If you're trying to synchronize audio with video, anything less than > 100ms is generally considered sufficient and regular updates with ntp > should work fine.  However, if you're trying to synchronize two > different audio signals (i.e. left and right channels), you have to be > less than around 50ms (1 cycle at 20 Khz), which you won't get reliably > without additional hardware. I don't think I want to sync audio signals, but... what makes you say I wouldn't get better than 50ms resolution? The way I see it, provided I get my clocks synched, the only other problem is the drift; otherwise I can do whatever I want. Therefore if I find a workable time interval over the length of which drift is negligible (say, <1ms), synchronisation is the only problem. In my current dev setup with random hardware, I see a drift of about 1ms per minute. I can work with and correct that. And as for the clock synching, as I understand it, it's a matter of the symmetry between the upward and downward leg of the packet roundtrip between both ends -- the more symmetric, the more accurate. And that difference is itself constrained by the roundtrip time, i.e., the error can never be greater than the overall roundtrip time. Again, I'm targeting a LAN. Possibly a WLAN. Roundtrip in such environments should be magnitudes smaller than 50ms, especially if I go pure UDP for the synching. Wouldn't you agree? Also, can you tell me how you arrive at the 20Khz figure? > The problem here is that CPU clocks, even if they are crystal > controlled, are not perfectly accurate.  A clock on a PC can easily be > off by a minute or two per week. Indeed, and that was the big revelation of these last few days. I feel silly for not having thought of it before -- it's kinda obvious, when you look at it -- but, ah well. -- DF.