Allow customizable delay

[ysaliens]

You already have a toggle that adjusts for bulb delays.
Make this a slider or make the user able to input a number (leave the default to what you currently use).
This may be helpful for different networks and advanced users.

[saites]

I've considered this before, and implemented it at one time to play around with. In my experience, it leads to a lot of fiddling without a lot of benefit, because there are several places where non-deterministic delays are introduced:

• the beat detection itself is of course a best guess -- this by far has the biggest impact on perception of synchronization
• Android can context-switch between when the app determines it should dispatch and when it actually does
• Android buffers network packets
• the network infrastructure introduces unpredictable delays
• the bulbs themselves do a small amount of buffering and require time to process messages
• sometimes packets are just dropped by the networking hardware
• physical interference can prevent messages from being received properly

I found that when I had the ability to modify the dispatching position relative the music, I never felt satisfied I had found "the" value to make perfect synchronization, and so I think giving it as an option is likely to hurt user experience.

To make this all more complicated, synchronizing music and light isn't just a physics/engineering problem -- it's a psychoacoustic problem. There are funny things that human brains do regarding perception of multimodal signals.

Looking it up now, it seems experiments in the broadcasting industry have determined the thresholds for detectability of synchronization of sound and vision are about +45ms to -125ms (PDF), which is to say that if an audio signal arrives between 45ms before up to 125ms after a visual signal, the brain is likely to perceive the events as simultaneous (it's more complicated than just that, but it's a good model to start with).

This suggests I should bias my message dispatch in the positive direction -- dispatch the light signal ahead of the expected sound impulse. If I attempted to dispatch it 125ms ahead of the expected audio impulse, and it somehow instantly caused the bulbs to change state, it would still be within the threshold of synchronization perception. However, we know it will be delayed by the processing and hardware in between, but dispatching it early would mean it could be delayed as long as 170ms and still be within the threshold.

I will play with this sometime soon.