[alsa-devel] question on snd_soc_dai_link_event
Hi, I have one question about current implementation of function snd_soc_dai_link_event Currently, on power up, it calls hw_params on the source and sink dai drivers, and digital_mute(0) on the sink dai driver
I wonder why it does not call the full hw_params / prepare / trigger sequence on both dai drivers to start the 2 DAIs.
Thanks in advance Regards, Sebastien
On Fri, Oct 26, 2012 at 01:58:54PM +0200, Sebastien LEDUC wrote:
Fix your mailer to word wrap within paragraphs, it makes your mails hard to read if you don't do this. I've reflowed for legibility.
I wonder why it does not call the full hw_params / prepare / trigger sequence on both dai drivers to start the 2 DAIs.
None of the drivers that use this actually have any of those calls so I didn't bother. Especially in the case of trigger it's unlikely that an off-SoC device without DMA would need this, though of course it could happen.
Hi Mark
One further question on the dai_link widget mechanism.
Currently the code in soc_probe_link_dais, the code will call snd_soc_dapm_new_pcm to create the dai_link widget and the routes.
For a capture stream, it creates the following routes: Cpu_dai widget -> dai_link widget -> codec_dai widget
And for a playback stream: Codec_dai widget -> dai_link widget -> cpu_dai widget
Shouldn't it be the opposite directions in both cases? Or did I miss something?
Thanks Regards Sebastien
On Wed, Nov 21, 2012 at 06:56:55PM +0100, Sebastien LEDUC wrote:
For a capture stream, it creates the following routes: Cpu_dai widget -> dai_link widget -> codec_dai widget
And for a playback stream: Codec_dai widget -> dai_link widget -> cpu_dai widget
Remember that for a CODEC<->CODEC link both devices will be CODECs so their widgets have the opposite sense as everything is named in a CPU centric fashion. The important thing is that we link playback to capture and capture to playback.
Hi Mark, Coming back on this topic: We are trying to use the codec <-> codec approach to model our on-SoC DSP. So in our case it would be quite important that the full sequence of ops is called, so that we are not dependent on which ops the codec we use is relying on.
I am even thinking that it could be worth creating an internal PCM for the dai link that has the params field, and to call the standard soc functions (soc_pcm_open, ...) on it from the dai_link widget DAPM callback to start / stop the PCM.
Any feedback?
Thanks Regards Sebastien
-----Original Message----- From: Mark Brown [mailto:broonie@opensource.wolfsonmicro.com] Sent: Friday, October 26, 2012 7:02 PM To: Sebastien LEDUC Cc: alsa-devel@alsa-project.org; Liam Girdwood (lrg@ti.com) Subject: Re: question on snd_soc_dai_link_event
On Fri, Oct 26, 2012 at 01:58:54PM +0200, Sebastien LEDUC wrote:
Fix your mailer to word wrap within paragraphs, it makes your mails hard to read if you don't do this. I've reflowed for legibility.
I wonder why it does not call the full hw_params / prepare / trigger sequence on both dai drivers to start the 2 DAIs.
None of the drivers that use this actually have any of those calls so I didn't bother. Especially in the case of trigger it's unlikely that an off-SoC device without DMA would need this, though of course it could happen.
On Fri, Jan 18, 2013 at 03:07:29PM +0100, Sebastien LEDUC wrote:
Once again, don't top post.
I am even thinking that it could be worth creating an internal PCM for the dai link that has the params field, and to call the standard soc functions (soc_pcm_open, ...) on it from the dai_link widget DAPM callback to start / stop the PCM.
Any feedback?
I think what's important here is that any resulting code looks sane and works well; I'm not sure that going all the way up the stack is going to help with that as you're more likely to expose assumptions about the calling environment but I've not paid it much concrete attention.
participants (2)
-
Mark Brown -
Sebastien LEDUC