PDA

View Full Version : Sync between digital and analog units?



tls
2006-06-01, 10:44
I have two SQ3's, both running firmware 45, both connected via the same 11g network (with a single access point) to the same SlimServer (running "SlimServer Version: 6.2.2 - 7085 - Mac OS X 10.4.6 (8I127) - EN - utf8").

One player is connected via its RCA outputs to a Behringer A500. The other is connected via its optical output to an Onkyo SP701.

If I try to sync the players, over the course of a long (e.g. 4-5 minute) song they will drift noticeably apart, with the digital player usually behind -- at times by what seems like as much as a half second. The players are in adjacent rooms, so this is pretty jarring.

I suspected some kind of delay in the Onkyo, which is processing the digital stream to do bass management, but putting the Onkyo in "line direct" mode didn't change anything -- and the songs don't *start* out of sync, anyway, they just *end up* out of sync.

Has anyone else seen this? Is there a fix?

grimholtz
2006-06-01, 11:11
Does pressing the FWD button help? (As discussed here (http://forums.slimdevices.com/showthread.php?t=23537)).

JJZolx
2006-06-01, 12:07
I have two SQ3's, both running firmware 45, both connected via the same 11g network (with a single access point) to the same SlimServer (running "SlimServer Version: 6.2.2 - 7085 - Mac OS X 10.4.6 (8I127) - EN - utf8").

One player is connected via its RCA outputs to a Behringer A500. The other is connected via its optical output to an Onkyo SP701.

If I try to sync the players, over the course of a long (e.g. 4-5 minute) song they will drift noticeably apart, with the digital player usually behind -- at times by what seems like as much as a half second. The players are in adjacent rooms, so this is pretty jarring.

I suspected some kind of delay in the Onkyo, which is processing the digital stream to do bass management, but putting the Onkyo in "line direct" mode didn't change anything -- and the songs don't *start* out of sync, anyway, they just *end up* out of sync.

Has anyone else seen this? Is there a fix?
I have an SB2 digital out to a DAC synched with an SB2 with analog outs and I've never noticed this.

How is it possible for the streams to get out of synch over the course of a single track? The Onkyo would must be buffering the digital input and then play it back at the _wrong_ rate. If its digital playback is that badly screwed up, you'd undoubtedly be better off using the analog outs of the Squeezebox.

azinck3
2006-06-01, 12:23
I have an SB2 digital out to a DAC synched with an SB2 with analog outs and I've never noticed this.

How is it possible for the streams to get out of synch over the course of a single track? The Onkyo would must be buffering the digital input and then play it back at the _wrong_ rate. If its digital playback is that badly screwed up, you'd undoubtedly be better off using the analog outs of the Squeezebox.

I don't think this analysis holds up. If the problem were with any sort of buffering in the Onkyo then the issue wouldn't be resolved by a track change on the SB3. You could *possibly* make this argument with the SB1 because it would "reset" the digital signal between tracks, thus forcing a new lock from the receiver. But the SB3's digital output is active all the time. Thus no new lock, thus no reason for the DAC to clear any buffers.

Ben Sandee
2006-06-01, 12:29
On 6/1/06, JJZolx <JJZolx.28qman1149189001 (AT) no-mx (DOT) forums.slimdevices.com>
wrote:
>
>
> How is it possible for the streams to get out of synch over the course
> of a single track? The Onkyo would must be buffering the digital input
> and then play it back at the _wrong_ rate. If its digital playback is
> that badly screwed up, you'd undoubtedly be better off using the analog
> outs of the Squeezebox.


I'd bet that this has nothing to do with the outputs used. I suspect it's
just the sync is not working properly. I love all my SlimDevices (all 4)
but I gave up on synchronizing them long ago. Until the network clock thing
gets implemented I don't think sync will ever be reliable enough for most
people.

Ben

JJZolx
2006-06-01, 12:39
I don't think this analysis holds up. If the problem were with any sort of buffering in the Onkyo then the issue wouldn't be resolved by a track change on the SB3.
Then explain how the tracks can possibly start in sync, but drift out of sync during the playback of a track? I don't see this when one of my units feeds a simple DAC and the other is doing analog out.

azinck3
2006-06-01, 13:10
Then explain how the tracks can possibly start in sync, but drift out of sync during the playback of a track? I don't see this when one of my units feeds a simple DAC and the other is doing analog out.

It's, as Ben said, the lack of a network clock. WHen a track is started the code is careful to begin playback simultaneously. But then the SB's are left to just play back the track. And because there's no network clock, the inevitable inconsistencies in the clocking of the SB's between units cause the small synch problem over time. This synchronization problem is well documented throughout the forums. The degree to which the problem occurs is going to vary on a case by case basis and will be affected by everything from slight differences in the components themselves, to different environmental factors (temperature, etc.) to different power-line conditions.

JJZolx
2006-06-01, 13:57
It's, as Ben said, the lack of a network clock. WHen a track is started the code is careful to begin playback simultaneously. But then the SB's are left to just play back the track. And because there's no network clock, the inevitable inconsistencies in the clocking of the SB's between units cause the small synch problem over time. This synchronization problem is well documented throughout the forums. The degree to which the problem occurs is going to vary on a case by case basis and will be affected by everything from slight differences in the components themselves, to different environmental factors (temperature, etc.) to different power-line conditions.
Ok, I see what you're saying. I'll have to fire up Mountain Jam tonight and see what happens over the course of a 33 minute track.

tls
2006-06-02, 10:40
It can't possibly have anything to do with "power line conditions" since the power input to the Squeezebox is DC, not AC. "Power line conditions" impacting time sync is -- and I do know a little bit about this, since one thing I used to do for a living was design digital carrier circuits for a telco -- something that went the way of the dinosaur with the General Electric 60Hz electromechanical alarm clock many of us had by our bedsides as kids. ;-)

I'm more than a little surprised that the units can't keep tight sync over the course of a song. They have an accurate oscillator of more than sufficient frequency available to drive the digital output -- if they didn't, it would have fierce bit sync problems, bad enough to be audible as glitches. Perhaps the digital output IC they use doesn't expose this clock to the rest of the system, or perhaps the rest of the hardware design doesn't allow its use to keep frames in sync during playback.

Temperature variations would make sense except that my two units are in adjacent rooms. Basically, I have to ask "just how crappy are the system clocks on these devices, anyway?" since you'd need a *really* bad oscillator to slip by half a second over the course of a few minutes, which is what I'm seeing.

azinck3
2006-06-02, 11:02
It can't possibly have anything to do with "power line conditions" since the power input to the Squeezebox is DC, not AC. "Power line conditions" impacting time sync is -- and I do know a little bit about this, since one thing I used to do for a living was design digital carrier circuits for a telco -- something that went the way of the dinosaur with the General Electric 60Hz electromechanical alarm clock many of us had by our bedsides as kids. ;-)

I'm more than a little surprised that the units can't keep tight sync over the course of a song. They have an accurate oscillator of more than sufficient frequency available to drive the digital output -- if they didn't, it would have fierce bit sync problems, bad enough to be audible as glitches. Perhaps the digital output IC they use doesn't expose this clock to the rest of the system, or perhaps the rest of the hardware design doesn't allow its use to keep frames in sync during playback.

Temperature variations would make sense except that my two units are in adjacent rooms. Basically, I have to ask "just how crappy are the system clocks on these devices, anyway?" since you'd need a *really* bad oscillator to slip by half a second over the course of a few minutes, which is what I'm seeing.


Ah, good point about the power-line stuff. I'm not an electrical engineer so I really am not able to comment any more about this intelligently. I agree that the slippage seems surprising. It'd be interesting to hear from Sean on the matter.

Here's a crazy thought--are you running different VU effects on the two units? I wonder if the processor load could have anything to do with it? I don't have any idea how these things are designed or programmed at a low level, so someone more knowledgable than I might come along and be able to definitively say that there's no way for the processor load to affect the audio data being output. But as a lay observer it seems like a potentially plausible explanation.

verbatone
2006-06-02, 16:33
Assuming everything were perfect in the data transport mechanism on the device, there could be variance from Squeezebox to Squeezebox due to the clock generation. Depending on the clock scheme, the audio decoder chip (the DAC) could have a PLL inside that might have some variance from chip to chip, so over the course of time, there could be drift. How much drift? I don't know, just a though. If the DAC doesn't have a PLL, then the master oscillator could be variance point. Typically the oscillators have pretty precisely specified frequency outputs, but with any system there is variance. Most systems that have synchronization characteristics use the same "system clock". This avoids clock gitter/phase issues.

If the data transport (music) was missing bits in the decode process, due to buffer underruns, data truncation, or something like this, the audio would get out of sync. If the bit errors were not catastrophic (hardly audible), but frequent enough, it's possible a delay could be noted.

Basically, I don't know, but there could be reasons. I could look into the burr-brown data sheet to see if I can find anything that might be suspicious.

Mark Lanctot
2006-06-02, 17:20
Depending on the clock scheme, the audio decoder chip (the DAC) could have a PLL inside that might have some variance from chip to chip, so over the course of time, there could be drift. How much drift? I don't know, just a though. If the DAC doesn't have a PLL, then the master oscillator could be variance point.

No PLL.

From http://www.slimdevices.com/pi_specs.html


Dedicated high-precision crystal oscillators (no PLL, no resampling)

ajmitchell
2006-06-04, 01:48
Yes, I agree its a fundamental synching problem, not an output type problem.

See my headache with the same issue http://forums.slimdevices.com/showthread.php?t=20534

Switching to 11g from 11b helped me a bit. In my experience the SB2 seems to have less problems than Sb3 but this is subjective.

Probably network signal is the key. If you run "Network health and performance" from the front page of slimserver it will usefully map each players issues!

Alex