HAL, sound cards and laptops

[Danny Kukawka]

Hi, 

after discussion with our ALSA guy at SUSE (Takashi Iwai), my comments:

On Sunday 06 August 2006 23:53, Lennart Poettering wrote:
> We're currently working on adding HAL support to PulseAudio. While
> working on it I noticed a few things:
>
> - My laptop has a softmodem which is available as ALSA device on
>   Linux. Currently there is no way to tell the difference between a
>   real sound card and such a modem in HAL. Therefore I would like to
>   suggest adding a new property to HAL for alsa, perhaps called
>   "alsa.class" or something which can take the value "modem" or
>   "audio". Because the ALSA API doesn't offer a way to query if
>   something is a modem or not this property should probably be set by
>   an .fdi file. Because the PCI device class is "7" for a modem and
>   "5" for a real sound card that .fdi file should be very easy to
>   write.

No, this could not work, because this is only correct for AC97 devices, but 
e.g. not for HD-audio PCI device which provide modem and sound device in the 
same pci device/chip. There is a way to detect if this is a modem or a sound 
devivce via alsa (but I'm not sure if we should add alsa-lib as dependency 
atm):

	#include <alsa/asoundlib.h>

	snd_pcm_info_t *info;

	snd_pcm_info_alloca(&info);
	snd_pcm_info(pcm_handle, info);

	switch (snd_pcm_info_get_class(info)) 
	{ 
		case SND_PCM_CLASS_MODEM:
			/* it's modem */
			...
		case SND_PCM_CLASS_GENERIC:
			/* standard device */
			...
		case SND_PCM_CLASS_MULTI:
			/* multichannel device */
			...
		case SND_PCM_CLASS_DIGITIZER:
			/*	digitizer device */
			...
	}

> - Currently all OSS devices appear twice in HAL. Once for /dev/audio
>   and once for /dev/dsp. Apart from this property "oss.device_file"
>   they both have all the same properties. AFAIK the two OSS device files
> are practically identical, except they have a different set of defaults. In
> PulseAudio we want only one of the two devices. Which one is not important
> for us. But we do not want them listed both. 
[...]
>   Therefore I'd like to suggest removing the /dev/audio
>   devices from HAL's device tree. Nobody uses them anyway and they are
>   fully redundant. If there is a good reason to keep them, then I
>   would at least suggest adding some kind of property to tell them
>   apart cleanly.

In fact they are both for different tasks:
	* /dev/audio for Sun-like systems, e.g. 8000Hz mu-law format as default
	* /dev/dsp is for the generic PCM use

There are maybe some applications using also /dev/audio. IMO we don't need to 
remove /dev/audio until they are in the kernel. You should be able to filter 
out the devices you would like to display in your application.

> - My laptop has a sound card which does 5.1 audio. At least that's
>   what ALSA says. In reality however, there are only stereo speakers
>   in the machine and the only audio jack is stereo, too. I would like
>   to see this information exposed in HAL. Something like
>   "alsa.physical_audio_channels" which would be set according to some
>   DMI data. I don't know HAL that well, but I am sure that this can be
>   done in .fdi files.

----------------------
Comment from Takashi Iwai:

One problem is that the available channels on a device is unknown in many 
cases.  At least, you have no ways to check whether the surround or rear is 
really available with AC97 codec.  If the codec chip supports, the driver 
assumes that the I/O jack is implemented. Hence, we'd need a _large_ table 
listing _every_ device in the market.

In the case of HD-audio devices, it's possible to know beforehand. But 
currently there is no certain API to inform the max "hardware" channels, 
because you can anyway emulate hardware capabilities on software, or even 
combine multiple soundcards as if a single card...

In future, most machines will be replaced with either HD-audio or others that 
are capable to tell more details of the hardware. Then such a thing will 
become easier.
----------------------

IMO the cost of such a list is very high. Is this really needed?

Cheers,

Danny