[vlc-devel] Core audio S/PDIF output with latency calculation

[David Fuhrmann]

Hi Remi,

Am 11.03.2013 um 11:08 schrieb Rémi Denis-Courmont <remi at remlab.net>:

> On Sun, 10 Mar 2013 18:05:36 +0100, David Fuhrmann
> <david.fuhrmann at gmail.com> wrote:
>> With this more generic approach, the result would make sense in any
> case,
>> also in the case that the length calculation might be changed elsewhere,
>> later on.
>> Opinions about that?
> 
> Unfortunately, the length of a packet is not necessarily the sum of the
> length of the packets that it was synthetized from. Rounding errors occur
> since 48000 is not a divisor of CLOCK_FREQ.

Of course they are rounding errors, in several audio_filter modules which recalculate i_length I suppose. And these errors will be more significant if i_length values are summed up. For 3 values, it will not really matter much, IMHO.

In the auhal plugin, we are summing up much more i_length values. If you want to say that these rounding errors really matter over time, the data type size of i_length would need to be increased (so it can store values < 1 us), otherwise i_length will be quite useless, at least for its current use in the auhal plugin.

> See date_t usage in most codecs and some demuxers for a proper way to
> compute the length.

The dtstospdif converter is not a decoder, it just copies blocks around and prepends S/PDIF headers. It does not seem to be designed to interpret the DTS data on its own. So they is no real possibility to calculate a more accurate i_length than just using the input i_length values, as far as I understand.

As a side note, even the a52tofloat32 and dtstofloat32 converters, which do interpret the data, are not setting i_length according to the data, but just using the input i_length value.

Best regards,
David