Opened 13 years ago
Closed 13 years ago
Last modified 13 years ago
#10642 closed Bug Report - General (Won't Fix)
Audio stops/starts/seeks a second after video
Reported by: | 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 13 years ago by
comment:2 Changed 13 years ago by
Owner: | set to JYA |
---|---|
Status: | new → assigned |
comment:3 Changed 13 years ago by
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 13 years ago by
Status: | assigned → infoneeded |
---|
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 13 years ago by
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 13 years ago by
Resolution: | → Won't Fix |
---|---|
Status: | infoneeded → closed |
I see...
We add to reset the audio buffer as otherwise, audio corruption could occur under some circumstances...
comment:7 Changed 13 years ago by
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.
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.