[mythtv] Ticket #850: Inaccuracies in audio timecode calculations

[Peter Stokes]

> my argument (valid or not) is this:
>
> I have the viewpoint that using anything but the existing content of all
> buffers at the time of measurement could go astray. dead reckoning (your
> implementation) does not do this. I also want to reduce the load on the
> timestretch bit which runs more often than it needs for which I have an
> idea
> to move that component to _AddSamples.
>
> secondly it does not address seeking in mythmusic and keeping the time
> index
> reported correct. not that my proposed solution does that anyway.
> mythmusic
> would need to change to generate these at the source. once these exist
> they
> can be passed to the output layer for synchronisation purposes. any other
> solution would be temporary until this can be addressed.
>

Mark,

Sorry, I have only just noticed that you had moved the discussion over to
the dev list (and hence I have only just read your objections to my proposed
modifications....)

It was some time ago that I worked on these changes and am now struggling to
remember all of the intricacies of behaviour of the existing code.

I accept most of your concerns regarding the 'dead reckoning' approach
contained within my patch. I do not consider it to be an ideal, long term,
fix. I felt that the changes necessary to correct this issue were too
invasive to propose as my first modification.

I guess my 'argument' would be that the 'dead reckoning' approach wonders a
little during periods of fluctuation (specifically in situations where the
timestretch factor is adjusted) but then always finds the correct value (at
least for the case of video playback, where the audio systems appears to
form a closed-loop control system with the video decoder, by means of the
reported timecode). Where-as any miscalculations due to the rounding errors
present in the existing approach will accumulate in an uncontrolled manor
over time. (This argument is perhaps academic if the video code always
provides blocks of audio samples amounting to an integer number of
milliseconds).

When I get a chance I'd like to look into how the MythMusic code works,
because seeking timecodes appeared to work during my testing. A fact that I
was a little surprised at and which led me to conclude that it must be do at
least some calculation of the current timecode itself.

IMOH I don't think that such complicated timecode calculations belong in the
audio system. The audio system should provided an accurate representation of
how much data it has consumed and where it is currently at, which may be
used as a reference of real-time, but it shouldn't be asked to provide video
timecodes; surely such code should sit in the video decoder (which has
knowledge of seek events etc.)?

Perhaps we could work together to come up with a system that will meet the
requirements in a more robust manor than the existing code? (I didn't want
to embark on proposing more invasive changes, only to find someone else is
currently re-writing the audio system).

Best regards

Peter

P.S. May I request that you to cc my email address on any reply, so that I
don't miss it?