Bug 64503

I think that works as designed.

Some modes doesn't offer enough bandwidth in the default configs to transmit all of the audio data. So for those modes we need to increase the number of audio packets per line, but since we haven't implemented that the low bandwidth modes can cause audio glitches.

Is that something that's very complex to do?

So far it's just a guess, we should first confirm that this is indeed the problem.

In drivers/gpu/drm/radeon/r600_hdmi.c there are two register writes using "HDMI0_AUDIO_PACKETS_PER_LINE(3)", try adjusting those to larger values and see if the audio glitches resolve.

I'll try changing as soon as I can find some time to play around with things. Although my rough calculation indicates that 3 packets per line should suffice:

 1 frame/packet * 3 packets/line * 1080 lines * 24 Hz = 77 kHz

And in stereo mode it could be squeezing in 4 frames per packet, giving even more headroom.

The other possibility is that we are doing something wrong with the audio clock recovery, but that's usually directly controlled by the hw.

The DTO divider calculation is incorrect.  See r600_audio_set_dto() and evergreen_audio_set_dto().  Express [24MHz / target pixel clock] as an exact rational number (coefficient of two integer numbers.  DCCG_AUDIO_DTOx_PHASE is the numerator, DCCG_AUDIO_DTOx_MODULE is the denominator.

What is the issue? The raw ratio should be:

24 * 10^6
---------
    c

And the code is putting in:

24 * 10^5
---------
c * 10^-1

which is the same thing.

(In reply to comment #7)
> What is the issue?

I simply assume the clocks get more stable with smaller numbers, and we haven't implemented reducing the fractions yet.

Alex comment is quite valid, that would also be worth a try.

Yeah, I'm just wondering if there is perhaps a sweet spot in the dividers (e.g., using 10 or 1 khz units rather than mhz .  Also the DTO_PHASE and and DTO_MODULE fields are 16 bits on DCE2.x, 24 bits on DCE3.x and 32 bits on DCE4.x

Created attachment 79258 [details] [review]
use 10khz units for dto

E.g., something like this.

Test results:

3.9.2 (Fedora): Glitches at around 110 seconds
plus upstream DTO stuff patched in: Dito.
plus Alex' patch: Glitches after about 20 seconds

So the suggested modification makes things much worse.


I'm also still failing to grasp how this thing works. Wouldn't you want as large values as possible to get the highest amount of precision?

So I tried that, and things are now back to ~110 seconds before a glitch. This is the code in case anyone's curious:

	base_bits = fls(24000);
	clock_bits = fls(clock);

	shift = min(32 - base_bits, 32 - clock_bits);

	WREG32(DCCG_AUDIO_DTO0_PHASE, 24000 << shift);
	WREG32(DCCG_AUDIO_DTO0_MODULE, clock << shift);

So that didn't help...

Also tried upping packets per line to 8, and the glitch is still in the same place.

More ideas? =/

(In reply to comment #0)
> (originally reported to Fedora:
> https://bugzilla.redhat.com/show_bug.cgi?id=954009)
> 
> I've recently started trying out 24 Hz again as my TV handles it better, and
> XBMC is finally at a point where they can keep things synced up when playing
> at exactly the monitor refresh rate.
> 
> Unfortunately that broke the HDMI audio output. If I try to output audio
> when the refresh rate is at 24 Hz, the receiver will lose audio sync every
> few minutes, resulting in silence until it regains sync.
> 
> I've tried the following:
> 
>  - Sending audio over SPDIF from the onboard audio to the same receiver
> works fine. Another cable though, and cannot handle high-bitrate formats, so
> hardly a long term solution.
> 
>  - Audio format doesn't seem to matter. I get glitches with PCM, AC3 and
> DTS. DTS is the worst, but that might just be because it requires more
> effort to sync back up again.
> 
>  - It's not xbmc that gets confused as sending audio from an entirely
> different program results in the same audio glitches (I tried mplayer with
> -vo null in the background).
> 
>  - Doesn't seem to be a application buffering issue as I see no spikes in
> either xbmc's or mplayer's sync statistics when the glitch appears.
> 
> 
> This is with kernel-3.8.7-201.fc18.x86_64.

Well I guess my bare bones LFS setup is very different to fedora, but I can't reproduce this.

Kernel drm-next recent-ish with radeon HD4890. Can only test PCM into TV with mplayer + alsa (pulse not installed)

cpufreq set to performance, GPU on low. TV screen set below monitor screen.

Tried 11 minute 44.1k CD track and 20 mins of blu-ray -vo vdpau 48k stereo and didn't hear any glitches at all. Of course blu-ray was 23.976 and modeline was 24, but I doubt that's relevant, mplayer will tweak video rate to keep audio sync and -framedrop was given.

FWIW this is my 24Hz line as shown by xrandr --verbose, maybe yours is different?

1920x1080 (0x2cd)   74.2MHz +HSync +VSync
        h: width  1920 start 2558 end 2602 total 2750 skew    0 clock   27.0KHz
        v: height 1080 start 1084 end 1089 total 1125           clock   24.0Hz

Having never used pulse I don't know if it's easy to bypass (assuming you are using it),

mplayer -ao alsa:device=hw=1.3 may work (assumes cat /proc/asound/cards shows HDMI as 1)

(In reply to comment #14)
> 
> FWIW this is my 24Hz line as shown by xrandr --verbose, maybe yours is
> different?
> 
> 1920x1080 (0x2cd)   74.2MHz +HSync +VSync
>         h: width  1920 start 2558 end 2602 total 2750 skew    0 clock  27.0KHz
>         v: height 1080 start 1084 end 1089 total 1125           clock  24.0Hz
> 

  1920x1080@23.976 (0x5e)   74.2MHz +HSync +VSync *current
        h: width  1920 start 2558 end 2602 total 2750 skew    0 clock   27.0KHz
        v: height 1080 start 1084 end 1089 total 1125           clock   24.0Hz

So identical I'd say.

> Having never used pulse I don't know if it's easy to bypass (assuming you
> are using it),

Nope, direct alsa.

Does anyone have any more ideas as to what I can test?

maybe this patch will help?

http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=f100380ecd8287b0909d3c5694784adc46e78a4a

Some monitors are picky about the checksum or hdmi version.

(In reply to comment #17)
> maybe this patch will help?
> 
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-
> next&id=f100380ecd8287b0909d3c5694784adc46e78a4a
> 
> Some monitors are picky about the checksum or hdmi version.

I'm afraid it had no effect. :/



Has anyone besides me been able to reproduce this?

does this patch help:
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.11&id=dffd4b65ca8989acb914da3c685c798ca5fcf99c

First off, I've upgraded to Fedora 19 and kernel-3.10.3-300.fc19.x86_64. That in itself had no effect on the bug, good or bad.

(In reply to comment #19)
> does this patch help:
> http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.
> 11&id=dffd4b65ca8989acb914da3c685c798ca5fcf99c

I also had to apply these two:

http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.11&id=7d61d835824f73dc4097b51f800382467c8049c5
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.11&id=9509f9a174b39db215edf7752de4847eaaca2775

Unfortunately the problem remains. =/

Just to confirm this is a driver problem, I tried two things:

 - Hooked up a Windows machine (also with a radeon card, although a different one)

 - Installed fglrx on my Linux machine.

In both cases the playback was glitch free in 24 Hz.

Argh! Problem found...

It was actually the mode that was incorrect. xrandr rounds things off, so it looked like it was the same as the working case, but actually wasn't.

Proper modeline:

Modeline "1920x1080"x24.0   74.25  1920 2558 2602 2750  1080 1084 1089 1125 +hsync +vsync (27.0 kHz e)

Horrible evil modeline:

ModeLine "1920x1080@23.976" 74.175 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync


The reason I had that was from back in ancient times when the radeon driver didn't properly grok the 24p mode from EDID for some reason. But it seems I got the NTSC I-can't-believe-it's-not-real-24p mode instead of the proper film one.


So with that hack removed it seems like the audio glitch is gone. Sorry for all the noise. :/

(In reply to comment #22) 
> So with that hack removed it seems like the audio glitch is gone. Sorry for
> all the noise. :/

No problem, at least we now knew what to ask for when we see that kind of bug again.