Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21
  1. #11
    Senior Member chill's Avatar
    Join Date
    Mar 2007
    Posts
    501
    Quote Originally Posted by rpress View Post
    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.
    I'm wondering whether the existing frame-dropping mechanism, as described earlier by Pippin, might be sufficient here, especially if pushed as far as it'll go with a decent network. Would it make sense that once the players are sharing a clock (or clocks) then any drift after the initial sync would be eliminated? If so it's the initial sync that's important.

    In my experience, syncing different players in different rooms seems to work well, and the only time it's less than perfect is when I have a mixed playlist and the crossfading kicks in. It seems like the sync is adjusted between tracks (to try and make it inaudible I guess), but when crossfade is on there's no 'inaudible' period. But this only occurs at the end of a song, so as far as I can tell the initial sync is pretty good. If this can be brought down to 1ms (approx 30cm), would such a difference between the tweeters and bass drivers be audible?

  2. #12
    Senior Member
    Join Date
    Jul 2009
    Location
    USA
    Posts
    126
    Quote Originally Posted by chill View Post
    I'm wondering whether the existing frame-dropping mechanism, as described earlier by Pippin, might be sufficient here, especially if pushed as far as it'll go with a decent network. Would it make sense that once the players are sharing a clock (or clocks) then any drift after the initial sync would be eliminated? If so it's the initial sync that's important.
    The frame-dropping mechanism will at best sync the players to the size of one frame. I don't know how big a frame is typically. But it still relies on the network to communicate the playback position of each player, and the problems with the nondeterministic latency.

    I think the initial sync is the key here as well.

  3. #13
    Senior Member
    Join Date
    Jun 2006
    Posts
    1,686
    Its certainly possible to share clocks over something like a LVDS link, thats fairly easy. As has been mentioned the problem is software. I see two main issues, getting two different data streams to the two players, and making sure they both start playing at exactly the same time.

    Both these are somewhat tricky.

    The easiest solution that I can come up with is to multiplex the multiple channels into one stream, say if you want 4 channels, you put all 4 into one 88.2 stream, we then have a custom jive_alsa that picks out the sample for player A and the jive_alsa in player B extracts the samples for that player. But you still need to sync the two players.

    Another possibility is to have a true master/slave syetem. The master player does all the normal stuff, but the data going to the dac chip actually has two samples, the extra data is ignored by the chip. We tap onto the data wire and send it over to the other player where we offset the L/R pulse so it's DAC chip sees the second sample. This would for sure take a change in jive_alsa, but would also probably take a change in the DAC chip driver. The advantage is that it doesn't take any change in the server or other firmware in the Touch.

    For both the above schemes you would need a server plugin that took the file data, did the DSP to split it up into multiple channels, then recombined the data into a faster two channel stream. From then on the server and most of the Touch just see a normal two channel stream. The plugin would have to have some way to tell the server that the data rate is faster than what is listed for the file.

    The first approach is fairly easy hardware wise and can use existing firmware (except for jive_alsa) and sync scheme since the same data is going to both players. But that is only going to work for 4 channels and starting with 44.1 or 48Khz files.

    John S.

  4. #14
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    11,980
    Quote Originally Posted by rpress View Post
    The frame-dropping mechanism will at best sync the players to the size of one frame. I don't know how big a frame is typically. But it still relies on the network to communicate the playback position of each player, and the problems with the nondeterministic latency.

    I think the initial sync is the key here as well.
    The server compares the clocks in the different devices, network latency is not an issue.
    And I misspoke about the frames, the player is dropping samples, not frames, although it's usually more than one at a time. The mechanism is that when the players are off by too far (as of the defines threshold of 10ms), then the player is advices to drop enough samples to get them back in sync (the slower player, that is).

    This effectively means the server is measuring the clock drift between the two players and compensating for it. If you can get the threshold low enough, you can easily get any accuracy you want (OK, as much as the sample rate allows) but the problem will be that if you make the step too small you'll probably run into race conditions which make the whole mechanism unstable. You'll also get too many false corrections due to single events adding latency that will not get through to the audio output due to buffering, I have no idea where the practical limit is.
    ---
    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.com
    New: iPeng 8, the Universal App for iOS 7 and iOS 8

  5. #15
    Senior Member
    Join Date
    Jul 2009
    Location
    USA
    Posts
    126
    Quote Originally Posted by pippin View Post
    The server compares the clocks in the different devices, network latency is not an issue.
    How does the server know the relative time between the clocks? It has no real reference. There is no wire between the units that will latch the two internal clock values at the exact same time.

    It must use the network at one point. A multicast or broadcast packet would be best, and even then the clocks would not be read at the same time, but pretty close.

    It's curious to look at the Network Time Protocol, these guys do their best to synchronize clocks over IP. Using a local NTP server, it seems that accuracy can possibly be a few ms, but over the internet it goes out the window.

    With the local oscillators using the same source, and the reset lines tied together, this could potentially synchronize the internal clock counters.
    Last edited by rpress; 2012-02-01 at 18:45.

  6. #16
    Senior Member bluegaspode's Avatar
    Join Date
    Jul 2009
    Location
    Berlin, Germany
    Posts
    3,161
    Every device just reports, how many samples it has played, so the server knows, which one is behind quite exactly. The clock of the devices is not used.

    In addition when the server requests the current frame, it sends its own timestamp which the devices must return in the answer.
    So when the server retrieves the answer it has a very educated guess about network latency for every single device.
    Every second a status update is sent.

    Finally given that devices in sync will be typically placed in different rooms and then based on where you stand there will always be delays of some milliseconds due to the time the audio travels through the air, an absolutely perfect sync between the devices is not needed anyway.
    Did you know: SqueezePlayer will stream all your music to your Android device. Take your music everywhere!
    Remote Control + Streaming to your iPad? Squeezebox + iPad = SqueezePad
    Want to see a Weather Forecast on your Radio/Touch/Controller ? => why not try my Weather Forecast Applet
    Want to use the Headphones with your Controller ? => why not try my Headphone Switcher Applet

  7. #17
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    11,980
    Quote Originally Posted by bluegaspode View Post
    Every device just reports, how many samples it has played, so the server knows, which one is behind quite exactly. The clock of the devices is not used.
    the number of samples played _is_ a clock, isn't it?
    The server expects that this figure is closely correlated to the clock. It's really the number if samples _played_, not the number of samples that are processed in sone way, which is why sync with software players on PCs etc. doesn't work.

    Finally given that devices in sync will be typically placed in different rooms and then based on where you stand there will always be delays of some milliseconds due to the time the audio travels through the air, an absolutely perfect sync between the devices is not needed anyway.
    well, that's no longer true since they introduced the feature to pair two mono Squeezeboxes as a stereo pair, using sync (mainly to be able to use a pair of radios for stereo playback).
    But I really don't see why you should not be able to get down to, say, 1ms except for the fact that you do an awful lot of corrections.

    @rpress
    Nobody said this would work over the internet. The problem with the Internet is that you don't have constant latencies unlike in a local network.
    Last edited by pippin; 2012-02-02 at 02:10.
    ---
    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.com
    New: iPeng 8, the Universal App for iOS 7 and iOS 8

  8. #18
    Senior Member bluegaspode's Avatar
    Join Date
    Jul 2009
    Location
    Berlin, Germany
    Posts
    3,161
    Quote Originally Posted by pippin View Post
    the number of samples played _is_ a clock, isn't it?
    But rpress obviously thought of something different, when you talked about a clock.

    since they introduced the feature to pair two mono Squeezeboxes as a stereo pair
    Did that already get a price for most geekiest and probably unused feature of the century?
    Did you know: SqueezePlayer will stream all your music to your Android device. Take your music everywhere!
    Remote Control + Streaming to your iPad? Squeezebox + iPad = SqueezePad
    Want to see a Weather Forecast on your Radio/Touch/Controller ? => why not try my Weather Forecast Applet
    Want to use the Headphones with your Controller ? => why not try my Headphone Switcher Applet

  9. #19
    Senior Member pippin's Avatar
    Join Date
    Oct 2007
    Location
    Berlin
    Posts
    11,980
    Quote Originally Posted by bluegaspode View Post
    But rpress obviously thought of something different, when you talked about a clock.
    OK, may be, but I talked about compensating for clock drift which is exactly what the mechanism does. Actually I believe (and that was my point) you don't need any other mechanism to compensate for clock drift, this one is fine.
    Did that already get a price for most geekiest and probably unused feature of the century?
    I don't know. Used it once myself for a party, albeit with two Classics.

    I also know it's a well-received feature with Sonos, obviously a lot of people just put two play:3 or play:5 devices in a room and use these to create stereo sound.
    I also like the idea of being able to place two battery-powered Radios around me and have stereo anywhere, I don't think it's geeky.
    ---
    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.com
    New: iPeng 8, the Universal App for iOS 7 and iOS 8

  10. #20
    Senior Member
    Join Date
    Jul 2009
    Location
    USA
    Posts
    126
    Quote Originally Posted by bluegaspode View Post
    Every device just reports, how many samples it has played, so the server knows, which one is behind quite exactly. The clock of the devices is not used.
    Sure the clock is used, the "samples played" clock (if you want to call it that) is basically a divided version of the real clock.

    Quote Originally Posted by bluegaspode View Post
    In addition when the server requests the current frame, it sends its own timestamp which the devices must return in the answer.
    So when the server retrieves the answer it has a very educated guess about network latency for every single device.
    Every second a status update is sent.
    Yes I'm sure it can compensate for latency, so does NTP. But Ethernet is still nondeterministic, that was my point in the first place. How good it can be, and if it is good enough, that is up for question.

    Quote Originally Posted by bluegaspode View Post
    Finally given that devices in sync will be typically placed in different rooms and then based on where you stand there will always be delays of some milliseconds due to the time the audio travels through the air, an absolutely perfect sync between the devices is not needed anyway.
    Yes the current mechanism is fine for players in different rooms. The original poster wants to use it for a "left/right or a bass/treble pair." For this a few milliseconds is a big problem.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •