HAL module only adds the first ALSA device of each card

Patch to add all ALSA devices

This patch is not right. On some sound cards surround sound is implemented via a 4 stereo subdevices which are then combined into a single 7.1 device. Thus it generally doesn't make sense to open subdevices directly, because only ALSA itself knows what those subdevices are about. The proper way to open a device for digital out is using the "spdif:" ALSA device string, not directly opening subdevices which will only work on very few devices.

Hi Lennart,

Your reply suggests that moving a stream to the "Digital" sound device in pavucontrol is not the correct way to have Pulse use SPDIF, because the correct behavior is for pulseaudio to not add this device (I had to modify my configuration to make it show up). Given this, can you please write up documentation explaining the correct way to play streams using optical out?

Thanks very much.

FireRabbit?, could you please tell me how you got the "Digital" device to show up? -- I am also only seeing analog and am not able to play to my desktop speakers connected via optical :(

I only see this output device in pulseaudio:

ALSA PCM on front:0 (ALC883 Analog) via DMA

When aplay -l shows:

card 0: NVidia [HDA NVidia], device 0: ALC883 Analog [ALC883 Analog]
card 0: NVidia [HDA NVidia], device 1: ALC883 Digital [ALC883 Digital]

Why doesn't pulseaudio add the second device and how do I add it manually? -- I've been up and down the documentation for over an hour now and still lost, please help.

Hi hackeron,

I added the following line to /etc/pulse/default.pa:

load-module module-alsa-sink device=hw:0,1

The first number is the card and the second number is the device, so in your case 0,1 is also correct.

As you probably saw, lennart mentioned that this is not the correct way to do this, however he has not yet provided an alternative.

Hope this helps.

thank you for the super fast reply, that did the trick!

Ther correct way to fix this issue to real SPDIF support to PA.

I have a soundblaster audigy 2 zs card (5.1 sound-system). PulseAudio automatically detects only the Output-Device "ALSA PCM on front:0 (ADC Capture/Standard PCM Playback) via DMA". This is wrong because I only hear the 2 front speakers. All other speakers (rear, center, lfe) are dead. PulseAudio should detect the Output-Device "ALSA PCM on hw:0,0 (ADC Capture/Standard PCM Playback) via DMA". In this case all speakers are working well! Is this a bug or what will happen to this in future?

Replying to albuntu:

I have a soundblaster audigy 2 zs card (5.1 sound-system). PulseAudio automatically detects only the Output-Device "ALSA PCM on front:0 (ADC Capture/Standard PCM Playback) via DMA". This is wrong because I only hear the 2 front speakers. All other speakers (rear, center, lfe) are dead. PulseAudio should detect the Output-Device "ALSA PCM on hw:0,0 (ADC Capture/Standard PCM Playback) via DMA". In this case all speakers are working well! Is this a bug or what will happen to this in future?

Try setting default-sample-channels = 6 in your /etc/pulse/daemon.conf file.

The workaround provided by firerabbit works, but to an unacceptable state. by adding that line to default.pa I am able to get the SPDIF to work but changing a stream from that output to any other output crashes Pusleaudio completely. Not sure where to find the logs for this.

output of Syslog after crash from moving stream away from digital out

I own an m-audio fasttrack pro, which, as far as alsa goes, is 2 devices:
-1 stereo output balanced/unbalanced (hw0,0)
-1 stereo output unbalanced/spdif + 2 inputs balanced/unbalanced

card 1: Pro [FastTrack Pro], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Pro [FastTrack Pro], device 1: USB Audio [USB Audio #1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

this card is designed with the idea that you can choose any of the outputs or output/input combinations. However, the pulse autodetection will add only one of these. Now I can add the other device manually of course, but, since this is a usb device, that will cause pulse to not come up if the device is not connected (eg on the road, when I use the builtin card of the laptop), which means I have to either edit the default.pa file each time, or add the second m-audio device manually each time, both options being somewhat un-elegant...

There may be other devices like this, and while I agree that not everyone will want all subdevices to be in pulse, maybe an option could be created to tell the autodetect/autodetect hal modules whether you'd want it to add a lsubdevices or not?

It seems to me that lack of detection of more than the 0 device of any card is becoming a critical need for pulseaudio's future success. The forums are full of people complaining that they have no way to control their digital outputs. Another point to be made in this argument, the new video cards that support HDMI output have their sound device detected as device 2 and so are completely ignored by hal/pulseaudio.

I really think that hal/pavucontrol should present all the devices detected and let the user have control over them rather than detect only device 0 and leave the user with no control over anything that is not device 0.

Adding the combine function into the pavucontrol gui would fix a lot of these issues. So would a AC3 passthrough checkbox.

I can understand the concern of lennart:

This patch is not right. On some sound cards surround sound is implemented via a 4 stereo subdevices which are then combined into a single 7.1 device. Thus it generally doesn't make sense to open subdevices directly, because only ALSA itself knows what those subdevices are about. The proper way to open a device for digital out is using the "spdif:" ALSA device string, not directly opening subdevices which will only work on very few devices.

But it does not make any sense to just ignore the issue. ALSA has that information, it is a failure of hal-detect to get it and pass it on to pavucontrol so it can be presented to the user that is the real issue here.

I have 5 output devices I would like to use but only 2 are available in pavucontrol and only one falls into the concerns that lennart expresses. When I try to add them manually as all I get is errors and the pa daemon refuses to start. So, as a result, I have only control over 2 speakers and my headphones working on separate sound cards and no way to control the sound on the other speakers and the sound to my TVs.

Pulse Audio makes it very easy to control sound over a network, but impossible to control sound around my living room.

Replying to markfal:

But it does not make any sense to just ignore the issue. ALSA has that information, it is a failure of hal-detect to get it and pass it on to pavucontrol so it can be presented to the user that is the real issue here.

ALSA does not export this information right now. There is the the naming hinting code, but it is incomplete, usually wrong and does not include information which devices are exclusive to each other and which are not. Currently there is no better way figure out the available device than trying to open them.

I have 5 output devices I would like to use but only 2 are available in pavucontrol and only one falls into the concerns that lennart expresses. When I try to add them manually as all I get is errors and the pa daemon refuses to start. So, as a result, I have only control over 2 speakers and my headphones working on separate sound cards and no way to control the sound on the other speakers and the sound to my TVs.

If ALSA allows concurrent access to those devices you want to access concurrently, then PA will allow you to use them that way. If you say you get errors than this is either a sign that in fact those devices are not usable independantly -- or that your configuration is broken.

Pulse Audio makes it very easy to control sound over a network, but impossible to control sound around my living room.

It's not exactly PulseAudio's fault. We build on top of ALSA, and ALSA is lacking in this area and needs to be fixed first.

Rest assure that this general issue is not ignored. However, the problem is much harder to fix than most people might assume.

Thanks for the quick reply. I suspected that there might have been some issue having to do with how alsa presents sound card info....

But anyway, is there any hope that this issue will be resolved anytime in the next few years?