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

[MythTV]

#850: Inaccuracies in audio timecode calculations
-------------------------------------------+--------------------------------
 Reporter:  mythtv at dadeos.freeserve.co.uk  |        Owner:  ijr 
     Type:  defect                         |       Status:  new 
 Priority:  minor                          |    Milestone:      
Component:  mythtv                         |      Version:  head
 Severity:  medium                         |   Resolution:      
-------------------------------------------+--------------------------------
Changes (by mythtv at dadeos.freeserve.co.uk):

  * version:  => head

Comment:

 Mark,

 Thank you for taking the time to investigate my patch.

 I am happy that your testing revealed no noticeable change in the
 behaviour of the 2 algorithms, I hope that this indicates that my patch is
 working correctly; video playback was working correctly for me before I
 developed the patch. The original bug I set out to resolve was the
 indicated playback position for tracks played from within MythMusic.

 Through my investigation I discovered the root cause of that fault to lie
 within the "AudioOutputBase" class and the way that it keeps track of the
 current playback position ("AudioTime"), which is basically achieved by
 accumulating the time in milliseconds represented by each buffer of audio
 submitted to the class via one of the "AddSamples" member functions. The
 audio timecode represented by the last sample stored in the audio cyclic
 buffer ("audiobuffer") is accumulated into the "audbuf_timecode" member
 variable by lines 626 through 633 of the original code:-

 {{{
     if (timecode < 0)
         timecode = audbuf_timecode; // add to current timecode

     /* we want the time at the end -- but the file format stores
        time at the start of the chunk. */
     // even with timestretch, timecode is still calculated from original
     // sample count
     audbuf_timecode = timecode + (int)((samples * 100000.0) / effdsp);
 }}}

 For video playback (I am based in the UK with a DVB-T setup):-

 Audio is 16bit, stereo, at 48000Hz[[BR]][[BR]]
 timecode = is always provided (i.e. is positive)[[BR]]
 samples = (in my testing at least) was always 1152[[BR]]
 effdsp = 100 * audio_samplerate[[BR]]
 [[BR]]
 audbuf_timecode = timecode + (int)((1152 * 100000.0)/(100 * 48000)[[BR]]
 audbuf_timecode = timecode + (int)(24)[[BR]]

 As such everything works as expected.........

 Now for audio playback in MythMusic (playing FLAC encoded CD tracks):-

 Audio is 16bit, stereo, 44100Hz[[BR]][[BR]]
 timecode = is not provided (i.e. is "-1")[[BR]]
 samples = (in my testing at least) was always 512[[BR]]
 effdsp = 100 * audio_samplerate[[BR]]
 [[BR]]
 audbuf_timecode = audbuf_timecode + (int)((512 * 100000.0)/(100 *
 44100)[[BR]]
 audbuf_timecode = audbuf_timecode + (int)(11.60997732426303855)[[BR]]

 As such, each audio buffer provided to the AudioOutputBase class is
 actually approximately 0.6 milliseconds longer than it is given credit for
 resulting in the misreporting of playback position within MythMusic (which
 is based upon the figures provided by the AudioOutputBase class).


 The "int" to "long long" return type from the "GetAudioTime" function was
 a change that I noticed along the way, and thought I would fix it as it
 might have strange ramifications that might otherwise be hard to replicate
 and fix.

 My patch is an initial attempt to rectify the behaviour of the
 AudioOutputBase class for the situations within which it is currently
 being used. I would like to take an opportunity to reconsider its current
 interface, possibly make some changes, and document the whole thing. But
 as I have said, this patch was my first attempt at contributing to the
 MythTV project and I didn't want to propose any major changes until I
 understand more about the context within which this code operates. I have
 some experience of writing audio processing code, I write soundcard
 drivers for a living, but I am less familiar with the video decoding and
 corresponding syncronisation issues.

 It is probably possible to rectify the MythMusic behaviour without
 touching the existing mechanism for reporting timecode for the video
 playback case. I would not be surprised if the video playback case always
 arranges that the audio buffer supplied to the "AddSamples" function
 consists of an integer number of milliseconds worth of data. But as this
 was beyond my knowledge and I always consider it to be good to avoid any
 such assumptions where at all possible I proposed the alterations I have.

 Best regards

 Peter

-- 
Ticket URL: <http://cvs.mythtv.org/trac/ticket/850>
MythTV <http://www.mythtv.org/>
MythTV