If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

(agreeing wildly with Adamdea)
Can we have a 6-channel Touch please - or a method of perfectly syncing 3 Touches - so I can implement a 3-way x-over alongside/within Inguz...

Similar thoughts here. What would it take to engineer two or more squeezeboxes to be in perfect sync? Assuming some DIY skills, could some kind of clock sharing achieve this? I know that the synching process is quite an art, and involves some feedback to the server to keep track of timing. In previous discussion on this topic I think it was concluded that the built-in syncing wouldn't be accurate enough for a left/right or a bass/treble pair. But could a Squeezebox be (hardware) modded to slave from another without using the software syncing at all?

I have a pair of home-built transmission line speakers. I put the crossovers in separate modules under the cabinets, so inside the cabinets all I have is speaker cable running directly from the driver units to a 4-way socket on the back.

With all this support around here for active speakers, and now again this discussion of software crossovers, I realised that my speaker build gives me the option to convert them, without touching the cabinets, into active speakers.

I could replace the crossover modules with, say, linked digital plate amps (such as http://www.hypex.nl/index.php?option...d=75&Itemid=91), which allow the crossover settings to be adjusted in their internal software. But I could also 'unlink' those plate amps, flatten the crossover, and feed them with (DSP-processed) signals from synced SBs. I wonder how good the syncing could be made.

I rasied this question some time ago, and was told that as it stadsn there is no way of syching 2 squeexoes perfectly to get left channel right channel. However I seem to rmember that there is now the facilty to use 2 squeezboxes as the left and right of a stereo pair. thuis must mean they are synched, but seems to assume they are each playing in mono.
But could this be tweaked to allow each of the two sbs to have 2 separate channels.
I have the feeling that as this stadsn its more of a begging letter to logitech than a DIY item, but if anyone is reading it would be great if we could have 4/6 channels via LMS

I rasied this question some time ago, and was told that as it stadsn there is no way of syching 2 squeexoes perfectly to get left channel right channel. However I seem to rmember that there is now the facilty to use 2 squeezboxes as the left and right of a stereo pair. thuis must mean they are synched, but seems to assume they are each playing in mono.
But could this be tweaked to allow each of the two sbs to have 2 separate channels.
I have the feeling that as this stadsn its more of a begging letter to logitech than a DIY item, but if anyone is reading it would be great if we could have 4/6 channels via LMS

Yes, I remember the thread, but I don't recall any mention of possible hardware mods. But I have a notoriously poor memory.

I've obviously also missed the fact that they can now be synched for left/right - is there some information about that somewhere?

Mono playback would clearly be a requirement in that case. But if they are synched well enough to do left/right, they ought to be able to do bass/treble, didn't they? One SB is EQed to supply the left and right tweeters, the other to supply the bass drivers.

Define "perfect sync"? Are 10ms not good enough? If not, what exactly is it that you need?

I doubt it's a hardware issue, it will be a question of software and turnaround times in the network. Sync works by detecting offsets between the two players and dropping frames to correct that, you need to define an offset you want to detect that is too big so you are willing to accept to drop frames to compensate for the drift.

Also, do I understand correctly that what you want is to have_different_ channels to be sent to the SBs? That would probably require bigger SW changes on the server side, it's - again - completely independent on the hardware.

You can't avoid drift between the different device, no matter how good the hardware, even environmental conditions like temperature play a role, if you really want the HW in sync (that is: with only small drift) you need a completely controlled environment and pretty expensive clocks.

---
learn more about iPeng, the iPhone and iPad remote for the Squeezebox and
Logitech UE Smart Radio as well as iPeng Party, the free Party-App,
at penguinlovesmusic.comNew: iPeng 8, the Universal App for iOS 7 and iOS 8

Define "perfect sync"? Are 10ms not good enough? If not, what exactly is it that you need?

Good question. No idea. I imagine the sync requirements are tighter for a pair of speakers than they are for players in different parts of the house. Odd phasing, variable soundstage etc would result otherwise. I think the mono requirement could be avoided by using each SB as the source for a pair of drivers (eg left/right tweeters). This would make the EQing easier too I think.

And yes, I appreciate that doing this in software with the current architecture is tricky, probably not practical, but what information would need to be shared, say by a dedicated hardware link between the devices, to slave one from another? The audio is obviously buffered separately, but if it was played out by synched clocks would that solve it - perhaps in combination with the built-in software solution?

So a clock-out/clock-in mod - would that do it? Surely the mechanics of that have already been worked out, for slaving to a DAC.

So a clock-out/clock-in mod - would that do it? Surely the mechanics of that have already been worked out, for slaving to a DAC.

Sorry to quote myself - but I reckon that would do it. The software approach to syncing two players would apply one big adjustment at the start of playback, but after that, because the clock of the slave was driven by the clock of the master, there'd be no further drifting so no further adjustment would be required.

That doesn't work over a distance.
Sync as it is now allows a drift of 10ms which equates to 3m distance. That's something you can hear in an average room. I don't know, but if you have a good network (not too much latency), high data rates (so that you've got frequent communication between server and client) you might be able to bring it down to 1ms without hardware changes. Is that good enough? Probably if you don't want to pin your head at a fixed point where you want to listen.

---
learn more about iPeng, the iPhone and iPad remote for the Squeezebox and
Logitech UE Smart Radio as well as iPeng Party, the free Party-App,
at penguinlovesmusic.comNew: iPeng 8, the Universal App for iOS 7 and iOS 8

Thanks - those look really interesting. The miniDSP/DIGI/AMP combo looks particularly interesting for converting my passive speakers into active digital speakers with DSP capability. Not certain about the 2x20W capability, although I think that's the same as the NAD3020i that was driving these speakers previously.

But that's not the point of the thread. Pippin - are you saying the clock syncing signal can't be carried over a long cable? What if the synced SBs were next to each other, and only their outputs have to travel a distance?

In terms of hardware mods, there are a few things I can think of. Using one clock for both units would get them playing at the exact same rate, like you mention, which is a good start. From what I recall there are a couple clocks, both around 24 MHz. Differential line drivers and receivers should be used, and with that you should be able to get a few meters length without problem. Another signal to combine would be the hardware reset. This would get the CPUs started up at the same time, which might help.

However this won't do anything about the players starting their stream at a slightly different time. Ethernet is nondeterministic, and Wifi even more so. I can't think of any hardware that will improve this, but I can think of software solutions, like using a multicast packet to start the stream.