[pulseaudio-discuss] Dealing with the PC speaker sound output via ALSA, aka snd-pcsp

[Lennart Poettering]

On Fri, 12.09.08 20:03, Luke Yelavich (themuso at ubuntu.com) wrote:

> Greetings all,

Heya!

> Ubuntu intrepid will be shipping kernel version 2.6.27, and alsa
> 1.0.17. However, for some reason which I am not really sure of yet,
> our kernel team have enabled snd-pcsp, and disabled pcspkr,
> resulting in the PC speakerbeing available for audio output. We have
> also added relevant options to ensure that snd-pcsp is not the first
> card, however when pulseaudio loads, hal lists the PC speaker device
> first, causing pulseaudio to use it as the default sink, unless the
> user has configuration present that states otherwise.

The order in which audio devices are initialized is nowadays not
deterministic anymore since all drivers are initialized fully in
parallel. That's why PA identifies devices by their HAL UDI and
defines no particular order (HAL UDIs suck,  too, but they are a still
vastly more useful than alsa device indexes)

Enabling snd-pcsp by default is -- quite frankly -- just crazy. What's
the point of doing that? It's a toy. Nothing more than a toy.  Having
it enabled will confuse the user, creates a wide range of problems
like the one your email is about and brings absolutely zero value. In
fact, snd-pcsp is a great way to burn a lot of CPU cycles for nothing.

snd-pcsp might be useful for a few embedded use cases, where no real
sound card exists. But that's not the case for the machines Ubuntu is
designed for!

The right fix for this issue is to disable snd-pcsp. All reasonable
distros disable it by default. And Ubuntu should too.

> At the moment, I have patched the hal module to prevent the PC
> speaker being available as a sink, however from arguments put to me,
> the PC speaker being available as a sink *MAY* be useful at times.

I seriously doubt snd-pcsp has any use for anything except very exotic
embedded systems. It should *never* be activated by default. People
who think it is useful to them are certainly capable of specifically
configuring PA and ALSA to enable it.

I'd love to see those "arguments" in favour of enabling snd-pcsp by
default.

> Attempting to look at this from an upstream's point of view, I think
> it would be better to patch the hal module to enable the PC speaker
> as a sink option, but after all other sinks have been set up,
> ensuring that the PC speaker sink will only be used if the user
> requests it. However, you may well want to blacklist it entirely.

PA doesn't really impose any order of devices. If a "default" device
is required and none has been set we pick one. Which one we
pick is not random, but not deterministic either -- you should not
depend on any order.

> So I'm interested in people's thoughts on the matter. If Lennart
> thinks its worth changing something along either these two lines,
> I'm happy to send a patch through.

Again, I think enabling snd-pcsp is a particularly bad idea. However,
one item that has been on my todo list might be interesting to you:

Right now if an USB and a PCI device are found it is not defined which
one becomes the default. I do think however that picking the PCI card
as default has a bigger chance to be the right pick. Hence what I'd
love t see is having a module that is loaded after
"module-default-device-restore" and checks whether any default device
has been set at that point (i.e. if m-d-d-r was able to restore any
settings). If not, and there's more than once device available, it
would choose one as default based on some heuristics. The heuristics I
thought about were mostly about preferring PCI over USB over BT and
generally hw devices over network devices. We could add an additional
rule that would make sure that we'd never pick snd-pcsp as default.

Writing this module is not a top priority for me though. It's however
probably very easy to implement and I am happy to take patches! The
only (minor) difficulty I see might be that ALSA doesn't export any
information about busses to us. But that should be easy to fix: we
could just extend module-hal to pass that propertiy to
module-alsa-sink for each instance. I.e. module-alsa-sink should get a
new option "properties=foobar=waldo,bus=pci,brumm=miau" and so
on. Those properties would just be added as sink properties. Pretty
trivial.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4