[pulseaudio-discuss] Using "expect" to feed pacmd

[Colin Guthrie]

'Twas brillig, and Whit Blauvelt at 10/09/10 13:01 did gyre and gimble:
> On Fri, Sep 10, 2010 at 10:07:25AM +0100, Colin Guthrie wrote:
> 
>> The default.pa is processed on PA startup, so if you were to put such
>> commands at the end of the default.pa (or better create your own
>> default.pa in ~/.pulse/default.pa with the following contents:
>>
>> .include /etc/pulse/default.pa
>> .nofail
>> set-default-source
>> alsa_input.usb-Generic_FREETALK_Everyman_0000000001-00-Everyman.analog-stereo
>> .fail
>>
>> You'll notice the use of .nofail and .fail there. This starts a generic
>> block where any errors are ignored. This will mean that if you do not
>> have the USB plugged in when pulse starts, it will not care that it did
>> not manage to set the default.
> 
> Here's the problem with that attempt at a solution: As I wrote before,
> having a ~/.pulse/default.pa with the one line causes pulseaudio to refuse
> to start _even with the usb headset plugged in_, so if I add the .nofail
> conditional to it, it still will be the case that setting the default source
> at this point will fail - it will just be ignored rather than blocking the
> whole startup (which is unnecessarily fragile - a failure should be logged
> and sent to console, but not kill the startup).

"Unnecessarily fragile? I don't think so. The default.pa is meant to
essentially be a startup script and I want to know when things in it
fail. I want proper failures, not "something's broken, but I'll try and
hide all the details from you so that you can carry on in your bubble of
blissful ignorance". If you mess with the script you should be told in
no uncertain terms that you've cocked it up.

That's the whole point in the fail/nofail modes. We want to be strict by
default and if you have a valid reason for doing a "hit and hope"
command, then you can.

This is simply a difference of opinion and, quite frankly, it's over a
detail that is very much at the bottom of any priority lists regarding
any developer focus.

> If we're to trust the error
> message pulseaudio throws without the .nofail conditional, it's trying to
> run default.pa commands before the system has loaded a necessary module.

Well depending on where you put the command in the default.pa script,
that is when it's executed. If you put *only* that line in your
~/.pulse/default.pa then nothing else will be run and it will of course
fail.

You need to include the system default.pa first via ".include
/etc/pulse/default.pa", then you can put your command. But as it's a
removable device, I'd very much advise against doing this.

Ultimately this is not really what default.pa is designed for. Setting
of default devices (especially removable ones) should be handled by
policy/routing modules. I've already provided a link to my article about
the overhauls I want to see in this area.

> So
> there's no way it could set the default even if it wanted to. If I compiled
> a monolithic kernel it would fix that; but most everyone runs distro kernels
> with modules these days. 

OK, now You've lost me. I really don't follow this logic.

> Perhaps Canonical/Ubuntu needs to improve the
> init.d/pulseaudio script to insure the modules are all loaded before
> pulseaudio is invoked. Haven't studied how they've handled that. Shouldn't
> need to. This isn't supposed to be for users to correct.

As stated previously this init script to which you refer should
generally NOT be used on 99% of user setups so it's irrelevant. I think
you've misanalysed your actual problem.

> Even if default.pa could set the default then, the default goes away as soon
> as the usb device is unplugged. But it can't even set it to begin with.
> Probably I could actually get the default initially set through System >
> Preferences > Startup Applications and then including my expect script
> there, or the like.

As stated in my very first reply, you're attempting to do something that
is not currently supported. I explained this and gave a link to my
proposal to fix it which I'll get round to implementing sooner or later.

You then tried to suggest there would be a work around, which I
entertained as a stop-gap and tried to advise as best I could. You now
seem to be taking your work-around far too far and making assumptions
and such like that really aren't warranted. The correct way of fixing
this was already identified in my first reply.

In other words, don't get too carried away :)

> Col, you're responsiveness on this list is a great asset to the project.
> Good luck getting the main players to agree to your plans to make the
> central design better. It's to further your efforts that I'm giving you this
> critique. I know it's mostly not your own work that's so full of design
> flaws.

I wouldn't say it's "full of" design flaws. There are some API quirks
that are a result of an evolving process and the routing/policy module
implementations are not something I'm currently happy with, but that's
very different from a design flaw - it's just a current implementation
detail I happen to disagree with.

Take care and I hope you get your workaround implemented to your
satisfaction until we fix it properly.

Col


-- 

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

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]