Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#10642 closed Bug Report - General (Won't Fix)

Audio stops/starts/seeks a second after video

Reported by: Josh Triplett <josh@…> Owned by: JYA
Priority: major Milestone: unknown
Component: MythTV - General Version: 0.25
Severity: medium Keywords:
Cc: Ticket locked: no

Description

In 0.25, when pausing, unpausing, or seeking in a recorded show or live TV, the video pauses/unpauses/seeks instantly, but the audio takes a second or so. This proves particularly problematic when unpausing or seeking, because it effectively leaves the video muted for the first second or so, causing users to have to rewind a bit to hear the audio.

I did not observe this problem in 0.22.

Change History (7)

comment:1 Changed 12 years ago by JYA

Are you using HDMI?

HDMI can take a little,while to get a lock on. Especially when using digital audio

Nothing to do with myth, and all to do with the amplifier used.

comment:2 Changed 12 years ago by JYA

Owner: set to JYA
Status: newassigned

comment:3 Changed 12 years ago by Josh Triplett <josh@…>

No. This occurs both on laptops (with built-in video and audio) and on dedicated MythTV frontends (using VGA/DVI and a separate headphone-style audio cable). This represents a regression from 0.22, which paused/resumed/seeked audio in sync with video.

comment:4 Changed 12 years ago by JYA

Status: assignedinfoneeded

So please provide details.. Audio settings, version of myth used, computer used.

I certainly have never seen this on any of my machines, and you would think that if it was a global issue, we would have heard about it.

0.22 was released a very long time ago... so whatever it did is of little relevance. I doubt you are running the same hardware/OS as you did when you were using 0.22

comment:5 Changed 12 years ago by Josh Triplett <josh@…>

So please provide details.. Audio settings, version of myth used, computer used.

Audio settings: ALSA:default and the stock MythTV defaults. I've tested with a completely fresh set of client settings and still encountered the problem.

MythTV 0.25.

Client: ThinkPad? X220, ThinkPad? T42, custom frontend with an Intel D945GSEJT Atom board, take your pick. They all have some variation of an Intel HDA audio chipset.

I certainly have never seen this on any of my machines, and you would think that if it was a global issue, we would have heard about it.

This represents a subtle issue; if you didn't otherwise have reason to pay close attention to the audio, you could easily not notice it. You'll notice it more easily if it takes your setup a longer time to seek, pause, or unpause. Effectively, the video starts changing immediately, but the audio doesn't switch over until after the video finishes changing. So, however long it takes to seek, the audio that would have played if you hadn't seeked will play while you seek. In former versions of MythTV, the audio would instead immediately stop playing while the operation happened, and start back up again with the correct audio after the operation finishes.

I doubt you are running the same hardware/OS as you did when you were using 0.22

Exactly the same hardware; OS upgraded from Debian 5 to Debian 6.

comment:6 Changed 12 years ago by JYA

Resolution: Won't Fix
Status: infoneededclosed

I see...

We add to reset the audio buffer as otherwise, audio corruption could occur under some circumstances...

comment:7 Changed 12 years ago by Josh Triplett <josh@…>

Sure, that makes sense. However, could you mute the audio at the start of an operation, and unmute it afterward? Or, could you avoid transitioning the video until the audio had finished transitioning? The oddity occurs because the audio and video transitions occur at noticeably different times.

Note: See TracTickets for help on using tickets.