[Sound-open-firmware] [PATCH 1/2] uapi: ipc: Add lbm in sof_ipc_dai_config

[Pierre-Louis Bossart]

On 06/04/2018 11:48 AM, Liam Girdwood wrote:
> On Mon, 2018-06-04 at 10:08 -0500, Pierre-Louis Bossart wrote:
>>>>> loopback is not tied to HW config, it can be enabled/disable at runtime
>>>>> so
>>>>> hould use the standard IPC for component commands like volume.
>>>> OK, this is done by suggestion from Pierre to not use a kcontrol but a
>>>> static topology token,
>>>> So if it is need to be runtime enable/disable. Then a kcontrol or a
>>>> debugfs should be used?
>>> kcontrol is more flexible since we don't have to change topologies and they
>>> should come as standard with all SSP topologies.
>> I don't really agree here. If a user sets the loopback kcontrol there's
>> no audio any more. "Be careful what you wish for" seems to apply here,
>> this will generate support issues.
> We've had this in ALSA/ASoC with the codecs for some while now so most users
> will do a alsactl or UCM file with good settings. I know it's very easy to
> change the route with alsamixer/amixer and mute the output, but I think adding
> one more here probably wont matter that much.
>
>> LBM is only useful in test modes, and
>> there's no problem generating test configurations.
> LBM is very useful for debug/integration usages and it's easier/quicker to ask a
> user to enable the LBM kcontrol as a test than to modify their topology or use
> the test topology (which may not be valid for them).
It's a one-line addition to an alsa-lib .conf file compared to the risk 
of broken kcontrols when users don't know what they are doing - which is 
about 80% of support requests. There are just too many people out there 
playing randomly with amixer/alsamixer and then reporting issues.
If you still want to go with the kcontrol, then make it conditional on a 
kernel module parameter to avoid accidental settings.
Or we could go the debugfs route, with a root controlled access.
The kcontrol accessible to everyone is just too flaky in my opinion.