Hey Dr Bagley you forgot to mention one thing at the end there. You completely just passed up the other end of it, the computer or device you're pairing with and it's bluetooth implementation and driver stack! So not only have you got the compression and decompression delays and just the fact that it's wireless instead of wired so that's always a slight delay even just because of that. (and wired is faster in that regard [ex. we like to prefer ethernet instead of wireless when we can since it's less delay and even more bandwidth possible like with a gigabit ethernet port! :)]) We seem to be reducing the delay with faster and faster devices and better implemented and newer versions of bluetooth but still could make it a bit faster than now I think. (Like when there's virtually no noticeable delay and you could use wireless headphones in realtime that would work just as well as wired ones [that'll be awesome] but the delaying the video is a clever way to compensate for the delay at present! So basically both the slowed down audio signal and also the bluetooth drivers and software on both the bluetooth audio device and device paired to receive audio from contribute to the problem the person who commented that which inspired this video was running into! :) Yea I have a bluetooth audio device also and I find lately the linux bluetooth stack has gotten a lot better and works better I think than both mac and windows bluetooth stacks! So that's something :D If you want to see if you can improve your delay in bluetooth audio, try Linux :D (If you don't know what distro I'd say go with debian instead of ubuntu if that was probably going to be one of your options (as that's recommended for new people to linux a lot it seems)) Bluetooth audio, it's cool even right now, but we can improve on it even further! :D

That is half of it, the other half is the name of the scene and take #.

+Partition 36 ;)

What on earth are you on about? 😅

No kidding -- no mention of AptX Low Latency suggests they did very little research into producing this video. They needed to mention that there are some Bluetooth audio codecs out there that have very low latency that are so responsive that the human brain can't detect the difference. AptX Low Latency has a delay around 40 ms.

The information in this video is general to all methods of transmitting audio from point A to point B. AptX LL had different latency and worked differently, but nonetheless did have latency, and the information in the video applies to it equally. AptX LL is now defunct, but was an interesting case as it was an attempt to go outside the Bluetooth spec to work around its inherent latency. Bluetooth was used to establish communication but audio was transmitted over a separate non-bluetooth transmitter and receiver. Effective, but proprietary and expensive for manufacturers to implement. Its replacement AptX Adaptive aims adjusts codec parameters such as buffer sizes and bit rates to minimise latency while still using Bluetooth and thus being compatible with standard Bluetooth hardware.

You could like, watch the video, it mentions how his videos have out of sync audio.....

I think audio devices changing automatically incur a resync.

yes, every video sadly! >Sean

repetition where

Just bad editing. Looking at the first example in a video editor, the audio IS coming very slightly before the video, but I beleive its zoomed out enough from his face that your brain doesn't really care. In the second example, for the first half, the audio is actually before the video, and it switches to coming after at about the halfway mark. I suspect the sudden switch makes the dissonance even worse.

I immediately noticed both times, I tend to pay attention to it because I've frequently had to manually adjust it on video streams.

coming soon! >Sean

Bluetooth has a limited bandwidth, limited amount of data, so the audio is compressed to fit. It's unfortunate and very annoying. It's like using cassette tapes in 2023.

Your on a human time scale, orders of magnitude from computer scale precise timing. I just pinged some servers, I am near Tacoma [north west] USA: my router 6ms, next town 18ms, East coast USA 80ms, Amsterdam 158ms, some car dealer in South Africa 350ms(all 10 hits between 341 and 357ms, zero packet loss) All of these times are round trip. Your NPT time sync is not a precise time tool, likely only rated for +-one second.

It would have been better to show him do things that make noise, like bounce a ball, clap, ...

Coming soon... >Sean

/me patiently waits... :-)

wondering that too.. that got my full attention

Tomorrows World?

I guess the problem comes when you start to care about lost packets and include a buffer - you could be right though that after the initial pause to fill the buffer up there might be no delay necessary. The sync problem with cheap headphones might come from bad connectivity and buffer issues? I also wonder how cinemas solve this issue with people having various distances to the screen and speakers and it still needs to be in sync - seems like even larger times than 3ms are still not an issue.

Oh yes, totally agree that the issue must be with the buffer. My comment was because big part of the video focuses on the "right" way to sync. From my personal experience projecting in small auditoriums, it's a non issue at all, even at 10 mts form the speakers.

A better example of this is if you are in a (large) movie theatre watching a movie, or you're in a concert hall. In those cases you may be over 30m from the screen or stage if it's a large auditorium which is nearly a tenth of a second. Funnily enough I've never perceived an audio delay in such a real life circumstance but if you attend a basketball match, you definitely hear the bounce of the ball after you see it.

I think you're misunderstanding something. Radio waves, for the purposes of Bluetooth, take zero time to travel the distance to the headphones. Radio waves move at the speed of light and pass through solid objects, meaning the only delay comes from the transmitter encoding the audio into a Bluetooth signal, then the headset decoding it back into sound after a handshake. This process takes between 30 and 100ms depending on how up to date your Bluetooth equipment is. The delay introduced by walking a meter or two farther from your TV is a fraction of a nanosecond, something barely even measurable, so it doesn't affect the audio at all. The device you're using can determine roughly the delay it should use based on the version of Bluetooth it and your headphones are equipped with as well as the delay in hand-shakes between devices.

It's possible that all the people saying this are currently using headphones with high-ish latency.

Timestamps are only part of the puzzle. They set out definitively how the audio and video sync up inside the source video. But then upon playback it's up to the playback equipment to make sure the video and audio match the sync in the file, as defined by those timestamps. And that is the subject of this video.

Of crap, it wasn’t supposed to be about of sync but it was for me haha

I never experienced that starting and stopping at my PC. Not with Windows and not with Linux. And I've been using Bluetooth headphones for years - crappy ones and higher quality ones. This has to be a Apple thing.

justWorks™

Some delay is expected by the human brain, so some (all?) video recordings may sync with 20 or so ms delay ElectroBoom just did a video on this! :D So I guess the PC can just resync the video audio as you press play, where as Apple instead resync the *video*?

The pausing really has to be a bad software implementation on Apple's side. I'm using pulse audio on a Linux system (my "media center") to send audio over the network to a raspberry pi, which itself uses an USB audio decoder to send it to the amplifier. Even with that setup (non of the components are "made for each other"), I've never seen a delay that noticeable in any of the players I use (VLC, or Firefox playing a youtube video for example).

having worked with apple devices for the past 2 years, bad implementations don't surprise me at all. I really don't know how Apple obtained the image of "just working". In my personal experience, it's pretty much the opposite

Bluetooth audio mostly doesn't benefit from anything post Bluetooth 3.0 because it uses Bluetooth Classic and most , but not all, enhancements to the Bluetooth spec since 3.0 have been to Bluetooth "smart"/"low energy". It does in theory benefit from the improved receiver and transmitter design of recent versions but I don't think the actual air protocol has changed.

It's because the television signal is deliberately delayed so that in the event anything happens that is "unfit to air" (like streaking or something), it can be caught and prevented from airing. Since radio is purely sound, it isn't covered by those rules.

Yes, that sounds true. So, they must not fear the radio listeners, for some reason (because they are fewer people, I guess?) :) Okay, streakers are less of a problem for radio. I understand that

As a Bluetooth application aptx has similar latency to ordinary SBC. I guess it had to be tuned for the reliability environment of Bluetooth transmission in a noisy (RF) environment.

What? You're comparing Apples and Bananas here.

Bluetooth overdose.

Your typing is not in sync.

Almujtaba Osama Proximity sensors.

Hahahaha

Bluetooth audio devices always cut out and lose connection, or just seem really buggy and flakey in operation. I have better luck with GPS devices and they work fine.

England is my country

LOL.... you're suppose to say it wrong... xD

Well, london is 8.78 millions people's city

Free service.

3