Bug 64503 - audio glitches when running at 24hz/24p
Summary: audio glitches when running at 24hz/24p
Status: RESOLVED INVALID
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: Other All
: medium enhancement
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-12 18:21 UTC by Pierre Ossman
Modified: 2013-08-03 10:49 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
use 10khz units for dto (3.43 KB, patch)
2013-05-13 15:37 UTC, Alex Deucher
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre Ossman 2013-05-12 18:21:02 UTC
(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.
Comment 1 Christian König 2013-05-13 08:19:25 UTC
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.
Comment 2 Pierre Ossman 2013-05-13 09:03:48 UTC
Is that something that's very complex to do?
Comment 3 Christian König 2013-05-13 10:19:11 UTC
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.
Comment 4 Pierre Ossman 2013-05-13 11:40:46 UTC
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.
Comment 5 Christian König 2013-05-13 11:56:54 UTC
The other possibility is that we are doing something wrong with the audio clock recovery, but that's usually directly controlled by the hw.
Comment 6 Alex Deucher 2013-05-13 14:41:25 UTC
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.
Comment 7 Pierre Ossman 2013-05-13 15:05:28 UTC
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.
Comment 8 Christian König 2013-05-13 15:27:02 UTC
(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.
Comment 9 Alex Deucher 2013-05-13 15:29:12 UTC
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
Comment 10 Alex Deucher 2013-05-13 15:37:20 UTC
Created attachment 79258 [details] [review]
use 10khz units for dto

E.g., something like this.
Comment 11 Pierre Ossman 2013-05-16 19:11:24 UTC
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?
Comment 12 Pierre Ossman 2013-05-16 19:40:19 UTC
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...
Comment 13 Pierre Ossman 2013-05-16 19:42:10 UTC
Also tried upping packets per line to 8, and the glitch is still in the same place.

More ideas? =/
Comment 14 Andy Furniss 2013-05-16 22:10:54 UTC
(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)
Comment 15 Pierre Ossman 2013-05-17 17:25:28 UTC
(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.
Comment 16 Pierre Ossman 2013-07-04 16:47:47 UTC
Does anyone have any more ideas as to what I can test?
Comment 17 Alex Deucher 2013-07-04 16:52:03 UTC
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.
Comment 18 Pierre Ossman 2013-07-07 11:43:04 UTC
(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?
Comment 20 Pierre Ossman 2013-08-02 14:53:45 UTC
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. =/
Comment 21 Pierre Ossman 2013-08-02 15:38:32 UTC
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.
Comment 22 Pierre Ossman 2013-08-02 16:35:20 UTC
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. :/
Comment 23 Christian König 2013-08-03 10:49:59 UTC
(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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.