The Xorg.0.log file in its entirety is attached.

Hi Samir, Am Montag, den 13.07.2009, 15:47 -0500 schrieb Samir Unni: thanks, this helps allot, and the not working audio is simple to explain: You got a RV710 not a R700 chipset, and the RV710 is just not testet/supported atm. The good news is, since you have a working fglrx setup it should be quite simple to get this working. In the "utils/conntest/" directory of the radeonhd driver is a utility called "rhd_dump". This utility can (beside other things) read and write every hardware register on a low level basis. Please compile it and try the following: While audio is playing run: sudo ./rhd_dump -r 7000,7900 1:00.0 > dump_radeonhd.log Do this once with radeonhd and once with fglrx, then send me the resulting dumps. By comparing those dumps it should be easy to figure out what's causing the problem. Bye, Christian. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

I've attached the two log files. The fglrx log files looks very good, found the base address for the DVI connector, and confirmed that the base address of the HDMI connector is

Am Donnerstag, den 16.07.2009, 20:03 -0500 schrieb Samir Unni: the same for R700 and RV710. Please apply the attached patch and try again, if possible also with an DVI->HDMI adapter and the TV connected to the DVI port. I won't expect that this patch makes it works out of the box, but it's at least a start. Please make a new dump of the 7000,7900 register range with this patch. Bye, Christian.

Am Sonntag, den 19.07.2009, 12:03 -0500 schrieb Samir Unni:

Sorry, I only have HDMI->HDMI cables. No problem, it would just be nice if we could test this under all circumstances. I assume that you still don't hear anything, not event static noise, am i right?

I have created a list of the twelve most significant differences in the register setup fglrx does, compared to radeonhd (i left out all register where i know that they are read only or doesn't seem to matter for audio output). Try the following commands while some audio is playing: sudo ./rhd_dump -w 0x7300 0x8F1000F0 1:00.0 sudo ./rhd_dump -w 0x7400 0x00000011 1:00.0 sudo ./rhd_dump -w 0x740C 0x00011000 1:00.0 sudo ./rhd_dump -w 0x7410 0x05001031 1:00.0 sudo ./rhd_dump -w 0x7454 0x80283D7A 1:00.0 sudo ./rhd_dump -w 0x7458 0x00000010 1:00.0 sudo ./rhd_dump -w 0x7460 0x02000000 1:00.0 sudo ./rhd_dump -w 0x74D4 0x00100000 1:00.0 sudo ./rhd_dump -w 0x74D8 0x00200000 1:00.0 sudo ./rhd_dump -w 0x74DC 0x00000000 1:00.0 sudo ./rhd_dump -w 0x7408 0x00060010 1:00.0 sudo ./rhd_dump -w 0x733C 0x00000002 1:00.0 If one of the commands actually gets audio working, note which one and mail me back the results. Thanks, Christian. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

...

sudo ./rhd_dump -w 0x7460 0x02000000 1:00.0

This one turned the screen green, but none of the commands produced any sound. Mhm, turning turning the screen green means that the Audio/Video Info

Am Sonntag, den 19.07.2009, 15:10 -0500 schrieb Samir Unni: frame (including the RGB/YUV control bits you changed) is transmitted, which in turn tells us that the HDMI transmitter works correctly, so i actually don't have any idea what's going wrong. Please check if you also need the command: sudo ./rhd_dump -w 0x7400 0x00000011 1:00.0 to turn the screen green after an reboot, or if the command: sudo ./rhd_dump -w 0x7460 0x02000000 1:00.0 only is enough to make it work. Also you could make a little timing test: 1. Get a clock wich displays seconds, (a stop watch or something like that) 2. Start up mplayer from the command line. 3. Count 10 seconds on your clock (or maybe a little bit more). 4. Stop mplayer and look at the how much seconds it has actually played in the 10 seconds you counted: Starting playback... A: 10.1 (10.0) of 265.0 (04:25.0) 3.4% Exiting... (Quit) Is mplayer playing to fast or to slow? If mplayer isn't playing at the right speed make a dump of the 0500,0600 register range (that are the timing registers) and send it to me. Thanks for testing this, Christian. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Am Dienstag, den 21.07.2009, 14:19 -0400 schrieb Antony Jepson:

I don't have access to my desktop computer (which has a Radeon HD4830) but this timing issue does definitely take place. Mplayer (and YouTube videos) seem to play twice as fast. When I change the default soundcard order (by changing the index) and place the HDMI output as the second soundcard, videos play with correct timing. Is your monitor/tv connected to HDMI or the DVI connector?

If you have only the DVI port connected than this would be pretty normal, because the audio engine won't have a timing reference source (it's possible to use the DVI connector as timing source, but this isn't implemented right now for the HD4830). Thanks for the info, Christian. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Hi, On Tuesday July 21 at 16:55, Christian König wrote:

Am Sonntag, den 19.07.2009, 15:10 -0500 schrieb Samir Unni:

...

...

sudo ./rhd_dump -w 0x7460 0x02000000 1:00.0

This one turned the screen green, but none of the commands produced any sound.

Mhm, turning turning the screen green means that the Audio/Video Info frame (including the RGB/YUV control bits you changed) is transmitted, which in turn tells us that the HDMI transmitter works correctly, so i actually don't have any idea what's going wrong.

Please check if you also need the command: sudo ./rhd_dump -w 0x7400 0x00000011 1:00.0 to turn the screen green after an reboot, or if the command: sudo ./rhd_dump -w 0x7460 0x02000000 1:00.0 only is enough to make it work.

I take back what I said earlier. There are several ways to get the screen to turn green, depending on which order the commands are run in. I've had instances where the last command run before the screen turned green was

sudo ./rhd_dump -w 0x7454 0x80283D7A 1:00.0

or

sudo ./rhd_dump -w 0x7458 0x00000010 1:00.0

as well.

Also you could make a little timing test: 1. Get a clock wich displays seconds, (a stop watch or something like that) 2. Start up mplayer from the command line. 3. Count 10 seconds on your clock (or maybe a little bit more). 4. Stop mplayer and look at the how much seconds it has actually played in the 10 seconds you counted: Starting playback... A: 10.1 (10.0) of 265.0 (04:25.0) 3.4% Exiting... (Quit)

Is mplayer playing to fast or to slow? If mplayer isn't playing at the right speed make a dump of the 0500,0600 register range (that are the timing registers) and send it to me.

As far as I can tell, MPlayer is playing the audio at the correct speed. Thanks, Samir -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

On Friday July 24 at 21:01, Christian König wrote:

The registers 0x7454,0x7458,0x745c and 0x7460 together form the so called "Audio & Video Info Frame", those 16 Bytes are transmitted at least once every frame to your television. Those bytes contain a whole bunch of informations, one of them ist the used colour format (RGB or YUV). The first byte is a checksum of the other bytes, so it makes sense that you have to set all 4 registers to make the checksum match, letting the television recognise the frame as valid and switching to YUV format, which in turn leads to a green picture.

The register 0x7400 is a general enable/disable register, you need to set specific bits to fire up the transmitter in general, which bits you need to set depends on the chipset. This is the first thing we need to know to get this working.

I wrote a script to automate the testing and found out that running the commands $ sudo ./rhd_dump -w 0x7410 0x05001031 1:00.0 $ sudo ./rhd_dump -w 0x7454 0x80283D7A 1:00.0 $ sudo ./rhd_dump -w 0x7458 0x00000010 1:00.0 in any order will cause the screen to turn green. None of the other commands seem to have any impact at all. Running just any two of those three commands has no impact either. I switched to a VT and back after each sequence of commands to ensure that I was starting "clean" each time.

I Would suggest that you make a register dump of the 0500-0600 range with fglrx and radeonhd anyway, don't know if it will help, but it won't hurt anyway.

I've attached the dumps; they look a lot more pertinent, as there are only differences on two of the lines.

Another possibility is to use the debug facility in the transmitter to test the stream setup:

sudo ./rhd_dump -w 0x7408 0x00021011 1:00.0 sudo ./rhd_dump -w 0x74E0 0x0 1:00.0

You should hear static noise after that, be aware this can get very loud. I would suggest that you make the picture green before you try this, so you know at least that the transmitter is working.

Even when I turn up the volume on the TV all the way and put my ear right up against a speaker, I can't hear anything.

If you don't hear anything than there is a problem with the stream setup, infos like sampling frequency, bit per sample, number of channels etc.. aren't transmitted correctly to your tv.

What's required to fix this problem? Thanks, Samir

On Sunday July 26 at 14:11, Christian König wrote:

...

I've attached the dumps; they look a lot more pertinent, as there are only differences on two of the lines.

At least the first difference look very odd, the 0x0514 and 0x0518 registers are the multiplier/divider for the audio timing. 0x0514 is initialized to a constant value (48000*50), while the 0x0518 is set to the current pixel clock*100. The pixel clock depend on the current resolution, so if you use the same resolution for your fglrx and radeonhd setup this value should be the same, but that isn't the case....

Do you use the same resolution for both? Or are fglrx and radeonhd run at different resolutions?

Well, they are both set to run at 1920x1080, but fglrx attempts to compensate for overscan by inserting a black bar around the output. However, the TV is digital, so the 1920x1080 output ends up being displayed on a smaller area of pixels. Newer versions of fglrx offer the option of disabling this overscan compensation, but none of those versions are available in Kubuntu (they were in Arch, which I was previously using, but its chronic instability caused me to move to Kubuntu a few days back).

...

Even when I turn up the volume on the TV all the way and put my ear right up against a speaker, I can't hear anything.

Then the bug is somewere in the stream setup, or the debugging facility works different on this hardware. Try the command sudo ./rhd_dump -w 0x7408 0x00021011 1:00.0 with fglrx! Does this work? Is there a recognizable sound?

No, I can't hear anything. There is also no change in the output if I run that command while other audio (that I can hear just fine) is playing. Thanks, Samir -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

I have the resolution set to 1920x1080 for both. But with fglrx, I get underscan because it incorrectly attempts to compensate for overscan on all TVs, including digital ones. Mhm, send me a Xorg.log generated with fglrx, the driver should note the

Am Sonntag, den 26.07.2009, 14:49 -0500 schrieb Samir Unni: pixel clock it uses for a given resolution (this should be either 74.25 or 148.5 mHz).

No, I can't hear anything. And if I run that command while audio (that I can hear just fine) is being played back, there is no discernable effect on the output. That's sad, this was always something very useful.

Do you still want me to try this, or does the debugging facility not working change things? Without this debugging facility it doesn't make sense to try it out, but this leads to another idea, let's try the other way around.

Start up fglrx, and while playing something, feed the hardware with the register values radeonhd use until sound stops. This approach doesn't tell us how to do it right, but maybe we get new informations about what we are doing wrong: # complete alsa engine shutdown, should give you no sound sudo ./rhd_dump -w 0x7300 0x0 1:00.0 # the value radeonhd uses, should start sound immediately sudo ./rhd_dump -w 0x7300 0x810000F0 1:00.0 # the value fglrx uses, should start it again if radeonhd value doesn't work sudo ./rhd_dump -w 0x7300 0x8F1000F0 1:00.0 # radeonhd values of unknown registers in the alsa engine sudo ./rhd_dump -w 0x7308 0x00000000 1:00.0 sudo ./rhd_dump -w 0x733C 0x00000000 1:00.0 # disable hdmi transmitter: no sound and wrong colours sudo ./rhd_dump -w 0x7400 0x00000000 1:00.0 # enable hdmi transmitter: again sound and right colors sudo ./rhd_dump -w 0x7400 0x00000110 1:00.0 # turn of audio packets: should give you no sound sudo ./rhd_dump -w 0x7408 0x00020010 1:00.0 # turn on audio packets: should give you sound again sudo ./rhd_dump -w 0x7408 0x00020011 1:00.0 # radeonhd values of some other registers sudo ./rhd_dump -w 0x740C 0x00001000 1:00.0 sudo ./rhd_dump -w 0x74D4 0x00000000 1:00.0 sudo ./rhd_dump -w 0x74D8 0x00000002 1:00.0 sudo ./rhd_dump -w 0x74DC 0x00001000 1:00.0 sudo ./rhd_dump -w 0x74E0 0x00FFFFFF 1:00.0 sudo ./rhd_dump -w 0x74E4 0x007FFFFF 1:00.0 sudo ./rhd_dump -w 0x74E8 0x00000001 1:00.0 sudo ./rhd_dump -w 0x74EC 0x00000001 1:00.0 # radeonhd values for AV Info Frame: false colours, but does they also affect sound? sudo ./rhd_dump -w 0x7410 0x00000031 1:00.0 sudo ./rhd_dump -w 0x7454 0x0000006F 1:00.0 sudo ./rhd_dump -w 0x7458 0x00000000 1:00.0 sudo ./rhd_dump -w 0x7460 0x02000000 1:00.0 Good luck, Christian. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

On Sunday July 26 at 16:04, Christian König wrote:

...

Mhm, send me a Xorg.log generated with fglrx, the driver should note the pixel clock it uses for a given resolution (this should be either 74.25 or 148.5 mHz).

It's attached, looks like it's 148.5 mHz. Yes, 148.5 mHz, but that's odd. When i look at your dumps of the 0x0518 register the value fglrx uses is 0x00714BE8 (7425000 decimal). It's just a guess, but i've attached a patch which writes (pixel clock)/2 into

Am Samstag, den 01.08.2009, 16:17 -0500 schrieb Samir Unni: this register for your chipset, please try it and check if it affects audio playback in any way, also check if mplayer is playing to fast/to slow with this change.

...

# complete alsa engine shutdown, should give you no sound sudo ./rhd_dump -w 0x7300 0x0 1:00.0

Yes, the sound stopped.

...

# the value radeonhd uses, should start sound immediately sudo ./rhd_dump -w 0x7300 0x810000F0 1:00.0

# the value fglrx uses, should start it again if radeonhd value doesn't work sudo ./rhd_dump -w 0x7300 0x8F1000F0 1:00.0

Both of these values successfully restarted the sound. Good, so the alsa interface isn't the source of the problem.

...

# disable hdmi transmitter: no sound and wrong colours sudo ./rhd_dump -w 0x7400 0x00000000 1:00.0

Actually, this had no effect on either the sound or the colors.

...

# enable hdmi transmitter: again sound and right colors sudo ./rhd_dump -w 0x7400 0x00000110 1:00.0

Neither did this.

...

# turn of audio packets: should give you no sound sudo ./rhd_dump -w 0x7408 0x00020010 1:00.0

# turn on audio packets: should give you sound again sudo ./rhd_dump -w 0x7408 0x00020011 1:00.0

Same here, neither had any impact. WTF? Either ATI changes quite everything i am used to, or we are missing something here. Maybe they changed the registers to be buffered, normally each write to the hdmi engine results in an instant visibility of the change, but there are other registers were you need to set a special "make this change active" bit to commit the register writes to the hardware. Thanks for all the testing, but i am really running out of ideas here.

Bye, Christian.

On 2009/08/02 at 14:28, Samir Unni wrote:

On Sunday August 02 at 14:26, Christian König wrote:

...

Am Samstag, den 01.08.2009, 16:17 -0500 schrieb Samir Unni:

...

On Sunday July 26 at 16:04, Christian König wrote:

...

Mhm, send me a Xorg.log generated with fglrx, the driver should note the pixel clock it uses for a given resolution (this should be either 74.25 or 148.5 mHz).

It's attached, looks like it's 148.5 mHz.

Yes, 148.5 mHz, but that's odd. When i look at your dumps of the 0x0518 register the value fglrx uses is 0x00714BE8 (7425000 decimal). It's just a guess, but i've attached a patch which writes (pixel clock)/2 into this register for your chipset, please try it and check if it affects audio playback in any way, also check if mplayer is playing to fast/to slow with this change.

I still can't hear anything, but MPlayer is now playing about twice as fast as it should be.

Any update on this? Thanks, Samir -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org