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.