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

Mark Spieth 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
> concerns.
>
> 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.

cheers
mark 



More information about the mythtv-dev mailing list