[MPlayer-users] mplayer alsa behavior playing video vs audio.
adf.lists at gmail.com
Fri May 2 22:20:04 CEST 2014
Reimar Döffinger wrote:
> On 02.05.2014, at 17:30, Andy Furniss <adf.lists at gmail.com> wrote:
>> This is just out of curiosity really, not an mplayer bug.
>> I've just got a new GPU and there is am audio over HDMI bug
>> (already reported by xbmc users).
>> The thing is I can't reproduce it when playing video with s/w
>> The bug is garbled sound - mplayer does produce with -
>> audio file video file -vc null (but not -vo null) video file uvd
>> The outputs and alsa hw params look the same for working and not
>> working cases.
>> So, the question is what is the difference from mplayers point of
>> view when playing to alsa
>> mplayer -ao alsa:device=hw=1.3 a wav file mplayer -ao
>> alsa:device=hw=1.3 a video with -vc null
>> mplayer -ao alsa:device=hw=1.3 a video
>> any thoughts, eg. does the timing come from somewhere else?
> When playing audio-only, MPlayer will query the driver for how much
> time it has data buffered and sleep for (more or less) that amount of
> time to avoid unnecessary power consumption. When video is enabled,
> it has to always wake up for new frames. However the results with UVD
> make no sense for that explanation, in fact it makes it more sound
> like e.g. a reclocking issue. Did you try running e.g. glxgears or
> some other 3D program while playing an audio-only file?
Thanks for that, it does seem that glxgears helps but doesn't cure.
Without it a music track sounds like it's stuck playing a portion + a
lot of extra noise/distortion and sometimes progressing a bit after many
With glxgears running free (vblank_mode=0) it helps in that the track is
at least progressing normally, but is still noisy/distorted. it gets
stuck again when I quit it.
So the next question - what is a reclocking issue?
More information about the MPlayer-users