Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#8500 closed patch (fixed)

more accurate audio timestamps

Reported by: Mark Spieth Owned by: JYA
Priority: minor Milestone: 0.24
Component: MythTV - Audio Output Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no


with the inclusion of hdaudio, timestamps are not that accurate, and delay is not enough for various media like some dvb.

patch addresses

  1. 2.6 sec worst case delay, needed for 32 bit 6ch output.
  2. race condition in lockless audio timestamp calculation.
  3. guarantee int64 for various critical parameters in audio ts generation.

only tested with alsa so far.

Attachments (3)

accurate_audiots.patch (21.9 KB) - added by Mark Spieth 11 years ago.
accurate_audiots.2.patch (23.8 KB) - added by Mark Spieth 11 years ago.
with reset race fix
accurate_audiots.3.patch (24.0 KB) - added by Mark Spieth 11 years ago.
with timecode wrap fix

Download all attachments as: .zip

Change History (10)

Changed 11 years ago by Mark Spieth

Attachment: accurate_audiots.patch added

Changed 11 years ago by Mark Spieth

Attachment: accurate_audiots.2.patch added

with reset race fix

comment:1 Changed 11 years ago by Mark Spieth

also existed a race when seeking and audio is reset. can cause 2 secs of old audio to be played before new audio. patch 2 fixes this too.

also see #7964

comment:2 Changed 11 years ago by JYA

The whole concept of the lockless audio framework was that timecode would be calculated in one thread only, not two (read and write). It's the reason why SetAudioTime? was removed this patch breaks that, without having any of the required lock.

There is no need to increase the size of the audio buffer by a factor of 2, it will only cause seeking delays. Where does that requirement of 2.6s delay comes from?

yes, there is a "race" in audiotime calc, but the worst case error is negligible.

Will try to implement your timecode calculation cleanly and neatly soon.

comment:3 Changed 11 years ago by Mark Spieth

understood. however the part that needs to be lockless is only modifying the ringbuffer pointers. the storage in the other process components is only modified in AddSamples?. Thus these latencies are static and can be excluded from the lockless component as they can be precalculated. This also makes GetAudiotime? faster as it doesnt have to include these latencies. audbuf_timecode becomes the top of the ringbuffer, not the latest timecode of the added audio data.

1.3-1.4 secs is marignal avsync delay for 6ch audio out. with the increase of bytes per sample to 4 (float32 due to processing enabled, upmix+timestretch), all that the increase does is maintain the worst case storage. it doesnt work properly otherwise. could go to a dynamic. the number is also that to make sure it is divisible by all the possible alternatives, including 8 ch out.

for smooth sync to work correctly, the race is very important.

Changed 11 years ago by Mark Spieth

Attachment: accurate_audiots.3.patch added

with timecode wrap fix

comment:4 Changed 11 years ago by Mark Spieth

patch 3 also with timecode wrap fix which happens for dvb timestamps.

comment:5 Changed 11 years ago by robertm

Status: newassigned

comment:6 Changed 11 years ago by JYA

Resolution: fixed
Status: assignedclosed

(In [26255]) more accurate audio timestamps. Patch by Mark Spieth. Improve A/V Sync. Closes #8500

comment:7 Changed 11 years ago by stuartm

Milestone: unknown0.24
Note: See TracTickets for help on using tickets.