Hacker News new | past | comments | ask | show | jobs | submit login

If it was buffered and you changed track on your phone, you would then have to wait 15-20 seconds for the track to change as it would playing from the buffer.

I guess if it was 2 seconds it might be more bearable.




I think OP meant to pre-send music and keep the next 15 seconds available locally. This way you can handle 15 seconds of interruption.

So, when you start streaming music, it starts playing immediately, but it tries to send data faster than it is played until you have a decent buffer. Obviously, this would only work for non-realtime things.


Not if it honored an "invalidate buffer" command.


Increase the size of the buffer to N > 1 songs and allow the device to tell the headphones to skip ahead in the buffer. If "next song prediction" is hard (e.g. the user is clicking around their library), support a device "burst push" mode that lets the device send the first M seconds of a song very quickly.

On a side note, it's interesting that this buffering problem is identical with switching channels on any streaming service, and that the buffering delay is a significant psychological barrier to moving around, and that traditional radio works really friggin' well for what it does.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: