Phonon problems in Debian

Colin Guthrie gmane at colin.guthr.ie
Sun Jan 30 10:55:25 GMT 2011


'Twas brillig, and Pedro Lopez-Cabanillas at 23/01/11 18:31 did gyre and
gimble:
> On Sunday 23 January 2011, Colin Guthrie wrote:
>> 'Twas brillig, and Thiago Macieira at 23/01/11 13:44 did gyre and
>> gimble:
>>> On Sunday, 23 de January de 2011 13:18:31 Colin Guthrie wrote:
>>>> 'Twas brillig, and Thiago Macieira at 19/01/11 23:05 did gyre
>>>> and gimble:
>>>>> On Wednesday, 19 de January de 2011 22:12:32 Colin Guthrie
>>>>> wrote:
>>>>>>> How do you detect if PA is used?
>>>>>> 
>>>>>> I just attempt to connect to the PulseAudio daemon. If I
>>>>>> get a connection it's there, and if not, it's not. It's
>>>>>> quite simple really.
>>>>> 
>>>>> Except, of course, when PulseAudio is running (it starts
>>>>> itself) but audio routing is done via ALSA straight to the
>>>>> kernel.
>>>> 
>>>> Not sure I follow your point here...
>>> 
>>> I mean systems like mine, where ALSA is configured to go to the
>>> kernel, not to pulseaudio.
>>> 
>>> But pulseaudio is running. It's unused and useless.
>> 
>> There is very, very little point in configuring a system where PA
>> is running and ALSA is not directing the "default" device to PA. To
>> do so would be an exercise in frustration and strange errors.
>> 
>> If you don't want to use PA then fine, but don't configure it to
>> run. If your distro behaves itself, then it'll offer easy ways to
>> configure this. If not then you'll have to do it yourself (disable
>> autospawn and stop the XDG autostart files from firing).
> 
> There may be good reasons to keep the PA daemon running, even when
> you don't need it all of the time. For instance, to avoid a problem
> like this https://support.mozilla.com/en-US/questions/732071 If there
> are problems when the PA ALSA plugin is too bored because programs
> are not using it, this should be addressed and fixed.

I don't deny that there may be good reasons to run this setup, but this
certainly isn't one of them (and I can't think of any others either, but
they may, of course, exist!)

Whatever the problem there, it's very likely not the primary *solution*
to the problem (perhaps something as simple as doing "export
CANBERRA_DRIVER=alsa" would fix it for example)

> On the other hand, the "default" device is only that, a default
> setting. Most ALSA enabled programs can be configured to open one
> device name or another. Only when the user didn't bother to provide
> some other device name the default device is used. In addition to the
> ALSA plugin, PulseAudio has also a native API that may be supported
> by some programs as a configuration setting, and it requires the PA
> daemon running.

I've very well aware of these issues (see sig!) but that doesn't change
the point I'm making. While most applications do provide some form of
configuration (which is something I'd very much like to see phased out -
consistent and central Desktop Environment provided UI for adjusting
sound preferences in all apps is the primary aim, rather than confusing,
inconsistent and hidden options, buried under several menus and config
panes in different applications does not help novice users configure
things to their tastes), the OOTB experience has to be one that is not
prone to errors. If the setup is PA running + ALSA NOT redirected, then
the potential for device open errors increases massively: either PA or
the native application will hog the device causing one or the other to fail.

So I stand by my original point. Either use PA completely, or don't use
it at all.

I'd say the only case for a half-way house setup would be for experts
who are very well aware of their choices. They would manually ensure
that the cards available to alsa were configured in PA to have a profile
of "Off" (thus PA wont even try to use them) and you'd only use PA for
network tunnels, bluetooth or other similar systems. But even they I'd
have to question why such a user would not just use PA at all times
anyway, as many of the nice features are lost by excluding the built in
h/w. (e.g. hotswap of devices and timer based scheduling).

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]



More information about the kde-multimedia mailing list