Audio Syncing: a limitation or bug?

Hello all:

I've been testing C2 for using layered music and found that when looping multiple tracks at once they eventually lose sync.

see my capx here: https://dl.dropboxusercontent.com/u/362 ... nager.capx

if you let the music play the tracks eventually fall out of sync. There are 4 tracks, each is exactly the same length (30 seconds). They start to go out of sync around the 3 loop (1:30 in) then by 4:00 minutes in, it's a complete mess.

I'm sure they are probably fired milliseconds apart, and if that was the only problem, they would be out of sync from the beginning, and continue that way. Because each track was made identical in length. But because they "creep" out of sync, they must be playing at different rates! I can't imagine how that could happen. Ashley is this a limitation or is it a bug? it reminds me of how beats can get messed up in a DAW if they have variable BPMs (beats per minute). Even a fraction of a difference eventually turns into a big difference the more the 2 times grow apart.

Sound events currently can only be fired during each tick, so assuming you're running at 60 FPS there's up to a 16ms error. Apart from that there should be no drift. However three timer behaviors effectively means you're keeping three separate times, when you want one audio clock - try basing all audio timing events off just 'wallclocktime' or some single source like that.

Ashley I'm only using Timers for volume fading, but the track remains playing (I probably should replace it with a more concave or convex "line" using lerp, it would sound better). All the music is set to loop in the Audio object. So it must be the looping that is causing it to become out of sync. I double checked my audio and each of the 4 tracks is precisely 29.538 seconds in length.

For the sake of ease let's say each track is precisely 0:30.000 seconds:

if track1 starts at: 0:00.000

and track2 starts at: 0:00.016 (worst case scenario)

and track3 starts at: 0:00.032

and track4 starts at: 0:00.048

their next start times after looping once should be:

track1 at: 0:30.000

track2 at: 0:30.016

track3 at: 0:30.032

etc... and so on..

each track should always remain the same +/-16ms apart after they have been started, however as you let it play(approx 4 mins), this is clearly not the case, the distance between the start times becomes audible and grows.

So maybe the Audio object is not meant to handle situations like this?

The Browser object handles actual audio playback and is responsible for keeping parallel tracks in sync. Does this happen in all browsers?

Ashley

I've been using Chrome 33.

However, now that you ask, I tested with the latest IE and Firefox

Firefox27.0.1 it seems, cannot handle looping audio seamlessly. And there is a noticeable pause between the loop points. I seem to remember this and started using Chrome because of it. However, if you continue to listen, it indeed has the same sync problems but they seem to happen right away after the first loop. With every new loop, I can't be sure, but it seems to change slightly, but never are they together like when you STOP, then START the music using the buttons I made.

IE11 is not working at all since I disable the buttons until "All Preloads Complete" event is true. And the buttons never become active...so I'm not sure what that is about. When I work around that, IE doesn't play the audio at all.

I'm running Windows 8.1 64bit

oh sorry.. IE probably doesn't support ogg... I only have ogg files in my capx.

Ashley okay, I made .m4a versions of all the audio and now IE is playing them fine.

IE11 does NOT lose sync at all (yaay!). I let them play for a long while. Although it doesn't do a very good job of looping seamlessly. It's not as bad as Firefox, but there's still a little 'pop' at the loop point - which depending on the music could be more noticeable. So that's a drag.

Gee I wish there was some consistency across platforms

Is there a way to report this syncing problem to Google or request this be addressed for a future update of Chrome? ditto for Mozilla... up until now I've had the best performance using Chrome and seems to be the browser of choice.

thanks for your help...

Yes, you should report them as bugs to Mozilla and Google.

done.

I just filed a Issue Report with Google although that seems like for the normal end user. Not sure where to send the report for something more technical than web browsing.

jobel this is a really nice example.

Is it technically possible to mute layers of music in a mobile browser?

I played this demo on Android Chrome but the mute buttons don't seem to mute individual tracks.

Android Chrome does play all the music layers at once.

NECROKRIEG I never tested it in Android Chrome, I can't see why it wouldn't work. Does the mute buttons just not work at all or does it mute all the tracks at once? If it's the latter then I'd say that was a limitation in AC as they probably look at all audio as one object, opposed to Chrome which allows C2 to effect an individual piece of audio by it's "tag".

NECROKRIEG I never tested it in Android Chrome, I can't see why it wouldn't work. Does the mute buttons just not work at all or does it mute all the tracks at once? If it's the latter then I'd say that was a limitation in AC as they probably look at all audio as one object, opposed to Chrome which allows C2 to effect an individual piece of audio by it's "tag".

Hi — When I un-tick the boxes in Android Chrome it doesn't mute any of the tracks, it doesn't turn off the full track either. However the volume meter does decrease to '-5 0'.

Thanks for the response, I have a feeling that AC sees the track as one instead of multiple layers, I will do some more research to see if it's possible to layer the music in mobile browsers, it might be a limitation.

NECROKRIEG well there is no full track, it's only individual tracks playing. So if you are hearing all the tracks playing then that part is working.

might be the Button objects or the Timers? does the colored track label get "greyed out" or become slightly opaque?

also it's important to note that this out of sync issue has not been addressed at all. my bug report to Google was completely pointless and most likely went unheard. I updated the capx to show the times next to the tracks and if you keep listening for > 1:30 you'll actually see them go out of sync.

Ashley do you know if this is even on Chrome's radar? I did file a bug report. It's almost a year later and my original question: "limitation or a bug?" still stands.

Is this something we can expect to be made to work or is it simply a limitation that we shouldn't even attempt?