[HDMI] No sound, no error...

[elgoretto]

Hi,

I really hope you can help me, I'm totally out of options

In short:
hardware: AMD HD4350
drivers: radeon (in kernel) or radonhd (1.3.0), and ALSA/hda-intel (in kernel with ATI HDMI support)
kernel: 2.6.34
Distribution: Gentoo (up to date)
Problem: display is OK, but no sound through HDMI


Full story:
It's been a loooong time I try to get audio through HDMI working with a radeon HD4350 (RV710).
Previously on WinXP and Ubuntu 9.x with AMD's fglrx binary it was OK.
I switched to a Gentoo Linux (wich I'm used to) to be able to simply use latest radeon and radeonhd drivers.

Both are greatly working on a 2.6.34 kernel (DRI is on, display on TV is just great, image is perfectly scaled).
But!
When I play a sound file (mplayer and aplay) with the proper output set (btw I permanently disabled Mobo integrated audio chip), it plays it without a hitch... but without any sound too.

I don't understand.
I tested this setup with fglrx on Gentoo, but unfortunatly I can't load fglrx module or Xorg would freezes. Without fglx loaded but correct setup done for fglrx use, sound is OK (DRI missing but it is expected).

So HDMI sound should work (radeon and radeonhd both claim to support HDMI audio on RV710) but I can't hear anything. (I tried to turn TV volume up, didn't helped obviously )
Frustrating isn't it?

Do you have an suggestion, do you need any log or additionnal information?

Thanks in advance

[AndyW]

The HDMI audio patch for RV730/710 was committed to radeonhd master at the end of last December but wasn't in 1.3.0 from the outset, so you might want to check exactly when your distro package was built. On my Fedora 13 box I have 1.3.0-5.4.20100210git.fc13, so I no longer need to build from git source.

In xorg.conf Section "Device" you need

Option      "HDMI" "all"

You could be more specific and put the HMDI connector name as returned by xrandr, but why make things more tricky? Note you don't need

Option      "Audio" "on"

any more - if indeed it ever did anything.

You say you disabled onboard audio in BIOS so there is no chance that something like PulseAudio is sending audio output to a disconnected device...

If none of these help there is a utility (rhd_dump) which can check & set the value of the h/w registers involved; however you would have to download & build from git to do this.

Let's see how you get on,
Andrew

[elgoretto]

Yesterday (seriously, really), I cleaned up my kernel by wiping out all uvesafb stuff from it, and by trying to get radeon KMS fature working (as audio was not working, I couldn't be really more disappointed if my console wasn't "KMSed" after all...)

And as a side effect, I got sound, with "radeon" driver, without modifying my previous xorg or alsa setup (which was correct, I knew it! ).

Seriously... is KMS needed (1)?
Or is it only related to uvesafb which was blocking radeon from fully working (2)?

If (1), then "Feature dependency tree" of radeon driver web page (bottom) is not mentioning it.

[agd5f]

If (1), then "Feature dependency tree" of radeon driver web page (bottom) is not mentioning it.

That page is for KMS. There's a separate page for UMS:
http://xorg.freedesktop.org/wiki/RadeonFeatureUMS

[elgoretto]

Mmmmm, ok, I failed to see this UMS dedicated page, as there is no mention "KMS only"-like (in page title or headers) on the basic radeon page.

May I suggest to make this KMS thing more explicit?
Like "Features in the following matrix that are not reported as supported on [RadeonFeatureUMS page] need obviously KMS enabled"?
Because the "Feature dependency tree" is finally tricky: power saving is correctly mentioned as requiring KMS, but not HDMI audio.

[droidhacker]

Yesterday (seriously, really), I cleaned up my kernel by wiping out all uvesafb stuff from it, and by trying to get radeon KMS fature working (as audio was not working, I couldn't be really more disappointed if my console wasn't "KMSed" after all...)

And as a side effect, I got sound, with "radeon" driver, without modifying my previous xorg or alsa setup (which was correct, I knew it! ).

Seriously... is KMS needed (1)?
Or is it only related to uvesafb which was blocking radeon from fully working (2)?

If (1), then "Feature dependency tree" of radeon driver web page (bottom) is not mentioning it.

It probably would have been noticed by someone if you had bothered to mention the fact that you were trying to play with UMS. That stuff about "radeon in kernel", though sounding somewhat weird, does imply that you are using a kernel driver for radeon, which means KMS.

As it happens, the appropriate place to set HDMI audio is the same place where you are reading the display's capabilities, which means the place where you are performing your mode setting. Since there is really no reason to duplicate code and UMS is obsolete, this means that enabling audio SHOULD be restricted to KMS.

[elgoretto]

Dear droidhacker, thank you for your sudden interest in my problem which has been solved, and for reacting to a humble suggestion of mine to clarify the radeon documentation.

Then, you won't mind if I allow myself to answer you.

It probably would have been noticed by someone if you had bothered to mention the fact that you were trying to play with UMS. That stuff about "radeon in kernel", though sounding somewhat weird, does imply that you are using a kernel driver for radeon, which means KMS.

As you would have noticed if you read my first post, I didn't mentioned KMS. Oh, you noticed. Then it surely was because I wasn't "playing with" KMS at all.
And if you ever been in a recent kernel config screen, you would have noticed that using radeon kernel DRM driver "does not mean KMS".

As it happens, the appropriate place to set HDMI audio is the same place where you are reading the display's capabilities, which means the place where you are performing your mode setting.

I still don't see the obvious relation between letting the kernel setting my screen resolution and enabling audio on HDMI. Maybe because I didn't read the driver code before posting. That's why I'm happy when I get this sort of info in documentation.

Since there is really no reason to duplicate code and UMS is obsolete, this means that enabling audio SHOULD be restricted to KMS.

About this code you apparently know about, I hope you noticed my only point was about expliciting a single point in the driver documentation. I barelly mentioned anything about radeon code.

In fact I wasn't emitting a single criticism, I just wanted to help radeon project to clarify a point that users may care about.

I can't see why I deserve all this rant for my feedback.

[bridgman]

I still don't see the obvious relation between letting the kernel setting my screen resolution and enabling audio on HDMI. Maybe because I didn't read the driver code before posting. That's why I'm happy when I get this sort of info in documentation.

It's a question of which code programs the display controller (which includes blending audio onto the HDMI stream). The audio support is implemented in the KMS code.

Note that the radeonhd driver implements audio in its UMS code but radeon does not. The simplest way to put it is that the radeon driver "doesn't do anything with audio at all", so documentating audio in the radeon driver would be essentially adding a list of things that it does *not* do (but which are handled by other drivers).

[bridgman]

For the record, documenting the things which a user might think the driver handles but which are actually handled by other drivers is a perfectly reasonable request, it's just not as obvious a task as you were implying. The devs are currently struggling to get all the things the drivers *do* documented and documenting the things that *other* drivers handle probably isn't on their radar yet.

Part of the problem might be that the userspace X driver and the kernel driver are both referred to as "radeon", but the documentation refers only to the userspace X driver.

[droidhacker]

Dear droidhacker, thank you for your sudden interest in my problem which has been solved, and for reacting to a humble suggestion of mine to clarify the radeon documentation.

Then, you won't mind if I allow myself to answer you.


As you would have noticed if you read my first post, I didn't mentioned KMS. Oh, you noticed. Then it surely was because I wasn't "playing with" KMS at all.
And if you ever been in a recent kernel config screen, you would have noticed that using radeon kernel DRM driver "does not mean KMS".


I still don't see the obvious relation between letting the kernel setting my screen resolution and enabling audio on HDMI. Maybe because I didn't read the driver code before posting. That's why I'm happy when I get this sort of info in documentation.

About this code you apparently know about, I hope you noticed my only point was about expliciting a single point in the driver documentation. I barelly mentioned anything about radeon code.

In fact I wasn't emitting a single criticism, I just wanted to help radeon project to clarify a point that users may care about.

I can't see why I deserve all this rant for my feedback.

Try to be nice. All I was saying is that you need to be MORE PRECISE when you are describing what you are doing. If all you say is "it doesn't work", then people NEED to make a bunch of assumptions, which may or may not apply to your circumstances.

If you SAID that you were UMS, then it would have been OBVIOUS.