HAL, sound cards and laptops

Lennart Poettering mzuny at 0pointer.de
Mon Aug 7 13:46:34 PDT 2006


On Mon, 07.08.06 19:22, Danny Kukawka (danny.kukawka at web.de) wrote:

> > - 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 

I am pretty sure that it is not difficult to write a FDI file to
tell apart audio and modem for both AC97/MC97 and the HD-audio stuff.

> devivce via alsa (but I'm not sure if we should add alsa-lib as dependency 
> atm):

Oh, I wasn't aware of snd_pcm_info_get_class(), thanks for the pointer!

But: This would require opening the audio device just for querying
this minor information.  This is definitely a no-no in my eyes and
makes it unusable for usage in PulseAudio.

> > - 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

As I wrote in my original mail: they are the same besides a different set
of defaults. With "defaults" I referred to 8000Hz mulaw.

Quoting the OSS Programmer's guide:

<snip>
The /dev/audio and /dev/dsp device files are very similar. The
difference is that /dev/audio uses logarithmic mu-law encoding by
default while /dev/dsp uses 8-bit unsigned linear encoding.  With
mu-law encoding a sample recorded with 12 or 16-bit resolution is
represented by one 8-bit byte. Note that the initial sample format is
the only difference between these device files. Both devices behave
similarly after a program selects a specific sample encoding by
calling ioctl. The /dev/audio device is provided for compatibility
with the sound device provided on Sun workstations running
SunOS. These device files can be used for applications such as speech
synthesis and recognition and voice mail. 

Although /dev/audio provides minimal compatibility with Sun's API,
there is no support for Sun's ioctl() interface. OSS under Solaris
emulates these calls to some degree to provide compatibility with
existing Solaris and SunOS applications, however this emulation is not
officially supported by 4Front Technologies.
</snip>

http://www.opensound.com/pguide/oss.pdf, page 11.

I read it like this: /dev/audio is a compatibility kludge for some
legacy applications. And things like that should not show up in HAL,
should they?

Applications which are modern enought to make use of HAL are
definitely not interested in the obsolete /dev/audio interface, i
would argue.

> 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.

What kind of filter would you suggest? If you read my original mail
closely you'll see that besides doing some strncmp() on
oss.device_file there is no way to tell these devices apart. And this
is really ugly. 

Legacy apps which want to use /dev/audio are welcome to do so even if
that specific device doesn't show up in HAL.

> 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.

I am fully aware that this information is not available for all
hardware. But for some hardware (specifically laptops) we do know what
kinds of speakers/jacks are available. 

I am aware that this table might grow. However, I thought that is what
HAL is abaout: a database of information about the local hardware,
partially gathered from the hardware itself and partially from some
external sources such as FDI files.

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

"Needed"? HAL itself is not "needed" to play music. However it
improves user experience. And so would
"alsa.available_physical_channels" or what this property would be
called.

Anyway. Because we are not going to use that feature in the near
future in PulseAudio (see other mail for an explanation) I am not
pushing for this particular feature.

Lennart

-- 
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/


More information about the hal mailing list