Bug 436257 - HDMI Audio doesn't work
HDMI Audio doesn't work
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: module-init-tools (Show other bugs)
5.2
All Linux
low Severity medium
: rc
: ---
Assigned To: Bhavna Sarathy
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-06 01:36 EST by Yang, Libin
Modified: 2010-10-22 19:04 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 17:06:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
this version was tested at AMD (257 bytes, application/octet-stream)
2008-03-13 15:30 EDT, Bhavna Sarathy
no flags Details

  None (edit)
Description Yang, Libin 2008-03-06 01:36:55 EST
Description of problem:

HDMI Audio does not work on AMD RS780+SB700 in RHEL5.2 Beta RC. The HDMI Audio
card initialization fails. 

This is because of the modprobe configuration issue about Audio card. It used a
fixed index for HDA audio. So HDMI Audio will conflict with SB HDA audio.




How reproducible:

1. Install RHEL5.2 Beta RC

2. Try to play HDMI Audio 
  
Actual results:
No HDMI Audio is initialized.

Expected results:
HDMI Audio works.

Additional info:
Comment 1 Russell Doty 2008-03-07 09:35:39 EST
Libin,

Do you have a patch for this?
Comment 2 Bhavna Sarathy 2008-03-07 10:33:47 EST
Libin, what exactly is the modprobe configuration issue?  I suspect this doesn't
need a kernel patch but a configuration issue for Red Hat to fix/enable support.
Comment 3 Yang, Libin 2008-03-09 23:05:14 EDT
This is an issue of configuration. 

In the file /etc/modprobe.conf:

alias scsi_hostadapter ahci
alias snd-card-0 snd-hda-intel
options snd-card-0 index=0
options snd-hda-intel index=0
remove snd-hda-intel { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; };
/sbin/modprobe -r --ignore-remove snd-hda-intel
alias eth0 tg3

It means snd-hda-intel kernel module will be loaded with the parameter index =
0. This causes 2 audio card(SB HDA & HDMI Audio) will use the same index. So
conflict occurs. 

Only one card will be initialized. When initializing the other card, the driver
will find index = 0 card has been loaded. And the driver will fail to initialize
the second card.

What should do is just remove the following 2 lines in the modprobe.conf file:
options snd-card-0 index=0
options snd-hda-intel index=0

I have done a test after removing the upper 2 lines. SB HDA and HDMI Audio both
can be initialized well.
Comment 4 Bhavna Sarathy 2008-03-13 12:49:57 EDT
Russ, this is not a kernel specific issue.  Can you raise this with the right
group that makes user level modprobe changes?   And assign it to them?
Thanks,
Bhavana
Comment 5 Bhavna Sarathy 2008-03-13 15:07:25 EDT
Changing component so this bug gets looked at.
Comment 6 Bhavna Sarathy 2008-03-13 15:30:57 EDT
Created attachment 297971 [details]
this version was tested at AMD
Comment 7 Bhavna Sarathy 2008-03-13 16:46:45 EDT
Bill, you voiced some concerns regarding this on IRC, but unfortunately I lost 
of internet connection and can't get back on.  Please discuss them here so 
Libin can take part in the discussion as well.
Comment 8 Bill Nottingham 2008-03-13 16:53:34 EDT
Basically, other than it being a file used by modprobe, modprobe.conf has
nothing to do with module-init-tools.

Those aliases are written by kudzu, in order to ensure some semblance of
consistent ordering of sound devices.

If we leave them in, as you note, machines where the same driver serves multiple
ALSA devices will have issues.

If we remove the writing of them, any machine will multiple audio devices (pci
and usb, or pci and pci) will have their sound interfaces potentially in random
order on each boot.
Comment 9 Russell Doty 2008-03-13 17:03:03 EDT
Any recommendations for AMD on how to resolve this?
Comment 10 Bill Nottingham 2008-03-13 17:54:09 EDT
Not immediately.
Comment 11 Yang, Libin 2008-03-17 04:48:44 EDT
Based on Bill's description, can we suppose that kudzu will give a correct
configuration file? If so, I think we need not do anything on this issue.

I'm not familiar with how modprobe works. Do you think we just remove the
following 2 lines:
options snd-card-0 index=0
options snd-hda-intel index=0
while keeping "alias snd-card-0 snd-hda-intel"

Can this fix this issue?
"If we remove the writing of them, any machine will multiple audio devices (pci
and usb, or pci and pci) will have their sound interfaces potentially in random
order on each boot."


Comment 12 Bill Nottingham 2008-03-17 11:27:02 EDT
The alias doesn't help you, as sound modules aren't loaded that way in RHEL 5.
Comment 13 Yang, Libin 2008-03-17 23:33:14 EDT
Can I assume that the following two items 
"options snd-card-0 index=0
options snd-hda-intel index=0"
do the same work because of "alias snd-card-0 snd-hda-intel" in this case?

So only one item is needed?

I suppose we use the item "options snd-hda-intel index=0"

Actually the item "options snd-hda-intel index=0" only has effect on
snd-hda-intel probe the HDA cards. It will not impact on which card will be
loaded first, which card will be loaded next. 

If "index=0" is assigned, only one HDA card will be initialized. The other HDA
cards will not be initialized correctly. 
Comment 14 Yang, Libin 2008-03-21 03:15:37 EDT
I have tested on the RHEL5.2 Snapshot1 for this issue. The issues still exists.

Does anyone have good solution for this issue? If this issue exists, every
platform that has 2 HDA controller cards will fail to make the second HDA work.
Comment 15 Bill Nottingham 2008-03-24 13:42:26 EDT
(In reply to comment #13)
> Can I assume that the following two items 
> "options snd-card-0 index=0
> options snd-hda-intel index=0"
> do the same work because of "alias snd-card-0 snd-hda-intel" in this case?

Yes, but changing that won't help you, as you state below.
Comment 16 Yang, Libin 2008-03-24 23:01:21 EDT
There is a tool named "alsaconf" in alsa-util package from alsa official
website, which is used to help generate the config file for audio.

I installed it and used this tool to generate configuation file for sound on
SB700. It generated a configuration file "sound" in /etc/modprobe.d/, the
contents are:
alias snd-card-0 snd-hda-intel
alias sound-slot-0 snd-hda-intel

It works well.

So if it is hard to change the configuration file. Is it possible to include the
tool "alsaconf" in alsa-utils package for Red Hat? And user can decide whether
to use the tool to generate the configuration file "sound".


Comment 17 Bill Nottingham 2008-03-25 11:10:23 EDT
Those lines are *useless* - they're completely ignored when udev loads the
modules. Having alsaconf write those is the equivalent of doing nothing at all.

In this case, you will get all cards initialized, but in essentially random order.
Comment 18 Yang, Libin 2008-03-26 05:35:15 EDT
Hi Bill,

I tried the "sound" file today. firstly, I removed the lines:
alias snd-card-0 snd-hda-intel
options snd-card-0 index=0
options snd-hda-intel index=0
in /etc/modprobe.conf

And then I used alsaconf to generate the "sound" file

Then I tried to load the hda and usb audio drivers in random order. HDA card
will always be the first card. 

Bill, could you please have a try and see whether this mean there is no "random"
issue? Thanks.
Comment 19 Yang, Libin 2008-03-26 05:44:18 EDT
"I tried to load the hda and usb audio drivers in random order" means that I
rmmod the audio driver. And there was no any sound driver in kernel. 

Then I plugged USB audio card. The USB audio card driver will be loaded
automatically. Then I "cat /proc/asound/cards" and found HDA card was in the
first place. The default card was HDA card when I tried to play sound.
Comment 20 Bill Nottingham 2008-03-28 17:12:48 EDT
That works almost entirely by accident, due to some peculiarities of the ALSA
subsystem.

What happens is that when the first sound device is loaded, one of its
dependencies is the snd-pcm module. For reasons I've yet to fathom, when this
module is loaded, ALSA generates a kmod request for snd-card-0. So, essentially,
while you're loading (via hotplug, udev, whatever) one module, a request will be
generated that will load whatever is aliased to snd-card-0. And they'll race,
and oftentimes (as you see) the intended behavior will happen.

However, that doesn't guarantee you anything. Imagine a box with the following
configuration generated in the manner you suggest:

alias snd-card-0 snd-hda-intel
alias snd-card-1 snd-rme9652 (to pick a random add-in card)

You hotplug a USB device before any other modules are loaded. Due to the kmod
request generated as described above, you're likely to get snd-hda-intel as card
0. But you'll still get the USB device as card 1.
Comment 21 Yang, Libin 2008-04-01 05:38:12 EDT
Hi Bill,

I agree with you if we use the configuration like:
alias snd-card-0 snd-hda-intel
alias snd-card-1 snd-rme9652 (to pick a random add-in card)


I missed another parameter: cards_limit
We can use: 

options snd cards_limit=n

to determine how many audio cards will be automatically detected. You can find
more information about it in the file ALSA-Configuration.txt.

This parameter is set 1 by default and then only one card is autodetected.
Comment 22 Bill Nottingham 2008-04-01 11:37:47 EDT
That's still unreliable, as on new device add, they will be hotplugged before
you'd actually get a chance to write the configuration.
Comment 23 Yang, Libin 2008-04-01 22:42:51 EDT
Yes, no configuration will be updated when a new device is added. But the old
configuration file can not solve this issue either. 

I suggest changing the configuration file aims to fix this issue: If there are
two sound cards using the same driver, for example snd-usb-audio.ko, the second
sound card will be initialized falsely and can not be used.

As to the hotplug issue, I think we can find another solution to fix it. For
example we can use a daemon like "hald" to detect such event and call a tool to
modify the configuration file. 

Actually, I believe there must be reasons that ALSA set cards_limit=1 to let
only one sound card be autoloaded. What I understand is that the first sound
card is very important because it is the default sound card and most
applications will use the default sound card to play if there is no parameters
to appoint the card. And other sound cards' order is not so important. Anyway,
if you want to appoint the cards' order clearly, OK, here is "cards_limit".
Comment 24 Bill Nottingham 2008-04-02 14:25:33 EDT
(In reply to comment #23)
> As to the hotplug issue, I think we can find another solution to fix it. For
> example we can use a daemon like "hald" to detect such event and call a tool to
> modify the configuration file. 

booting is just another case of hotplug, and you won't catch those
events, or modify the config file then.
Comment 25 Yang, Libin 2008-04-02 22:24:54 EDT
There is a file "/etc/init.d/alsasound". It will be invoked when booting if the
runlevel supports sound function. I think many things can be done in this file.
Or just create another similar file to do it.

There is indeed some difference whether or not to use the "index" option. But if
there is no specific requirement, the "index" param is not necessary. And if the
"index" is used, then the risk in my former comments must be considered.
Comment 26 Bill Nottingham 2008-04-03 11:15:28 EDT
(In reply to comment #25)
> There is a file "/etc/init.d/alsasound". It will be invoked when booting if the
> runlevel supports sound function. I think many things can be done in this file.
> Or just create another similar file to do it.

Having an initscript to do sound things is silly:

- it leads to a case where the admin can easily break it by disabling the init
script
- there is a delay between when the module is loaded and things are actually set
working
- there's no way to hook into hotplug events

It should just be done via udev. That's why we've never shipped such a script.

Note You need to log in before you can comment on or make changes to this bug.