[pulseaudio-discuss] [PATCH] suspend-on-idle: Allow disabling suspending for specific devices

[Arun Raghavan]

On Fri, 2013-08-30 at 15:11 +0200, David Henningsson wrote:
> On 08/30/2013 09:28 AM, Tanu Kaskinen wrote:
> > On Fri, 2013-08-30 at 08:16 +0200, David Henningsson wrote:
> >> On 08/29/2013 04:36 PM, Tanu Kaskinen wrote:
> >>> Sometimes it would be nice to disable module-suspend-on-idle for
> >>> specific devices. For me the use case is to keep a HDMI sink running
> >>> all the time to avoid loss of audio when starting to play a stream to
> >>> the device (the HDMI receiver eats a bit from the beginning of the
> >>> stream when the device is opened). This is arguably a hacky solution
> >>> to the problem, but on the other hand, I think it's very sensible to
> >>> interpret negative timeout in the module-suspend-on-idle.timeout
> >>> property as disabling the suspending altogher. This is also how the
> >>> exit-idle-time configuration option behaves (negative value disables
> >>> automatic exiting).
> >>
> >> Didn't Arun have another solution for a similar problem? Like a sink
> >> ALWAYS_RUNNING flag or something.
> > 
> > Yes, he did. That patch was not merged, and I don't know if Arun plans
> > to still work on it.
> > 
> > Regardless of Arun's solution, I think it makes sense to support
> > negative value for the module-suspend-on-idle.timeout property to be
> > consistent with other timeout parameters.
> > 
> 
> Hmm, it looks like there already is a module-suspend-on-idle.timeout
> property and you're just improving its functionality. Then I would
> typically prefer this over a new sink flag.
> 
> Even better if the module-suspend-on-idle.timeout was documented though...
> 
> Arun, would this solve your problem as well? Would it be possible for
> the two of you to synchronise your efforts?

Tanu and I discussed this on IRC. I don't think we should use this
property to do what I was trying to with ALWAYS_RUNNING - the module
parameters is mechanism, and the always-running-ness is policy. Don't
want to mix the two.

That said, I've no objection to what the patch is trying to do, per se
(i.e. extend/standardise the semantics of a device property that we
already support).

-- Arun