[pulseaudio-discuss] [PATCH] Added module-ofono-switch-on-voicecall

Felipe Tonello eu at felipetonello.com
Wed Mar 26 09:17:30 PDT 2014

Hi Tanu,

On Wed, Mar 26, 2014 at 1:03 AM, Tanu Kaskinen
<tanu.kaskinen at linux.intel.com> wrote:
> On Tue, 2014-03-25 at 11:21 -0700, Felipe Tonello wrote:
>> Hi Tanu,
>> On Tue, Mar 25, 2014 at 1:05 AM, Tanu Kaskinen
>> <tanu.kaskinen at linux.intel.com> wrote:
>> > On Mon, 2014-03-24 at 14:32 -0700, Felipe Tonello wrote:
>> >> On Mon, Mar 24, 2014 at 1:18 AM, Tanu Kaskinen
>> >> > Why does this module have to be loaded before module-syspend-on-idle?
>> >> > Such load order restrictions should be avoided if at all possible.
>> >>
>> >> IIRC this was necessary because the sink/source new callback from this
>> >> module had to be called first then the one from
>> >> module-suspend-on-idle. Does it make sense?
>> >
>> > Not really. You're using different hooks than module-suspend-on-idle, so
>> > the module loading order has no effect on the order of the callbacks.
>> True. So perhaps there is no reason for the order anyway.
>> >
>> > This "prevent idle suspending" logic doesn't really belong to this
>> > module anyway, because this module is a policy module, but the "don't
>> > suspend on idle" property is part of the device, not part of the policy,
>> > in my opinion.
>> That's way this is optional. The parameters "sink" and "source" are
>> optional. This module was intended to be used in embedded devices
>> where the device configuration is well defined. Well, that was my
>> original intent.
> Switching the card profile on certain oFono-based triggers and
> preventing some devices from idle-suspending are completely orthogonal
> features, I don't see any good reason to have them in the same module.

I agree. But in practice this is very often useful. That's why I wrote
in a way that this feature is optional.

>> > Ideally the device would set the property by itself. Is
>> > it possible for you to set the property as part of the device
>> > configuration? Do you use static configuration in default.pa or UCM or
>> > path configuration files?
>> I use UCM files for path configurations.
>> Is it possible to change PA properties from a device configuration
>> file? I don't see any way to do that in the device configuration.
> I think the UCM code in PulseAudio should somehow automatically detect
> that this device is a dummy device that actually just controls the DSP
> routing. Could you share the UCM configuration and "pactl list cards"
> output so I have a better idea of the setup? I can't give concrete
> suggestions about how to implement the auto-detection without
> understanding the setup better.

I don't have access to it right now. But why would this be useful
anyway? How do you suggest us to implement this in UCM, since UCM
library doesn't have any option for that? Maybe add a PA specific

> Another idea would be to add a "devices_to_ignore" option to
> module-suspend-on-idle, but in my opinion that would be just a
> workaround, not a proper fix.

I prefer the UCM solution also.


More information about the pulseaudio-discuss mailing list