Re: [PATCH 0/8] ASoC: SOF: power optimizations for HDaudio platforms

From: Takashi Iwai <tiwai@suse.de>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: alsa-devel@alsa-project.org, Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH 0/8] ASoC: SOF: power optimizations for HDaudio platforms
Date: Sun, 13 Jun 2021 09:25:43 +0200	[thread overview]
Message-ID: <s5h5yyi5iq0.wl-tiwai@suse.de> (raw)
In-Reply-To: <6f8c8799-2602-a5a2-cf38-cc6a11eac593@linux.intel.com>

On Fri, 11 Jun 2021 18:30:53 +0200,
Pierre-Louis Bossart wrote:
> 
> 
> > Perhaps, it may be acceptable to add a global control enum (to the control
> > API) for the ALSA card which may modify the driver behaviour / settings at
> > runtime (normal operation, battery saving operation etc.). This control can be
> > set in the UCM config. In this way, we don't need to touch the PCM API for the
> > user space at all.
> 
> If there was a mechanism based on ALSA controls for an application to
> query capabilities and set what it want to disable that would be
> fine. hwdep would be fine as well.
> 
> I don't get though how this could be 'set in the UCM config',
> different apps might have different needs. UCM files don't currently
> make assumptions on which application uses them, do they?

I also came to the idea of kcontrol instead of module parameter, and
hit to the differentiating via UCM, too.  Maybe we may provide two
different profiles and let apps choose.  But, this reaches to the
question: how to tell applications what is for.  It's also the
question if we extend the API.

Namely, the driver may inform user-space or the user-space may inform
the driver whether to allow (or to use) the rewind.  But, it doesn't
explain what cost it would need.  And that's a difficult task to
generalize it.  I can think of some API providing a preset per
scenario, e.g. power-saving, large buffer, etc.  But in this case, if
rewind is allowed, what would it mean practically?

Then, this also led me a question: what happens if you disable tsched
on PA?  It'll be essentially equivalent behavior like pipewire, and
this would be better?  Note that the latest kernel already dropped the
buffer pre-allocation for HD-audio, hence PA will take a large buffer
(for one second) per default.  I suppose that the influence of no
rewind becomes noticeable, or would it still be OK with tsched?

If tsched=0 mode works reasonably well in case of no rewind, it can be
done simply by setting SNDRV_PCM_INFO_BATCH together.  Even with this
change, we can keep the module parameter as a kill switch in case
significant regression is found.

thanks,

Takashi