Latency on playing sounds to external bluetooth speaker

[trevix]

OSX 10.14.6 LC 9.5.1RC1 iOS12.9
I have a stack were a player, given a path, should play a short sound (less then 1 seconds) trough an external bluetooth speaker.
Most of the time the beginning of the sound gets cut off. Often you can barely hear the end of it.
Long sounds play fine, but the beginning get often cut off too, unless there is some silent in the beginning of the sound file.
But putting silent time in front of my sounds, would make the user experience pretty bad...

Is there any solution to this?
Is it because the speaker is a cheap one ($16,00) or else?

This happens both on development on the Mac and on the standalone, uploaded to an iPAD.

[bogs]

Is there any solution to this?

To me, it sounds like typical wireless latency. Bluetooth is convenient, the trade-off is of course stability/speed.

Is it because the speaker is a cheap one ($16,00) or else?

If you are just describing the time it takes for typical wireless latency, then the cost of the device isn't going to matter as much as the receivers specs. Some cheap devices are as fast (or faster) than some more expensive devices.

[trevix]

Thanks.
But this makes me think:
- The speaker/receiver start handling data when receiving a bluetooth msg
- the OS of the sender (desktop or mobile) should transmit everything it receive from the App that generate data to be transmitted
- is any chance that the LC "player" is not acting properly on this?

What I mean is that the receiver should handle ALL the data it receive, albeit with a latency of whatever milliseconds. Otherwise if instead of sound the transmitter send string of data, something would be missing on the receiving end

[Klaus]

The LC "player" is OK, it is the "bluetooth" protocol itself which causes the latency!
Check the net with Google for an explanation.

[jacque]

This reminds me of a similar problem I had years and years ago. Very short sounds simply wouldn't play. Using a sound editor, I had to add a second of silence before the sound actually started. It doesn't have anything to do with Bluetooth or the speakers, the problem was in the LC player control itself.

That was many years ago so things may have changed by now, but your experience is exactly what I saw. You might want to enter a bug report about it. I don't know why it happens, but my guess it has has something to do with the amount of time it takes a player to load a sound file.

If the problem were just latency, I'd think the beginning of the sound would play but it would be delayed. If the beginning is totally missing then it's something else. Does the sound play correctly on your computer?

[bogs]

This reminds me of a similar problem I had years and years ago. Very short sounds simply wouldn't play. Using a sound editor, I had to add a second of silence before the sound actually started. It doesn't have anything to do with Bluetooth or the speakers, the problem was in the LC player control itself.

I made some assumptions when I posted my answer, but there is a way to test whether or not it is hardware or software related.

If you run the app through the devices wired speakers (I don't think you can plug in headphones anymore, right?), and the sound starts and stops on que, then it is not a player issue, otherwise it would be chopped off at all times.

IF on the other hand, it is playing chopped off on the hardware itself, then you might suspect the player control or code.

[trevix]

On the hardware, sounds play fine.
If I add 1 seconds of silence in front of the sound file, the sound play fine over bluetooth.

- If instead of a short sound, that gets chopped, I transmit over bluetooth a packet "1,2,3", does that means that the receiver will receive only "2,3"?

- Isn't error correction implemented in bluetooth so that what is transmitted get received?

- So, should I assume that when I transmit a short sound, the receiver speaker wakes up, but then the first part of a stream of packets is already gone?

[Thierry]

Hi Trevix,

Why you're not testing playing your sound with another music app, but not LC ?

If this sound is played perfectly on the same device over bluetooth
then you'll have some useful information...

My 2 cents,

Thierry

[trevix]

Easy done with system sound:
they get chopped!

So, it is either the bluetooth speaker or the bluetooth version.
Thanks

[bogs]

On the hardware, sounds play fine.
If I add 1 seconds of silence in front of the sound file, the sound play fine over bluetooth.

To me, this eliminates the player control being the issue, as I said earlier. Your working with Mac stuff, but this kind of problem certainly isn't limited to Mac equipment, as you can see here, nor is it solely a latency issue, it is far more often a synchronization issue between the OS and the BT device.

- If instead of a short sound, that gets chopped, I transmit over bluetooth a packet "1,2,3", does that means that the receiver will receive only "2,3"?

Depends, although I'm not sure what kind of BT device would take a string. I know keyboards can transmit a string, but what would receive one?

- Isn't error correction implemented in bluetooth so that what is transmitted get received?

Again, depends. Error correction could be left to the programmer, much as Jacque pointed out by using a slight delay in transmission to overcome the chop off.

- So, should I assume that when I transmit a short sound, the receiver speaker wakes up, but then the first part of a stream of packets is already gone?

I wouldn't lay all of this on the speaker. Some of it falls on the BT itself, some on the implementation, some on the receiver. There are general guidelines for trouble shooting pairing issues, the first thing almost always suggested is restarting the connection between the two devices.

Also as I said previously, you may wind up testing other receiver devices, I've personally noticed some are better than others, just not based on price. However, if your planning to release an app to the public in general, keep in mind that most people aren't going to have or use exactly what you have or use.

I also wonder if there isn't a better way to introduce the delay through code? Like, for instance, starting the transmission early on in the code before transmitting the sound. It may be that sending a silent sound to the device at the beginning of the handler may be enough to 'wake it up' before the actual sound goes out, there by eliminating the chop off. Something like (psuedo code) -

Code: Select all

on yourSoundHandler
	-- first line of code in the script sends a silent sound *of no length or minimal length* (like 1 ms of sound) to your speaker...
	-- do your script stuff that precedes the actual sound you want sent...
	-- send your actual sound to the speaker...
end yourSoundHandler

Or better yet, send the silent sound to the speaker from the handler calling your routine just before calling the routine to wake the speaker up. Something to try, anyway.

[trevix]

I tried sending 2 sounds in a row but it does not work.
There not seems a way to fool the speaker.
I tried several variation, like this one:

Code: Select all

set the filename of player "Settingsplayer"  of this card to TheSoundPath
          put (the duration of player "Settingsplayer"/the timeScale of player "Settingsplayer")*1000 into totMilliseconds
          start player "Settingsplayer"
          wait totMilliseconds milliseconds with messages
          start player "Settingsplayer"

I think that the second sound just overlap the first being sended, but still does not play the beginning of itself.

The only thing that works is an empty sound in the beginning of the same sound file, but not all the time: somehow the speaker, after an interval of 8-10 seconds between sending sounds, again cuts off the first occurrence. It may have to do with "going to sleep" in order to save batteries? (before you ask, there are no setting for this on the speaker)

[bogs]

It may have to do with "going to sleep" in order to save batteries? (before you ask, there are no setting for this on the speaker)

Heh, never entered my mind

I think that the second sound just overlap the first being sended, but still does not play the beginning of itself.

Huh, I certainly didn't expect that, as far as I know, Lc player can only play one sound at a time and ...

somehow the speaker, after an interval of 8-10 seconds between sending sounds, again cuts off the first occurrence

I would have thought the first sound sent would kickstart the connection, so it would be ready by the time the 2nd sound came along. Interesting that it does not

[Klaus]

Code: Select all

...
start player "Settingsplayer"
wait totMilliseconds milliseconds with messages
start player "Settingsplayer"
...

If you start an already "playing" player a second time, nothing will happen at all.
It does not start again from the beginning of the movie/sound, if that is what you exspect.

[bogs]

If you start an already "playing" player a second time, nothing will happen at all.

No, I was actually thinking that the player would start a sound of almost no time either at the beginning of a handler or in the referring handler which would certainly be cut off at the speaker but which would activate the connection to the speaker 'waking it up' as it were, so that the 2nd (desired) sound would play from the beginning without the 1 second cut off, I am not talking about the wait command.

If the first sound played is 1 to a couple of milliseconds long, it should be finished before the actual sound you want to play gets called to start, which would certainly happen with in the 8 or so seconds trevix is saying the connection plays without chopping off the 1 second of sound.

...somehow the speaker, after an interval of 8-10 seconds between sending sounds, again cuts off the first occurrence.

Hopefully, that clears up the thoughts I had a bit.

@ trevix - it looks like you are coding what Klaus said in a way, using a fraction of the same sound to rig it. I don't think that would work.

On 'nix, the player object is a mixed bag as to whether you'll hear sound or not, I'll have to rig up a test on Windows I guess to trace through what I am thinking. Of course, I don't have any BT devices handy to test out with, but I'll post the script if it works out on real hardware and put it up here so you can see what I am talking about.

[bogs]

After I wrote the last post, I realized I can't test my theory for your problem because I have no way to set up an environment to do so, i.e. Mac osx and iOs. Sorry for that.