Resynchronize after "Drop chunk"

[kolorafa]

After device get a "drop chunk" message in log, audio is getting desynced, it's not a problem if the devices are far away from each other, might not even be noticable, but I would like to aim for perfection :)

I'm playing on two devices going into single mixer/speakers, it generate sound that you can hear if the sound is not in sync. Using audacious, pulseaudio nullsink to stream.

The easiest way to achive dropped packages/desync is to seek a song, it will jump a lot in short period of time and the log generate dropped chunks with negative timestamps:

Drop chunk: q_len=25 delay=-17.573ms < 0. tolerance=-15.000ms: P=1.34
Drop chunk: q_len=24 delay=-17.651ms < 0. tolerance=-15.000ms: P=1.35
Drop chunk: q_len=23 delay=-17.680ms < 0. tolerance=-15.000ms: P=1.36
Drop chunk: q_len=22 delay=-17.710ms < 0. tolerance=-15.000ms: P=1.36
Drop chunk: q_len=21 delay=-17.738ms < 0. tolerance=-15.000ms: P=1.37
Drop chunk: q_len=20 delay=-17.766ms < 0. tolerance=-15.000ms: P=1.37
Drop chunk: q_len=19 delay=-17.794ms < 0. tolerance=-15.000ms: P=1.37
Drop chunk: q_len=14 delay=-80.058ms < 0. tolerance=-15.000ms: P=9.67
Drop chunk: q_len=13 delay=-40.168ms < 0. tolerance=-15.000ms: P=4.36
Drop chunk: q_len=12 delay=-40.198ms < 0. tolerance=-15.000ms: P=4.36
Drop chunk: q_len=11 delay=-40.224ms < 0. tolerance=-15.000ms: P=4.36
Drop chunk: q_len=10 delay=-40.250ms < 0. tolerance=-15.000ms: P=4.37
Drop chunk: q_len= 9 delay=-40.247ms < 0. tolerance=-15.000ms: P=4.37
Drop chunk: q_len=14 delay=-17.093ms < 0. tolerance=-15.000ms: P=1.28
Drop chunk: q_len=13 delay=-17.171ms < 0. tolerance=-15.000ms: P=1.29

The way to synchronize sound is to pause playback until all devices stops (empty their queue), and resume.

This efect sometimes also occur when changing songs. (I use a fadein and out in audacious, so songs gets mixed (fade in/out) while changing/stoping/starting that might be also a factor)

https://www.dropbox.com/s/zillhil667riybq/desync.mp3?dl=0
^
0:33 - 0:44 desynced
0:44 - 0:45 paused
0:45 - 1:00 synced
1:05 - 1:08 seeking
1:08 - 1:24 desynced
1:23 - 1:26 phone vibrated :D
1:25 - 1:36 synced
...

Thanks for your fast reaction with python problem :)

[blaa]

The thing that fixes the synchro is "silence detection". With fade it won't work though. And it shouldn't be necessary to have synchronised playback. You can reduce the silence detection time to let it kick in more often.

I started work on time-of-stream branch which should fix problems with jumping tracks, and possibly more. i hope to have it done next week top.

The only probable, other cause, which might be harder to fix is the output buffer. I was thinking about generating silence to force a constant pressure on it.

Thanks for heads up. I'll look into it.

[blaa]

time-of-stream branch has something semi-usable with this fixes. Didn't loose the synchronization on stops and song searching/jumping (player was mocp).

Did loose synchro when I stopped (ctrl+s) player for a while before releasing it (ctrl+q) so I have a further benchmark.

So - if in the mood it's a testable BETA. Next week I'll try to finish it up and publish as 2.0

[blaa]

I've published this as 2.0 some time ago - you can try rechecking how it works right now. There still might be a need for some additional changes.