[MPlayer-users] mplayer alsa behavior playing video vs audio.

[Andy Furniss]

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
>> decode.
>>
>> The bug is garbled sound - mplayer does produce with -
>>
>> audio file video file -vc null (but not -vo null) video file uvd
>> decode.
>>
>> 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
>>
>> and
>>
>> 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
seconds.

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?