Ntpd won't save you from one particular rogue bit

Re:Ntpd won't save you from one particular rogue bit by wyldfire on Thursday September 28, 2017 @09:53AM (#15357106)

The RTC is not a factor for problems in music playback on phones or elsewhere. It's only for "wall clock" time, and generally only for when the system boots. The OS timer tick that drives the scheduler is often generated by the CPU and some operating systems don't use it anymore -- Linux has offered a tickless config for a while that I think many android configs capitalize on for the sake of conserving battery. The scheduler could be a culprit for playback discontinuity (stalls) but not problems with the tempo.

I'm wondering -- "What might cause music playback to be faster than normal?" I don't think I know enough to tell. Perhaps the clocks on the audio playback device are skewed? Most SoCs use a dedicated DSP which doesn't seem terribly different from PC's. Not sure, but we can say for certain that it's definitely immune to changes in wall clock time (whether in the RTC or its representation in the OS).

[ Parent | on HN ]

Re:Ntpd won't save you from one particular rogue bit by tonyarkles on Thursday September 28, 2017 @10:57AM (#15357533)

I had a USB sound card that, on windows, would play back at 48kHz instead of 44.1kHz. Slight pitch shift upwards, playback at 8% faster. Most apps just let the audio driver provide backpressure and don't actively try to send data at the rate the soundcard is expecting, they just feed bytes when asked.

Even more fun was that it was a dual-boot machine, and the audio worked perfectly in Linux but shifted up in Windows. I honestly thought I was losing my mind for a while. I'd listen to the same song in Spotify on both OSes and just get this "something is wrong here..." feeling in my gut.

[ Parent | on HN ]