[mythtv] [mythtv-commits] Ticket #850: Inaccuracies in audio timecode calculations
mark at dclabs.com.au
Wed Jan 18 21:33:51 UTC 2006
> When so much of the code within that class is dedicated to ensuring that
> the timecode produced is very accurate (with going to the lengths of using
> a high resolution timer to estimate the soundcard’s position based upon
> elapsed time since the position was previously reported). I don’t under
> stand why the solution that was merely ‘more’ accurate then the
> existing code, especially when an implementation that is completely
> accurate has been provided.
> If you can express some details regarding your apparent objections to my
> proposed modifications then I would be happy to attempt to address your
> I’d also dispute that it’s an “enhancement”; it’s a bug, it’s
> not a serious bug (at the moment), but it definitely a bug.
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.
More information about the mythtv-dev