Hi, I noticed some messages on the HDMI audio part for an RS690. I have also been experimenting with this feature and got a working setup after quite some experimenting and puzzling. I think the patch does not break support for R600 and up cards but no guarantee here. Right now audio works, however AC3 or DTS pass through is not working yet. Have to do some more puzzling here. Another challenge I'm working on is tear-free video playback on a full-HD screen. Right now I have a working setup using the AVIVO overlay option with a double buffering setup. This however needs a lot more work and can be best called a proof of concept at the moment. Hope this helps, Christiaan van Dijk. diff -u -r xf86-video-radeonhd/src/rhd_audio.c xf86-video-radeonhd-work/src/rhd_audio.c --- xf86-video-radeonhd/src/rhd_audio.c 2009-03-24 18:35:53.000000000 +0100 +++ xf86-video-radeonhd-work/src/rhd_audio.c 2009-04-06 19:06:02.000000000 +0200 @@ -228,41 +228,49 @@ xf86DrvMsg(Audio->scrnIndex, X_INFO, "%s: using %s as clock source with %d khz\n", __func__, Output->Name, (int)Clock); - switch(Output->Id) { - case RHD_OUTPUT_TMDSA: - case RHD_OUTPUT_LVTMA: - RHDRegMask(Audio, AUDIO_TIMING, 0, 0x301); - break; - - case RHD_OUTPUT_UNIPHYA: - case RHD_OUTPUT_UNIPHYB: - case RHD_OUTPUT_KLDSKP_LVTMA: - RHDRegMask(Audio, AUDIO_TIMING, 0x100, 0x301); - break; + if (rhdPtr->ChipSet > RHD_RS740) { + switch(Output->Id) { + case RHD_OUTPUT_TMDSA: + case RHD_OUTPUT_LVTMA: + RHDRegMask(Audio, AUDIO_TIMING, 0, 0x301); + break; + + case RHD_OUTPUT_UNIPHYA: + case RHD_OUTPUT_UNIPHYB: + case RHD_OUTPUT_KLDSKP_LVTMA: + RHDRegMask(Audio, AUDIO_TIMING, 0x100, 0x301); + break; - default: - break; - } + default: + break; + } - switch(Output->Id) { - case RHD_OUTPUT_TMDSA: - case RHD_OUTPUT_UNIPHYA: - RHDRegWrite(Audio, AUDIO_PLL1_MUL, Rate*50); - RHDRegWrite(Audio, AUDIO_PLL1_DIV, Clock*100); - RHDRegWrite(Audio, AUDIO_CLK_SRCSEL, 0); - break; - - case RHD_OUTPUT_LVTMA: - case RHD_OUTPUT_UNIPHYB: - case RHD_OUTPUT_KLDSKP_LVTMA: - RHDRegWrite(Audio, AUDIO_PLL2_MUL, Rate*50); - RHDRegWrite(Audio, AUDIO_PLL2_DIV, Clock*100); - RHDRegWrite(Audio, AUDIO_CLK_SRCSEL, 1); - break; - - default: - xf86DrvMsg(Audio->scrnIndex, X_ERROR, "%s: unsupported output type\n", __func__); - break; + switch(Output->Id) { + case RHD_OUTPUT_TMDSA: + case RHD_OUTPUT_UNIPHYA: + RHDRegWrite(Audio, AUDIO_PLL1_MUL, Rate*50); + RHDRegWrite(Audio, AUDIO_PLL1_DIV, Clock*100); + RHDRegWrite(Audio, AUDIO_CLK_SRCSEL, 0); + break; + + case RHD_OUTPUT_LVTMA: + case RHD_OUTPUT_UNIPHYB: + case RHD_OUTPUT_KLDSKP_LVTMA: + RHDRegWrite(Audio, AUDIO_PLL2_MUL, Rate*50); + RHDRegWrite(Audio, AUDIO_PLL2_DIV, Clock*100); + RHDRegWrite(Audio, AUDIO_CLK_SRCSEL, 1); + break; + + default: + xf86DrvMsg(Audio->scrnIndex, X_ERROR, "%s: unsupported output type\n", __func__); + break; + } + } else { + /* + * RS600, RS690, RS730? + */ + RHDRegWrite(Audio, AUDIO_PLL1_MUL, Rate * 50); + RHDRegWrite(Audio, AUDIO_PLL1_DIV, Clock * 100); } } @@ -287,12 +295,22 @@ xf86DrvMsg(Audio->scrnIndex, X_WARNING, "%s: reserved codec bits set 0x%x\n", __func__, (int) codec); - if(clear) { - RHDRegWrite(Audio, AUDIO_SUPPORTED_SIZE_RATE, config); - RHDRegWrite(Audio, AUDIO_SUPPORTED_CODEC, codec); + if (rhdPtr->ChipSet > RHD_RS740) { + if(clear) { + RHDRegWrite(Audio, AUDIO_SUPPORTED_SIZE_RATE, config); + RHDRegWrite(Audio, AUDIO_SUPPORTED_CODEC, codec); + } else { + RHDRegMask(Audio, AUDIO_SUPPORTED_SIZE_RATE, config, config); + RHDRegMask(Audio, AUDIO_SUPPORTED_CODEC, codec, codec); + } } else { - RHDRegMask(Audio, AUDIO_SUPPORTED_SIZE_RATE, config, config); - RHDRegMask(Audio, AUDIO_SUPPORTED_CODEC, codec, codec); + /* + * RS600, RS690, RS730? + */ + if(clear) + RHDRegWrite(Audio, AUDIO_SUPPORTED_CODEC, codec); + else + RHDRegMask(Audio, AUDIO_SUPPORTED_CODEC, codec, codec); } } @@ -375,7 +393,9 @@ return; } - /* shoutdown the audio engine before doing anything else */ + /* + * Shutdown the audio engine before doing anything else. + */ RHDAudioSetEnable(rhdPtr, FALSE); RHDRegWrite(Audio, AUDIO_TIMING, Audio->StoreTiming); diff -u -r xf86-video-radeonhd/src/rhd_hdmi.c xf86-video-radeonhd-work/src/rhd_hdmi.c --- xf86-video-radeonhd/src/rhd_hdmi.c 2009-03-24 18:35:54.000000000 +0100 +++ xf86-video-radeonhd-work/src/rhd_hdmi.c 2009-04-06 19:09:26.000000000 +0200 @@ -236,7 +236,7 @@ { if(Enable) { RHDRegMask(hdmi, hdmi->Offset+HDMI_CNTL, 0x1000, 0x1000); - RHDRegWrite(hdmi, hdmi->Offset+HDMI_AUDIO_DEBUG, 0xffffff); + RHDRegWrite(hdmi, hdmi->Offset+HDMI_AUDIO_DEBUG_0, 0xffffff); } else { RHDRegMask(hdmi, hdmi->Offset+HDMI_CNTL, 0, 0x1000); } @@ -253,34 +253,46 @@ struct rhdHdmi *hdmi; RHDFUNC(rhdPtr); - if(rhdPtr->ChipSet >= RHD_R600) { + if(rhdPtr->ChipSet >= RHD_RS600) { hdmi = (struct rhdHdmi *) xnfcalloc(sizeof(struct rhdHdmi), 1); hdmi->scrnIndex = rhdPtr->scrnIndex; hdmi->Output = Output; - switch(Output->Id) { - case RHD_OUTPUT_TMDSA: - hdmi->Offset = HDMI_TMDS; - break; - - case RHD_OUTPUT_LVTMA: - hdmi->Offset = HDMI_LVTMA; - break; - - case RHD_OUTPUT_UNIPHYA: - hdmi->Offset = HDMI_TMDS; - break; - - case RHD_OUTPUT_KLDSKP_LVTMA: - hdmi->Offset = HDMI_DIG; - break; - - /*case RHD_OUTPUT_UNIPHYB: */ - - default: - xf86DrvMsg(hdmi->scrnIndex, X_ERROR, "%s: unknown HDMI output type\n", __func__); - xfree(hdmi); - return NULL; - break; + /* I really don't like this... */ + hdmi->ChipSet = rhdPtr->ChipSet; + if (rhdPtr->ChipSet > RHD_RS740) { + /* + * Above RS740. + */ + switch(Output->Id) { + case RHD_OUTPUT_TMDSA: + hdmi->Offset = HDMI_TMDS; + break; + + case RHD_OUTPUT_LVTMA: + hdmi->Offset = HDMI_LVTMA; + break; + + case RHD_OUTPUT_UNIPHYA: + hdmi->Offset = HDMI_TMDS; + break; + + case RHD_OUTPUT_KLDSKP_LVTMA: + hdmi->Offset = HDMI_DIG; + break; + + /*case RHD_OUTPUT_UNIPHYB: */ + + default: + xf86DrvMsg(hdmi->scrnIndex, X_ERROR, "%s: unknown HDMI output type\n", __func__); + xfree(hdmi); + return NULL; + break; + } + } else { + /* + * RS600, RS690, RS740? + */ + hdmi->Offset = HDMI_TMDS; } hdmi->Stored = FALSE; RHDAudioRegisterHdmi(rhdPtr, hdmi); @@ -298,31 +310,60 @@ if(!hdmi) return; RHDFUNC(hdmi); - RHDAudioSetClock(RHDPTRI(hdmi), hdmi->Output, Mode->Clock); + if (hdmi->ChipSet > RHD_RS740) { + /* + * Above RS740. + */ + RHDAudioSetClock(RHDPTRI(hdmi), hdmi->Output, Mode->Clock); - HdmiAudioDebugWorkaround(hdmi, FALSE); + HdmiAudioDebugWorkaround(hdmi, FALSE); - RHDRegWrite(hdmi, hdmi->Offset+HDMI_UNKNOWN_0, 0x1000); - RHDRegWrite(hdmi, hdmi->Offset+HDMI_UNKNOWN_1, 0x0); - RHDRegWrite(hdmi, hdmi->Offset+HDMI_UNKNOWN_2, 0x1000); + RHDRegWrite(hdmi, hdmi->Offset+HDMI_UNKNOWN_0, 0x1000); + RHDRegWrite(hdmi, hdmi->Offset+HDMI_UNKNOWN_1, 0x0); + RHDRegWrite(hdmi, hdmi->Offset+HDMI_UNKNOWN_2, 0x1000); - HdmiAudioClockRegeneration(hdmi, Mode->Clock); + HdmiAudioClockRegeneration(hdmi, Mode->Clock); - RHDRegWrite(hdmi, hdmi->Offset+HDMI_VIDEOCNTL, 0x13); - RHDRegWrite(hdmi, hdmi->Offset+HDMI_VERSION, 0x202); + RHDRegWrite(hdmi, hdmi->Offset+HDMI_VIDEOCNTL, 0x13); + RHDRegWrite(hdmi, hdmi->Offset+HDMI_VERSION, 0x202); - HdmiVideoInfoFrame(hdmi, RGB, FALSE, 0, 0, 0, - 0, 0, FALSE, 0, 0, 0, 0, 0, 0, 0, 0, 0); + HdmiVideoInfoFrame(hdmi, RGB, FALSE, 0, 0, 0, + 0, 0, FALSE, 0, 0, 0, 0, 0, 0, 0, 0, 0); - /* audio packets per line, does anyone know how to calc this ? */ - RHDRegMask(hdmi, hdmi->Offset+HDMI_CNTL, 0x020000, 0x1F0000); + /* audio packets per line, does anyone know how to calc this ? */ + RHDRegMask(hdmi, hdmi->Offset+HDMI_CNTL, 0x020000, 0x1F0000); - /* update? reset? don't realy know */ - RHDRegMask(hdmi, hdmi->Offset+HDMI_CNTL, 0x14000000, 0x14000000); + /* update? reset? don't realy know */ + RHDRegMask(hdmi, hdmi->Offset+HDMI_CNTL, 0x14000000, 0x14000000); + } else { + /* + * RS600, RS690, RS740? + */ + RHDAudioSetClock(RHDPTRI(hdmi), hdmi->Output, Mode->Clock); + + /* Debug stuff */ + RHDRegWrite(hdmi, hdmi->Offset+HDMI_AUDIO_DEBUG_0, 0x00FFFFFF); + RHDRegWrite(hdmi, hdmi->Offset+HDMI_AUDIO_DEBUG_1, 0x007FFFFF); + RHDRegWrite(hdmi, hdmi->Offset+HDMI_AUDIO_DEBUG_2, 0x00000001); + RHDRegWrite(hdmi, hdmi->Offset+HDMI_AUDIO_DEBUG_3, 0x00000001); + HdmiAudioDebugWorkaround(hdmi, FALSE); + + /* Setup video info frame. */ + RHDRegMask(hdmi, hdmi->Offset+HDMI_CNTL, 0x04020011, 0x04070111); + RHDRegMask(hdmi, hdmi->Offset+HDMI_UNKNOWN_2, 0x00001100, 0x00001100); + RHDRegMask(hdmi, hdmi->Offset+HDMI_VIDEOCNTL, 0x000000B3, 0x000000B3); + RHDRegMask(hdmi, hdmi->Offset+HDMI_VERSION, 0x00000202, 0x00003F3F); + RHDRegMask(hdmi, hdmi->Offset+HDMI_UNKNOWN_1, 0x00000000, 0x00000001); + + HdmiAudioClockRegeneration(hdmi, Mode->Clock); + + HdmiVideoInfoFrame(hdmi, RGB, FALSE, 0, 0, 0, + 0, 0, FALSE, 0, 0, 0, 0, 0, 0, 0, 0, 0); + } } /* - * update settings whith current parameters from audio engine + * update settings with current parameters from audio engine */ void RHDHdmiUpdateAudioSettings( @@ -382,10 +423,27 @@ RHDRegMask(hdmi, hdmi->Offset+HDMI_IEC60958_2, iec, 0x5000f); - RHDRegWrite(hdmi, hdmi->Offset+HDMI_AUDIOCNTL, 0x31); - HdmiAudioInfoFrame(hdmi, channels-1, 0, 0, 0, 0, 0, 0, FALSE); + if (hdmi->ChipSet > RHD_RS740) + { + /* + * Above RS740. + */ + RHDRegWrite(hdmi, hdmi->Offset+HDMI_AUDIOCNTL, 0x31); + HdmiAudioInfoFrame(hdmi, channels-1, 0, 0, 0, 0, 0, 0, FALSE); + + /* is this OK? Not 0x4000000 ?? */ + RHDRegMask(hdmi, hdmi->Offset+HDMI_CNTL, 0x400000, 0x400000); + } else { + /* + * RS600, RS690, RS740? + */ + /* 0x021 or 0x031 sets the audio frame length */ + RHDRegMask(hdmi, hdmi->Offset+HDMI_AUDIOCNTL, 0x00000031, 0x00000031); + HdmiAudioInfoFrame(hdmi, channels-1, 0, 0, 0, 0, 0, 0, FALSE); + RHDRegMask(hdmi, hdmi->Offset+HDMI_VIDEOCNTL, 0xC0, 0xC0); - RHDRegMask(hdmi, hdmi->Offset+HDMI_CNTL, 0x400000, 0x400000); + RHDRegMask(hdmi, hdmi->Offset+HDMI_CNTL, 0x4000000, 0x4000000); + } } /* @@ -399,26 +457,57 @@ /* some version of atombios ignore the enable HDMI flag * so enabling/disabling HDMI was moved here for TMDSA and LVTMA */ - switch(hdmi->Output->Id) { - case RHD_OUTPUT_TMDSA: - RHDRegMask(hdmi, TMDSA_CNTL, Enable ? 0x4 : 0x0, 0x4); - RHDRegWrite(hdmi, hdmi->Offset+HDMI_ENABLE, Enable ? 0x101 : 0x0); - break; - - case RHD_OUTPUT_LVTMA: - RHDRegMask(hdmi, LVTMA_CNTL, Enable ? 0x4 : 0x0, 0x4); - RHDRegWrite(hdmi, hdmi->Offset+HDMI_ENABLE, Enable ? 0x105 : 0x0); - break; - - case RHD_OUTPUT_UNIPHYA: - case RHD_OUTPUT_UNIPHYB: - case RHD_OUTPUT_KLDSKP_LVTMA: - RHDRegWrite(hdmi, hdmi->Offset+HDMI_ENABLE, Enable ? 0x110 : 0x0); - break; - - default: - xf86DrvMsg(hdmi->scrnIndex, X_ERROR, "%s: unknown HDMI output type\n", __func__); - break; + if(hdmi->ChipSet > RHD_RS740) { + /* + * Above RS740. + */ + switch(hdmi->Output->Id) { + case RHD_OUTPUT_TMDSA: + RHDRegMask(hdmi, TMDSA_CNTL, Enable ? 0x4 : 0x0, 0x4); + RHDRegWrite(hdmi, hdmi->Offset+HDMI_ENABLE, Enable ? 0x101 : 0x0); + break; + + case RHD_OUTPUT_LVTMA: + RHDRegMask(hdmi, LVTMA_CNTL, Enable ? 0x4 : 0x0, 0x4); + RHDRegWrite(hdmi, hdmi->Offset+HDMI_ENABLE, Enable ? 0x105 : 0x0); + break; + + case RHD_OUTPUT_UNIPHYA: + case RHD_OUTPUT_UNIPHYB: + case RHD_OUTPUT_KLDSKP_LVTMA: + /* This part is doubtfull in my opinion */ + RHDRegWrite(hdmi, hdmi->Offset+HDMI_ENABLE, Enable ? 0x110 : 0x0); + break; + + default: + xf86DrvMsg(hdmi->scrnIndex, X_ERROR, "%s: unknown HDMI output type\n", __func__); + break; + } + } else { + /* + * RS600?, RS690, and RS740? + */ + switch(hdmi->Output->Id) { + case RHD_OUTPUT_TMDSA: + RHDRegMask(hdmi, HDMI_TMDS+HDMI_ENABLE, Enable ? 0x01 : 0x00, 0x0D); + break; + + case RHD_OUTPUT_LVTMA: + RHDRegMask(hdmi, HDMI_TMDS+HDMI_ENABLE, Enable ? 0x05 : 0x00, 0x0D); + RHDRegMask(hdmi, LVTMA_CNTL, Enable ? 0x04 : 0x00, 0x04); + break; + + case RHD_OUTPUT_UNIPHYA: + case RHD_OUTPUT_UNIPHYB: + case RHD_OUTPUT_KLDSKP_LVTMA: + RHDRegMask(hdmi, HDMI_TMDS+HDMI_ENABLE, Enable ? 0x0D : 0x00, 0x0D); + RHDRegMask(hdmi, RS69_DDIA_CNTL, Enable ? 0x04 : 0x00, 0x04); + break; + + default: + xf86DrvMsg(hdmi->scrnIndex, X_ERROR, "%s: unknown HDMI output type\n", __func__); + break; + } } } @@ -433,7 +522,10 @@ hdmi->StoreEnable = RHDRegRead(hdmi, hdmi->Offset+HDMI_ENABLE); hdmi->StoreControl = RHDRegRead(hdmi, hdmi->Offset+HDMI_CNTL); - hdmi->StoredAudioDebugWorkaround = RHDRegRead(hdmi, hdmi->Offset+HDMI_AUDIO_DEBUG); + hdmi->StoredAudioDebugWorkaround[0x0] = RHDRegRead(hdmi, hdmi->Offset+HDMI_AUDIO_DEBUG_0); + hdmi->StoredAudioDebugWorkaround[0x1] = RHDRegRead(hdmi, hdmi->Offset+HDMI_AUDIO_DEBUG_1); + hdmi->StoredAudioDebugWorkaround[0x2] = RHDRegRead(hdmi, hdmi->Offset+HDMI_AUDIO_DEBUG_2); + hdmi->StoredAudioDebugWorkaround[0x3] = RHDRegRead(hdmi, hdmi->Offset+HDMI_AUDIO_DEBUG_3); hdmi->StoredFrameVersion = RHDRegRead(hdmi, hdmi->Offset+HDMI_VERSION); @@ -483,7 +575,10 @@ RHDRegWrite(hdmi, hdmi->Offset+HDMI_ENABLE, hdmi->StoreEnable); RHDRegWrite(hdmi, hdmi->Offset+HDMI_CNTL, hdmi->StoreControl); - RHDRegWrite(hdmi, hdmi->Offset+HDMI_AUDIO_DEBUG, hdmi->StoredAudioDebugWorkaround); + RHDRegWrite(hdmi, hdmi->Offset+HDMI_AUDIO_DEBUG_0, hdmi->StoredAudioDebugWorkaround[0x0]); + RHDRegWrite(hdmi, hdmi->Offset+HDMI_AUDIO_DEBUG_1, hdmi->StoredAudioDebugWorkaround[0x1]); + RHDRegWrite(hdmi, hdmi->Offset+HDMI_AUDIO_DEBUG_2, hdmi->StoredAudioDebugWorkaround[0x2]); + RHDRegWrite(hdmi, hdmi->Offset+HDMI_AUDIO_DEBUG_3, hdmi->StoredAudioDebugWorkaround[0x3]); RHDRegWrite(hdmi, hdmi->Offset+HDMI_VERSION, hdmi->StoredFrameVersion); diff -u -r xf86-video-radeonhd/src/rhd_hdmi.h xf86-video-radeonhd-work/src/rhd_hdmi.h --- xf86-video-radeonhd/src/rhd_hdmi.h 2009-03-24 18:35:54.000000000 +0100 +++ xf86-video-radeonhd-work/src/rhd_hdmi.h 2009-04-05 17:31:57.000000000 +0200 @@ -29,6 +29,7 @@ struct rhdHdmi { struct rhdHdmi* Next; + enum RHD_CHIPSETS ChipSet; int scrnIndex; @@ -39,7 +40,7 @@ CARD32 StoreEnable; CARD32 StoreControl; CARD32 StoreUnknown[0x3]; - CARD32 StoredAudioDebugWorkaround; + CARD32 StoredAudioDebugWorkaround[0x4]; CARD32 StoredFrameVersion; CARD32 StoredVideoControl; diff -u -r xf86-video-radeonhd/src/rhd_regs.h xf86-video-radeonhd-work/src/rhd_regs.h --- xf86-video-radeonhd/src/rhd_regs.h 2009-03-24 18:35:54.000000000 +0100 +++ xf86-video-radeonhd-work/src/rhd_regs.h 2009-04-05 17:13:51.000000000 +0200 @@ -1113,7 +1113,10 @@ HDMI_IEC60958_1 = 0xd4, HDMI_IEC60958_2 = 0xd8, HDMI_UNKNOWN_2 = 0xdc, - HDMI_AUDIO_DEBUG = 0xe0 + HDMI_AUDIO_DEBUG_0 = 0xe0, + HDMI_AUDIO_DEBUG_1 = 0xe4, + HDMI_AUDIO_DEBUG_2 = 0xe8, + HDMI_AUDIO_DEBUG_3 = 0xec }; #endif /* _RHD_REGS_H */
Am Montag, den 06.04.2009, 20:36 +0200 schrieb Christiaan van Dijk:
I noticed some messages on the HDMI audio part for an RS690. I have also been experimenting with this feature and got a working setup after quite some experimenting and puzzling. I think the patch does not break support for R600 and up cards but no guarantee here. Right now audio works, however AC3 or DTS pass through is not working yet. Have to do some more puzzling here.
Ah, thanks allot, it was giving me quite a headache figuring out what's going wrong on RS690 for some time now. I will take a look at the patch and maybe have some additional questions, but that won't be before Friday. Bye, Christian. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/4/6 Christiaan van Dijk
I noticed some messages on the HDMI audio part for an RS690. I have also been experimenting with this feature and got a working setup after quite some experimenting and puzzling. I think the patch does not break support for R600 and up cards but no guarantee here. Right now audio works, however AC3 or DTS pass through is not working yet. Have to do some more puzzling here.
I've tested this patch on my 2 machines: 1) M82 with HDMI on DVI-D_1 2) RV635 with HDMI on DVI-I_1/digital and after reboot with HDMI on DVI-I_2/digital using Samsung 1080p TV and mplayer -vo alsa:hw=device=1.3. I tested that for 1920x1080, 1280x720 and 640x480. I didn't notice any regression and I'm quite happy with that :) RV635 was somehow little problematic earlier (http://lists.opensuse.org/radeonhd/2008-10/msg00153.html) On friday I'll able to test M82 again with AC3/DTS pass-through S/PDIF (current I don't have access to hardware suppporting that signal). -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Apr 07, 09 00:08:55 +0200, Christian König wrote:
Ah, thanks allot, it was giving me quite a headache figuring out what's going wrong on RS690 for some time now. I will take a look at the patch and maybe have some additional questions, but that won't be before Friday.
Christian, would it be reasonable to push this into git for the current
release, and fix it for good after that, do we want to delay post
easter, or ship as is?
Matthias
--
Matthias Hopf
2009/4/8 Matthias Hopf
On Apr 07, 09 00:08:55 +0200, Christian König wrote:
Ah, thanks allot, it was giving me quite a headache figuring out what's going wrong on RS690 for some time now. I will take a look at the patch and maybe have some additional questions, but that won't be before Friday.
Christian, would it be reasonable to push this into git for the current release, and fix it for good after that, do we want to delay post easter, or ship as is?
Pushing this to master and releasing 1.2.5 the same day? Does this patch look to safe for other chipsets (no chance for regression)? -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Apr 08, 09 16:02:16 +0200, Rafał Miłecki wrote:
2009/4/8 Matthias Hopf
: On Apr 07, 09 00:08:55 +0200, Christian König wrote:
Ah, thanks allot, it was giving me quite a headache figuring out what's going wrong on RS690 for some time now. I will take a look at the patch and maybe have some additional questions, but that won't be before Friday.
Christian, would it be reasonable to push this into git for the current release, and fix it for good after that, do we want to delay post easter, or ship as is?
Pushing this to master and releasing 1.2.5 the same day? Does this patch look to safe for other chipsets (no chance for regression)?
Looks safe to me. Though it needs some work, still.
E.g. there are some typos (RS730 vs. RS740, only in comments, though),
I would prefer >= RHD_R600 instead of > RHD_RS740 (R600 seems to be the
big step, and we might see something like RS760 or RS790 in the future),
there's a comment about a constant that might be wrong in the R600 and
up case (which has to be verified).
Nothing that would hold up a commit. And AFAIK we do not support
pre-R600 HDMI audio correctly yet, am I right?
Matthias
--
Matthias Hopf
2009/4/8 Matthias Hopf
Nothing that would hold up a commit. And AFAIK we do not support pre-R600 HDMI audio correctly yet, am I right?
Yes, I think so. According to Christian's mail [1] from october 2008 we support:
RV620, RV630, RV635, RV770, RS780 and M86
and probably other, similar to these mentioned, but not
Please don't push this to master ATM. The patch looks good, but it adds some new values for the debug registers. And AFAIK those registers can trigger the writeout of ANY video memory as audio packets, resulting in some static noise. This is indeed very usefull for debugging (since you can see where a problem is in the audio pipeline), but also very annoying if it happens accidentally. Bye, Christian. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Hi Christiaan, i have some questions about your RS690 HDMI patch. First of all could you send me an XOrg log created with -logverbose 7 ? Second some questions about individual stuff in the patch: rhd_audio.c:268 } else { /* * RS600, RS690, RS730? */ RHDRegWrite(Audio, AUDIO_PLL1_MUL, Rate * 50); RHDRegWrite(Audio, AUDIO_PLL1_DIV, Clock * 100); } Why do you miss initializing of AUDIO_CLK_SRCSEL and AUDIO_TIMING ? I think the missing write to AUDIO_TIMING is the problem behind AC3 pass through not working. rhd_audio.c:306 } else { /* * RS600, RS690, RS730? */ if(clear) RHDRegWrite(Audio, AUDIO_SUPPORTED_CODEC, codec); else RHDRegMask(Audio, AUDIO_SUPPORTED_CODEC, codec, codec); } Why not setting AUDIO_SUPPORTED_SIZE_RATE ? It's unimportant ATM, but if somebody tries to load alsa after the radeonhd driver we would ran into problems. rhd_hdmi.c:475 case RHD_OUTPUT_UNIPHYA: case RHD_OUTPUT_UNIPHYB: case RHD_OUTPUT_KLDSKP_LVTMA: /* This part is doubtfull in my opinion */ RHDRegWrite(hdmi, hdmi->Offset+HDMI_ENABLE, Enable ? 0x110 : 0x0); break; mhm? Why is this doubtful? 0x110 is the value which gets written on M86, and that also seems to work on anything else. That's it for the moment, but i think i will have more questions when i figure out how those additional debug registers you've found works. Bye, Christian. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Apr 08, 09 17:01:43 +0200, deathsimple@vodafone.de wrote:
Please don't push this to master ATM.
I ignore this patch for the current release then.
Thanks for looking at it
Matthias
--
Matthias Hopf
Hello, Christian König wrote:
Hi Christiaan,
i have some questions about your RS690 HDMI patch. First of all could you send me an XOrg log created with -logverbose 7 ?
Second some questions about individual stuff in the patch:
rhd_audio.c:268 } else { /* * RS600, RS690, RS730? */ RHDRegWrite(Audio, AUDIO_PLL1_MUL, Rate * 50); RHDRegWrite(Audio, AUDIO_PLL1_DIV, Clock * 100); }
Why do you miss initializing of AUDIO_CLK_SRCSEL and AUDIO_TIMING ? I think the missing write to AUDIO_TIMING is the problem behind AC3 pass through not working.
The part you mention does not seem to apply for (at least) the RS690. I just tried the combinations again to see if there is any effect on AC3/DTS passthrough: * RHDRegMask(Audio, AUDIO_TIMING, 0, 0x301); No effect, audio works, AC3 pass through fails. * RHDRegMask(Audio, AUDIO_TIMING, 0x100, 0x301); No effect, audio works, AC3 pass through fails. * RHDRegWrite(Audio, AUDIO_CLK_SRCSEL, 0); No effect, audio works, AC3 pass through fails. * RHDRegWrite(Audio, AUDIO_CLK_SRCSEL, 1); No effect, audio works, AC3 pass through fails. No effect what so ever. I'm not sure where the problem lies with the AC3/DTS pass through. When using mplayer it reports the right output format: 48000Hz 2ch ac3 (1 byte per sample). The switch from 16 bits to 8 bits per sample should be detected by AudioUpdateHdmi but is not and audio playback is not started. Right now I'm looking at the ALSA kernel driver part to see how the AC3 settings are being passed, this however seems to be supported although the code contains a lot of fixme's ... Has playback of AC3/DTS been verified on other chipsets????
rhd_audio.c:306 } else { /* * RS600, RS690, RS730? */ if(clear) RHDRegWrite(Audio, AUDIO_SUPPORTED_CODEC, codec); else RHDRegMask(Audio, AUDIO_SUPPORTED_CODEC, codec, codec); }
Why not setting AUDIO_SUPPORTED_SIZE_RATE ? It's unimportant ATM, but if somebody tries to load alsa after the radeonhd driver we would ran into problems.
Just rechecked this one. I had some problems with getting any audio at all and thought it was related to this part; but it's not :-), this part should be identical for all chipsets.
rhd_hdmi.c:475 case RHD_OUTPUT_UNIPHYA: case RHD_OUTPUT_UNIPHYB: case RHD_OUTPUT_KLDSKP_LVTMA: /* This part is doubtfull in my opinion */ RHDRegWrite(hdmi, hdmi->Offset+HDMI_ENABLE, Enable ? 0x110 : 0x0); break;
mhm? Why is this doubtful? 0x110 is the value which gets written on M86, and that also seems to work on anything else.
I ran into some parts where different values seem to be used for R600. Did not take a very detailed look at it and just commented it as an attention point. If there are no problems it's probably not critical.
That's it for the moment, but i think i will have more questions when i figure out how those additional debug registers you've found works.
These new debug registers are not very clear to me. They only seem to apply to RS chips but I did not really play around with any detailed debugging.
Bye, Christian.
I also had one question mark in rhd_hdmi.c around line 448: /* is this OK? Not 0x4000000 ?? */ RHDRegMask(hdmi, hdmi->Offset+HDMI_CNTL, 0x400000, 0x400000); } else { I really have no clue on what this does and I did no testing with different sampling frequencies yet. The 5 instead of 6 zeros could be a simple typo, or you have a lot more insight in what this bit does and had a very good reason for doing it this way :-). Still have to make the Xorg.0.log, system is recording right now so will be a bit later. Great to get some feedback on this patch, hopefully the AC3/DTS will also be solved. System is coming closer and closer to a usable media center :-). Regds, Christiaan van Dijk. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/4/9 Christiaan van Dijk
Has playback of AC3/DTS been verified on other chipsets????
Works fine on M82, my amplitier tuner shows "DTS" then and sound is much better quality. -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Rafał Miłecki wrote:
2009/4/9 Christiaan van Dijk
: Has playback of AC3/DTS been verified on other chipsets????
Works fine on M82, my amplitier tuner shows "DTS" then and sound is much better quality.
Thanks for the info, this is very useful; at least the ALSA part and radeonhd driver part are working for the M82. Just have to dig some more for the RS690. Does playback of AC3 also work good? This uses 48000kHz and 8 bits per sample while DTS is using more bits per sample (if I'm not mistaken...). Regds, Christiaan. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/4/10 Christiaan van Dijk
Rafał Miłecki wrote:
2009/4/9 Christiaan van Dijk
: Has playback of AC3/DTS been verified on other chipsets????
Works fine on M82, my amplitier tuner shows "DTS" then and sound is much better quality.
Thanks for the info,
this is very useful; at least the ALSA part and radeonhd driver part are working for the M82. Just have to dig some more for the RS690. Does playback of AC3 also work good? This uses 48000kHz and 8 bits per sample while DTS is using more bits per sample (if I'm not mistaken...).
Not sure, is this question to me? :) If so, what would you like me to test (what mplayer params)? -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Rafał Miłecki wrote:
2009/4/10 Christiaan van Dijk
: Rafał Miłecki wrote:
2009/4/9 Christiaan van Dijk
: Has playback of AC3/DTS been verified on other chipsets????
Works fine on M82, my amplitier tuner shows "DTS" then and sound is much better quality.
Thanks for the info,
this is very useful; at least the ALSA part and radeonhd driver part are working for the M82. Just have to dig some more for the RS690. Does playback of AC3 also work good? This uses 48000kHz and 8 bits per sample while DTS is using more bits per sample (if I'm not mistaken...).
Not sure, is this question to me? :) If so, what would you like me to test (what mplayer params)?
Well just anybody with a working setup could help here. If you have a file with AC3 and/or DTS encoding (demos can be downloaded at lot of places) and test them with mplayer. I use the option "-ac hwac3" for AC3 files and "-ac hwdts" for DTS files. Mplayer gives some info on what samplerate, channels and bits per channel are used. This worked very well on my old VIA based boxes but no luck with the RS690 yet. Would be really good to know if this works like this on other setups like an M82. Regds, Christiaan. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Christian König wrote:
Hi Christiaan,
i have some questions about your RS690 HDMI patch. First of all could you send me an XOrg log created with -logverbose 7 ?
That's it for the moment, but i think i will have more questions when i figure out how those additional debug registers you've found works.
Bye, Christian.
Hello, really not easy to use the "-logverbose 7" option in OpenSuSE. Finally got it to work by re-starting X from a command prompt. Is there no easy way to pass this parameter during normal system startup??? Tried /etc/X11/xinit/xserverrc but this has no effect. Anyway, log is attached, audio was not working due to something going wrong during X startup and ALSA. Regds, Christiaan.
2009/4/11 Christiaan van Dijk
really not easy to use the "-logverbose 7" option in OpenSuSE. Finally got it to work by re-starting X from a command prompt. Is there no easy way to pass this parameter during normal system startup??? Tried /etc/X11/xinit/xserverrc but this has no effect. Anyway, log is attached, audio was not working due to something going wrong during X startup and ALSA.
Quite easy :) sudo init 3 startx -- -logverbose 7 -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Apr 11, 09 12:44:59 +0200, Christiaan van Dijk wrote:
really not easy to use the "-logverbose 7" option in OpenSuSE. Finally got
Yeah, it depends on whether you're using kdm, gdm, or xdm :-(
Painful, indeed.
Plus, I never seem to remember the paths of the kdm and
gdm config files :-/
Matthias
--
Matthias Hopf
W dniu 11 kwietnia 2009 11:50 użytkownik Christiaan van Dijk
Well just anybody with a working setup could help here. If you have a file with AC3 and/or DTS encoding (demos can be downloaded at lot of places) and test them with mplayer. I use the option "-ac hwac3" for AC3 files and "-ac hwdts" for DTS files. Mplayer gives some info on what samplerate, channels and bits per channel are used. This worked very well on my old VIA based boxes but no luck with the RS690 yet. Would be really good to know if this works like this on other setups like an M82.
OK, I got movie in mkv container with following audios: [mkv] Track ID 2: audio (A_DTS) "DTS 5.1 @ 1.5mbit", -aid 0, -alang eng [mkv] Track ID 3: audio (A_AC3) "English Commentary", -aid 1, -alang und which should be great for testing. 1) mplayer -aid 0 -ao alsa:device=hw=1.3 file.mkv Opening audio decoder: [libdca] DTS decoding with libdca Stream with high frequencies VQ coding AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000) Selected audio codec: [dts] afm: libdca (DTS-libdca) ========================================================================== AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Amplifier-tuner displays "PCM" and "[ICON]PLII", audio works 2) mplayer -aid 1 -ao alsa:device=hw=1.3 file.mkv Opening audio decoder: [liba52] AC3 decoding with liba52 Using SSE optimized IMDCT transform Using MMX optimized resampler AUDIO: 48000 Hz, 2 ch, s16le, 192.0 kbit/12.50% (ratio: 24000->192000) Selected audio codec: [a52] afm: liba52 (AC3-liba52) ========================================================================== AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Amplifier-tuner displays "PCM" and "[ICON]PLII", audio works 3) mplayer -aid 0 -ac hwdts -ao alsa:device=hw=1.3 file.mkv Forced audio codec: hwdts Opening audio decoder: [hwac3] AC3/DTS pass-through S/PDIF No accelerated IMDCT transform found hwac3: switched to DTS, 1536000 bps, 48000 Hz AUDIO: 48000 Hz, 2 ch, ac3, 1536.0 kbit/100.00% (ratio: 192000->192000) Selected audio codec: [hwdts] afm: hwac3 (DTS through S/PDIF) ========================================================================== [AO_ALSA] alsa-lib: conf.c:3843:(parse_args) Unknown parameter AES0 [AO_ALSA] alsa-lib: conf.c:3969:(snd_config_expand) Parse arguments error: No such file or directory [AO_ALSA] alsa-lib: pcm.c:2202:(snd_pcm_open_noupdate) Unknown PCM hw:1,3,AES0=6 AO: [alsa] 48000Hz 2ch ac3 (1 bytes per sample) Amplifier-tuner displays "dts", audio works 4) mplayer -aid 1 -ac hwac3 -ao alsa:device=hw=1.3 file.mkv Forced audio codec: hwac3 Opening audio decoder: [hwac3] AC3/DTS pass-through S/PDIF No accelerated IMDCT transform found hwac3: switched to AC3, 192000 bps, 48000 Hz AUDIO: 48000 Hz, 2 ch, ac3, 192.0 kbit/12.50% (ratio: 24000->192000) Selected audio codec: [hwac3] afm: hwac3 (AC3 through S/PDIF) ========================================================================== [AO_ALSA] alsa-lib: conf.c:3843:(parse_args) Unknown parameter AES0 [AO_ALSA] alsa-lib: conf.c:3969:(snd_config_expand) Parse arguments error: No such file or directory [AO_ALSA] alsa-lib: pcm.c:2202:(snd_pcm_open_noupdate) Unknown PCM hw:1,3,AES0=6 AO: [alsa] 48000Hz 2ch ac3 (1 bytes per sample) Amplifier-tuner displays "[ICON]D" and "[ICON]PLII", audio works Can I provide more info for you? The [ICON] is that icon presented always as dolby digital logo. -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Hi, Am Samstag, den 11.04.2009, 12:44 +0200 schrieb Christiaan van Dijk:
really not easy to use the "-logverbose 7" option in OpenSuSE. Finally got it to work by re-starting X from a command prompt. Is there no easy way to pass this parameter during normal system startup??? Tried /etc/X11/xinit/xserverrc but this has no effect. Anyway, log is attached, audio was not working due to something going wrong during X startup and ALSA. Ah thanks, is this the only card with an RS690 you have?
In the patch i can see that you have made a change for the DVO output, but in your logs i can the that you only have a LVTMA output, ist this correct? And a more general question: Do you want to make changes to your patch yourself, or should i hack the stuff how i think it should look like and mail it back to you for testing? Bye, Christian. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Rafał Miłecki wrote:
W dniu 11 kwietnia 2009 11:50 użytkownik Christiaan van Dijk
napisał: Well just anybody with a working setup could help here. If you have a file with AC3 and/or DTS encoding (demos can be downloaded at lot of places) and test them with mplayer. I use the option "-ac hwac3" for AC3 files and "-ac hwdts" for DTS files. Mplayer gives some info on what samplerate, channels and bits per channel are used. This worked very well on my old VIA based boxes but no luck with the RS690 yet. Would be really good to know if this works like this on other setups like an M82.
OK, I got movie in mkv container with following audios: [mkv] Track ID 2: audio (A_DTS) "DTS 5.1 @ 1.5mbit", -aid 0, -alang eng [mkv] Track ID 3: audio (A_AC3) "English Commentary", -aid 1, -alang und which should be great for testing.
1) mplayer -aid 0 -ao alsa:device=hw=1.3 file.mkv Opening audio decoder: [libdca] DTS decoding with libdca Stream with high frequencies VQ coding AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000) Selected audio codec: [dts] afm: libdca (DTS-libdca) ========================================================================== AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
Amplifier-tuner displays "PCM" and "[ICON]PLII", audio works
2) mplayer -aid 1 -ao alsa:device=hw=1.3 file.mkv Opening audio decoder: [liba52] AC3 decoding with liba52 Using SSE optimized IMDCT transform Using MMX optimized resampler AUDIO: 48000 Hz, 2 ch, s16le, 192.0 kbit/12.50% (ratio: 24000->192000) Selected audio codec: [a52] afm: liba52 (AC3-liba52) ========================================================================== AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
Amplifier-tuner displays "PCM" and "[ICON]PLII", audio works
3) mplayer -aid 0 -ac hwdts -ao alsa:device=hw=1.3 file.mkv Forced audio codec: hwdts Opening audio decoder: [hwac3] AC3/DTS pass-through S/PDIF No accelerated IMDCT transform found hwac3: switched to DTS, 1536000 bps, 48000 Hz AUDIO: 48000 Hz, 2 ch, ac3, 1536.0 kbit/100.00% (ratio: 192000->192000) Selected audio codec: [hwdts] afm: hwac3 (DTS through S/PDIF) ========================================================================== [AO_ALSA] alsa-lib: conf.c:3843:(parse_args) Unknown parameter AES0 [AO_ALSA] alsa-lib: conf.c:3969:(snd_config_expand) Parse arguments error: No such file or directory [AO_ALSA] alsa-lib: pcm.c:2202:(snd_pcm_open_noupdate) Unknown PCM hw:1,3,AES0=6 AO: [alsa] 48000Hz 2ch ac3 (1 bytes per sample)
Amplifier-tuner displays "dts", audio works
4) mplayer -aid 1 -ac hwac3 -ao alsa:device=hw=1.3 file.mkv Forced audio codec: hwac3 Opening audio decoder: [hwac3] AC3/DTS pass-through S/PDIF No accelerated IMDCT transform found hwac3: switched to AC3, 192000 bps, 48000 Hz AUDIO: 48000 Hz, 2 ch, ac3, 192.0 kbit/12.50% (ratio: 24000->192000) Selected audio codec: [hwac3] afm: hwac3 (AC3 through S/PDIF) ========================================================================== [AO_ALSA] alsa-lib: conf.c:3843:(parse_args) Unknown parameter AES0 [AO_ALSA] alsa-lib: conf.c:3969:(snd_config_expand) Parse arguments error: No such file or directory [AO_ALSA] alsa-lib: pcm.c:2202:(snd_pcm_open_noupdate) Unknown PCM hw:1,3,AES0=6 AO: [alsa] 48000Hz 2ch ac3 (1 bytes per sample)
Amplifier-tuner displays "[ICON]D" and "[ICON]PLII", audio works
Can I provide more info for you?
The [ICON] is that icon presented always as dolby digital logo.
Hi, the first situation is what also works for me right now; software decoding and 48kHz/2ch/16bit output. Second test is still using software decoding and the 3th and 4th tests use the pass through. I tried the same settings on my setup and get the same messages but no audio playback. At least I now know these messages are OK and the pass-through part does work on other setups. Now just have to figure out what's going wrong on the RS690 :-\ . I have no other tests at the moment. Thanks, Christiaan. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
W dniu 13 kwietnia 2009 12:08 użytkownik Christiaan van Dijk
Hi,
the first situation is what also works for me right now; software decoding and 48kHz/2ch/16bit output. Second test is still using software decoding and the 3th and 4th tests use the pass through. I tried the same settings on my setup and get the same messages but no audio playback. At least I now know these messages are OK and the pass-through part does work on other setups. Now just have to figure out what's going wrong on the RS690 :-\ . I have no other tests at the moment.
Did you try to check does fglrx make any good? IIRC using fglrx I was able to play pass-through. Maybe you could observe some interesting registers changes? -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Hi, Am Montag, den 13.04.2009, 12:08 +0200 schrieb Christiaan van Dijk:
the first situation is what also works for me right now; software decoding and 48kHz/2ch/16bit output. Second test is still using software decoding and the 3th and 4th tests use the pass through. I tried the same settings on my setup and get the same messages but no audio playback. At least I now know these messages are OK and the pass-through part does work on other setups. Now just have to figure out what's going wrong on the RS690 :-\ . I have no other tests at the moment. Did someone mentioned that you need AC3/DTS with 192 k Bytes per second or 1536 k bits per second to get pass through working? At least for DTS 164 k Bytes per second are more common.
Am Montag, den 13.04.2009, 12:23 +0200 schrieb Rafał Miłecki:
Did you try to check does fglrx make any good? IIRC using fglrx I was able to play pass-through. Maybe you could observe some interesting registers changes? Comparing the the register values to some reference implementation is always the simplest way to get things working, but at least for R620 i had to compare the register values to the windows driver, not fglrx. Since fglrx doesn't seem to support pass through on R620. Keep in mind that this doesn't have to be true on RS690, so it worth at least a try.
Bye, Christian. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Rafał Miłecki wrote:
W dniu 13 kwietnia 2009 12:08 użytkownik Christiaan van Dijk
napisał: Hi,
the first situation is what also works for me right now; software decoding and 48kHz/2ch/16bit output. Second test is still using software decoding and the 3th and 4th tests use the pass through. I tried the same settings on my setup and get the same messages but no audio playback. At least I now know these messages are OK and the pass-through part does work on other setups. Now just have to figure out what's going wrong on the RS690 :-\ . I have no other tests at the moment.
Did you try to check does fglrx make any good? IIRC using fglrx I was able to play pass-through. Maybe you could observe some interesting registers changes?
That's one of the next steps. Working with the fglrx driver is not really nice; unstable is a very soft expression when using fglrx on a full-HD display. Right now the problem seems to be the link from ALSA to the radeonhd driver. ALSA seems to do all the right things but the radeonhd driver does not detect this. ALSA also contains options to be more verbose but this needs recompilation of the kernel modules. Not a real problem but I was running into some problems here. Probably a small mistake but it takes some time to figure out and the weather is really nice here at the moment so I'm not sure if I want to spent the entire afternoon fighting this problem :-). Regds, Christiaan. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Good news, just updated the kernel modules to latest ALSA version (1.0.19) and mplayer is giving me correct pass through!!!! (ALSA was not working due to indeed a stupid mistake). Quite surprisingly gmplayer is not giving pass through. Probably has something to do with the cutting edge version installed right now, will fix this later on but this is not related to the driver. Both DTS and AC3 are now working. I also messed a bit with the driver so I will do some more checks to see if this had any effect. There can still be some audio drop-outs of about 100ms (I think). This probably has to do with some interrupts in my source stream from MythTV. I still want to try to make the stopping of the audio from the timer routine a bit more relaxed. For example stop audio after 2 or 3 timer intervals with off. Still needs verification. But right now I'm going to enjoy the great weather here:-). Regds, Christiaan. Christian König wrote:
Hi,
Am Montag, den 13.04.2009, 12:08 +0200 schrieb Christiaan van Dijk:
the first situation is what also works for me right now; software decoding and 48kHz/2ch/16bit output. Second test is still using software decoding and the 3th and 4th tests use the pass through. I tried the same settings on my setup and get the same messages but no audio playback. At least I now know these messages are OK and the pass-through part does work on other setups. Now just have to figure out what's going wrong on the RS690 :-\ . I have no other tests at the moment.
Did someone mentioned that you need AC3/DTS with 192 k Bytes per second or 1536 k bits per second to get pass through working? At least for DTS 164 k Bytes per second are more common.
Am Montag, den 13.04.2009, 12:23 +0200 schrieb Rafał Miłecki:
Did you try to check does fglrx make any good? IIRC using fglrx I was able to play pass-through. Maybe you could observe some interesting registers changes?
Comparing the the register values to some reference implementation is always the simplest way to get things working, but at least for R620 i had to compare the register values to the windows driver, not fglrx. Since fglrx doesn't seem to support pass through on R620. Keep in mind that this doesn't have to be true on RS690, so it worth at least a try.
Bye, Christian.
-- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/4/13 Christiaan van Dijk
just updated the kernel modules to latest ALSA version (1.0.19) and mplayer is giving me correct pass through!!!!
That's great!
There can still be some audio drop-outs of about 100ms (I think).
I don't really understand, what do you mean by this? Actually I hear audio few hundreds ms after I start mplayer (my M82). Is this what you mean? Is this hardware limitation or can this be improved? -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/4/12 Christian König
And a more general question: Do you want to make changes to your patch yourself, or should i hack the stuff how i think it should look like and mail it back to you for testing?
Any news on that? -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Rafał Miłecki wrote:
2009/4/12 Christian König
: And a more general question: Do you want to make changes to your patch yourself, or should i hack the stuff how i think it should look like and mail it back to you for testing?
Any news on that?
Hi, Christian made a patch which I am currently testing. So far all seems to work fine allthough I still have some questions on the adaptions but I really have to look in more detail. Very limited time available at the moment for this stuff. My setup still suffers from occasional audio drop outs. This does not seem to be caused by the radeonhd driver but somewhere in the ALSA part. Dropouts are very frequent in AC3 passthrough. Have to try some of the options for the hda-intel module to see if this helps, any thoughts would be welcome here. Regds, Christiaan. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Hi, Rafał Miłecki wrote:
Any news on that? sorry forgot to put you/the list on cc. Attached is the patch i send Christiaan for testing. It's just a stripped down version to only the most necessary. Could you test it and make sure that this patch doesn't make any changes on other chipset types?
My setup still suffers from occasional audio drop outs. This does not seem to be caused by the radeonhd driver but somewhere in the ALSA part. Dropouts are very frequent in AC3 passthrough. Have to try some of the options for the hda-intel module to see if this helps, any thoughts would be welcome here. Since the audio pipeline from application->alsa->audio codec->hdmi encoder->DTS/AC3 decoder->speaker is quite long it's hard to tell were the problem is.
Does the frequency of those drop outs change with different display resolutions (or more specific with the pixel clock)? If no then i am pretty sure that you are right and this is a problem somewhere in the alsa driver. If yes this could also be a glitch in the audio clock recovery code. Bye, Christian.
Christian König wrote:
Since the audio pipeline from application->alsa->audio codec->hdmi encoder->DTS/AC3 decoder->speaker is quite long it's hard to tell were the problem is.
Does the frequency of those drop outs change with different display resolutions (or more specific with the pixel clock)? If no then i am pretty sure that you are right and this is a problem somewhere in the alsa driver. If yes this could also be a glitch in the audio clock recovery code.
Bye, Christian.
Another good pointer, the default settings for my setup are: Pixel clock = 148500 kHz PLL setup: ((14320 kHz / 9) * 560) / 6 = 148503.704 kHz RHDAudioSetClock: Using TMDS B as clock source with 148500 kHz MUL = 2400000, DIV = 148500000; gives 24MHz CTS_48kHz = 148500, N_48kHz = 6144 All the audio related settings match the settings made by fglrx, I did not check the PLL configuration so far, never looked in this area. Playback is very strange. Using Mythtv I have allmost no dropouts. This is what xorg log says: (II) RADEONHD(0): RHDHdmiUpdateAudioSettings: playing with 2 channels, 48000 Hz sampling rate, 16 bits per sample, (II) RADEONHD(0): RHDHdmiUpdateAudioSettings: 0x01 IEC60958 status bits and 0x00 category code Now I take a divx file with mplayer. Sound is OK and mplayer gives the following info: AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) And xorg logs: (II) RADEONHD(0): RHDHdmiUpdateAudioSettings: playing with 2 channels, 48000 Hz sampling rate, 16 bits per sample, (II) RADEONHD(0): RHDHdmiUpdateAudioSettings: 0x01 IEC60958 status bits and 0x00 category code And now an AC3 file. Sound has dropouts every couple of minutes, mplayer info: AO: [alsa] 48000Hz 2ch AC3 (1 bytes per sample) And xorg log: (II) RADEONHD(0): RHDHdmiUpdateAudioSettings: playing with 2 channels, 48000 Hz sampling rate, 16 bits per sample, (II) RADEONHD(0): RHDHdmiUpdateAudioSettings: 0x01 IEC60958 status bits and 0x00 category code All combinations give the same settings but different behaviour on the drop outs, really strange. Lowering the screen resolution gives a different situation: Pixel clock = 109000 kHz PLL setup: ((14320 kHz / 7) * 373) / 7 = 109007,35 kHz RHDAudioSetClock: Using TMDS B as clock source with 148500 kHz MUL = 2400000, DIV = 10900000; gives 24MHz CTS_48kHz = 109000, N_48kHz = 6144 Now there a no drop outs in the sound. Another side effect is noticeable in the video playback; playback is very smooth with the lower resolution. In the 1920x1080 resolution playback is not smooth. I also tried playback with video output to the null device to see if the video rendering has any effect; no effect what so ever. I'm very puzzled by this behavior but will try to think of some new experiments. Regds, Christiaan. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/4/26 Christian König
Rafał Miłecki wrote:
Any news on that? sorry forgot to put you/the list on cc. Attached is the patch i send Christiaan for testing. It's just a stripped down version to only the most necessary. Could you test it and make sure that this patch doesn't make any changes on other chipset types?
Audio still works fine with M82, I wan't able to test with RV635 yet. -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
participants (5)
-
Christiaan van Dijk
-
Christian König
-
deathsimple@vodafone.de
-
Matthias Hopf
-
Rafał Miłecki