0

audio syncronization across network

We just got a whole bunch of 220s to replace a couple of crazy-strange multitrack audio players; Rube Goldberg, "Doin' it the hard way!" (Or, in short, 3 multitrack audio players and 7 video players getting replaced with 32 Rokus.)

 

In doing some testing before I get into serious reauthoring of the content, I'm coming up with a couple of questions and/or concerns.

1. I'm going to have anywhere from a single player (no sync with anybody else,) up to 7 players locked together. I think there'll be something in the neighborhood of a dozen "groups" of players on a dedicated subnet with their own dedicated hub. I figure I'll distribute the UDP ports so they aren't all talking the same ports. But what happens if Group 1 sends a sync-command the same time Group 2 is trying to do it? I don't know enough about networking to know if this sort of collision will actually happen. Or is the Sync command a bi-directional sort of UDP thing with actual feedback, so the Master knows if the Slave is following?

 

2. In the test that I'm running now in the shop, I've got two players running, each running the exact same pair of audio files. Audio 1, Audio 2, then Audio 1 again. The Slave plays Audio 1 in perfect sync. Then it plays Audio 2 in perfect sync. Then it restarts Audio 2 for about a fifth of a second or so, before restarting Audio 1; again, in perfect sync. Unfortunately, I can't tell if it's also doing it to Audio 1 (because of the file in question.) Apart from having a short gap at the head of each file, is there a way around this? The loops should (ideally,) be as seamless as possible.(If we have to, we can probably live with this work-around.)

 

3. Any chance of making a Brightsign that can play 6 or 8 tracks of audio out of a bunch of analog outs without needing an external AC3 decoder? (I wish, I wish..)

 

Leo Kerr

 

 

3 comments

  • 0
    Avatar
    Alex

    1. You can give different names to sync commands in different groups, so the players do not miscommunicate. No, feedback does not come to master unit from slave. You can add "send udp" command to media file (slave presentation), and set the master unit to listen for udp command, and perform some action if needed. This is a way to setup slave-to-master feedback.

    2. Please send your master and slave presentations. In fact, synchronization of multiple audio files across multiple players is not supported. You need to add audio stream to video and play video on the brightsign. For seamless loop on HD220 we recommend using H.264 .MOV files. The audio type needs to be AAC.

    3. This functionality is not available on the current product line. The brightsign doesn't decode AC3 but passes it through.

  • 0
    Avatar
    LFKerr

    regarding question one, I was not so concerned about command-names being confused, but rather more about uncertainty of the UDP broadcast: if two "masters" broadcast synchronize commands at the same time,.. can the commands crash?

    On question 2, for this demonstration (BrightAuthor files attached,) I was just using a pair of MP3 files where I could tell if the two files were being played in sync. I had kind of hoped that the HD220 series might be able to work without making a whole bunch of video files, and it pretty much almost does. Maybe with a tiny bit of tweaking at my end -- a fraction of a second of silence to start -- and I should be able to make it at least mostly invisible to the audience.

    As a clarification on the attached Author files, the intent of the test was to see how it worked. They booted to an image file, and then the master timed out, sync-starting the first MP3 file on both players (same file, two players. Run into a mixer, picking left of Master and right of Slave. The files I was using made it very easy to judge if there was any slippage.) Then, when the first file tailed out, sync-start the second file on both machines. Again, identical file. It always has been that when the "show" loops back to start the first audio file again, that the Slave player briefly starts the second audio file.

    In further checking of the mp3 files themselves, the first file has a moment of silence - maybe as much as a quarter of a second of silence before the audio starts. The second file has... nothing. It just starts, big and loud, right from the very beginning.

    Maybe if I'm a little more awake tomorrow, I might try another experiment; even just as a pure experiment. Sync-start the first step, and then just use time-outs -- no synchronization -- and see what happens.

    (I think I've been at work too long today.)

     

  • 1
    Avatar
    Alex

    You could substitute "sync" with "UDP", and test. See the attached presentations.

Please sign in to leave a comment.