Re: [PATCH 0/3] Fallback mechanism for pulse plugin

[David Henningsson <david.henningsson@canonical.com>]

On 09/14/2011 12:35 PM, Colin Guthrie wrote:
> 'Twas brillig, and David Henningsson at 14/09/11 10:51 did gyre and gimble:
>> On 09/13/2011 10:47 AM, Colin Guthrie wrote:
>>> 'Twas brillig, and Takashi Iwai at 13/09/11 08:55 did gyre and gimble:
>>>>> Yup I think so. I'll put this on my list (I did try and suggest
>>>>> something like this a while back, but got little in the way of
>>>>> responses
>>>>> - I wanted to standardise things rather than have distro hacks
>>>>> everywhere - can't seem to find the email now, so I'll just resend it
>>>>> when I have some time to think straight)
>>>>
>>>> Yeah, we want to have some really easy way to check whether PA is
>>>> enabled or not.  For example, in the case of X11, you can check
>>>> $DISPLAY (or options are given explicitly) as a primary check.
>>>
>>> Yeah, but sadly I don't think this is possible. The Ubuntu solution for
>>> example works differently to yours. (Disclaimer, I've already said I
>>> think this is ugly). It works by altering the config file dynamically
>>> such that the default is either dmix or pulse depending on whether PA is
>>> running. Of course "PA is running" is a broken check in the first place
>>> (see the "ugly" word in my disclaimer!) as we could be dealing with thin
>>> clients and remote PA daemons only, in which case there is no running
>>> PA.
>>
>> I think adding a function in libpulse named is_PA_enabled() makes sense,
>> as discussed somewhere else in this thread. Once we have that, we should
>> change "PA is running" to "file_exists(libpulse.so.x)&&
>> dlopen(libpulse.so.x)&&  is_PA_enabled()". Does that seem to be a
>> reasonable solution?
>
> It depends on how clever the check is.

That would be an PulseAudio internal problem, I assume - i e, it is up 
to PulseAudio to make that check clever enough, or face the wrath of 
ugly workarounds ;-)

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic