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 __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de -- 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 __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

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

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

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

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

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

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

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.

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 __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de -- 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

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.

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