Hi Liam,
Ping for RFC.
This is my previous kcontrol solution for topology part.
Does this can work with the runtime switch to loopback mode?
On 6/1/2018 11:24, Pan, Xiuli wrote:
On 6/1/2018 07:15, Ranjani Sridharan wrote:
On Thu, 2018-05-31 at 16:08 -0500, Pierre-Louis Bossart wrote:
On 5/31/18 12:37 PM, Ranjani Sridharan wrote:
On Thu, 2018-05-31 at 07:55 -0500, Pierre-Louis Bossart wrote:
On 5/30/18 9:08 PM, Pan, Xiuli wrote:
On 5/30/2018 21:06, Pierre-Louis Bossart wrote: > On 5/30/18 4:51 AM, Xiuli Pan wrote: >> From: Pan Xiuli xiuli.pan@linux.intel.com >> >> Have some clean up for the code may used. >> Add some macros that are needed for the switch widget. >> TODO: Have the useable get/put function for the kcontrol. >> >> Pan Xiuli (5): >> topology: mixer: Add CONTROLMIXER_MIN >> topology: utils: Add kdapm macro for route with >> kcontrol >> topology: m4: add switch widget >> topology: sof: add pipeline loopback dai >> topology: test: add loopback test topology > What do you mean by "loopback"? > a) enabling capture on SSP with hardware LBM (LoopBackMode) - > mirroring the playback data? > b) enabling a capture-to-playback hostless pipeline - > mirroring > the > capture data? I think the it should be the a). This will try to enable SSP driver loopback mode with a kcontrol.
Not sure if it's wise to expose a kcontrol to users for what is largely a test capability - not to mention that you will not typically turn this on/off dynamically. I'd suggest looking into using the topology+IPC to enable such custom tests.
If it is not needed to turn this ON/OFF dynamically, then could we possibly just use a test FW with loopback mode enabled by default instead? That way we can avoid the extra work on the topology/driverside.
It's one token and one field in the IPC structure, with no framework change. Compare that with requiring everyone to create a custom firmware when they want to test if the output looks correct...
I take Pierre's suggestion with the TOKEN version.
Thanks Xiuli
Fair enough. I think topology is certainly the way to go.
Xiuli, now that you dont need a kcontrol, are you still going to work on that patch with a generic switch IO handler? Or should I take care of it?
I think Pierre give me another solution for this loopback mode. I would like to do a cleanup for the topology with kcontrol. But I think it is not in high priority right now. We can have a sync later about how to make all kinds kcontrol work with topology.
Thanks Xiuli
Maybe we can try to make the b) also work.
Thanks Xiuli > >> topology/m4/mixercontrol.m4 | 16 ++++-- >> topology/m4/switch.m4 | 46 >> +++++++++++++++ >> topology/m4/utils.m4 | 4 ++ >> topology/sof/pipe-dai-loopback.m4 | 36 >> ++++++++++++ >> topology/sof/pipe-low-latency-capture.m4 | 3 +- >> topology/sof/pipe-low-latency-playback.m4 | 2 + >> topology/sof/pipe-pcm-media.m4 | 1 + >> topology/sof/pipe-tone.m4 | 2 + >> topology/sof/pipe-volume-capture.m4 | 1 + >> topology/sof/pipe-volume-playback.m4 | 1 + >> topology/test/test-loopback-ssp.m4 | 94 >> +++++++++++++++++++++++++++++++ >> topology/test/tplg-build.sh | 2 +- >> 12 files changed, 201 insertions(+), 7 deletions(-) >> create mode 100644 topology/m4/switch.m4 >> create mode 100644 topology/sof/pipe-dai-loopback.m4 >> create mode 100644 topology/test/test-loopback-ssp.m4 >> _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-fir mwar e
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmw are
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmwar e
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware