[vlc-devel] Fixing long latency audio outputs like Airplay
david.fuhrmann at gmail.com
Sat Jun 27 10:12:36 CEST 2015
> Am 21.06.2015 um 23:31 schrieb Rémi Denis-Courmont <remi at remlab.net>:
> Le dimanche 21 juin 2015, 18:00:05 David Fuhrmann a écrit :
>> The problem is that (the original) Airplay specification defines a fixed 2
>> seconds latency for each audio device. Additionally, the auhal audio output
>> has an internal buffer, which adds more delay. While we can try to keep the
>> second latency down to a small value, we need to cope with a audio latency
>> of some value slightly bigger than 2 secs in some way, to support Airplay.
> Currently the audio output cannot specify its latency requirements to
> upstream. Audio output latency is generally assumed to be 40 milliseconds or
> less. This is probably not easy to fix, as it probably affects ES output, clock
> and decoder buffering.
Thanks for the input, Remi. I understand that it likely takes more effort to properly support it. What do you exactly mean with latency requirements? From my understanding, the current latency is already reported by time_get. Do you mean reporting an expected latency value beforehand, to adapt buffer sizes or whatever beforehand?
Where is this 40 ms value hardcoded / incorporated?
Additionally, I’m asking what the difference is between the current audio sync option and the aout latency. Maybe the former can be used to mitigate the problem? Before VLC 2.2, the user needed to set the -2000ms shift by hand, and this seems to work fine even for higher shifts.
Still, increasing input cache helps already, according to various reports. Thus I still wonder if it makes sense, to help users by setting a sensible value by default, or by informing the users about increasing the input cache, over whatever ways.
More information about the vlc-devel