https://bugs.freedesktop.org/show_bug.cgi?id=64503

--- Comment #2 from Pierre Ossman pierre-bugzilla@ossman.eu --- Is that something that's very complex to do?

https://bugs.freedesktop.org/show_bug.cgi?id=64503

--- Comment #4 from Pierre Ossman pierre-bugzilla@ossman.eu --- 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.

https://bugs.freedesktop.org/show_bug.cgi?id=64503

--- Comment #6 from Alex Deucher agd5f@yahoo.com --- 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.

https://bugs.freedesktop.org/show_bug.cgi?id=64503

--- Comment #8 from Christian König deathsimple@vodafone.de --- (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.

https://bugs.freedesktop.org/show_bug.cgi?id=64503

--- Comment #10 from Alex Deucher agd5f@yahoo.com --- Created attachment 79258 --> https://bugs.freedesktop.org/attachment.cgi?id=79258&action=edit use 10khz units for dto

E.g., something like this.

https://bugs.freedesktop.org/show_bug.cgi?id=64503

--- Comment #12 from Pierre Ossman pierre-bugzilla@ossman.eu --- 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...

https://bugs.freedesktop.org/show_bug.cgi?id=64503

--- Comment #14 from Andy Furniss adf.lists@gmail.com --- (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)

https://bugs.freedesktop.org/show_bug.cgi?id=64503

--- Comment #16 from Pierre Ossman pierre-bugzilla@ossman.eu --- Does anyone have any more ideas as to what I can test?

https://bugs.freedesktop.org/show_bug.cgi?id=64503

--- Comment #18 from Pierre Ossman pierre-bugzilla@ossman.eu --- (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?

https://bugs.freedesktop.org/show_bug.cgi?id=64503

--- Comment #20 from Pierre Ossman pierre-bugzilla@ossman.eu --- 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=7d6... http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.11&id=950...

Unfortunately the problem remains. =/

https://bugs.freedesktop.org/show_bug.cgi?id=64503

--- Comment #22 from Pierre Ossman pierre-bugzilla@ossman.eu --- 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. :/