Message ID | 1464673532.31906.2.camel@mtkswgap22 (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Tue, May 31, 2016 at 01:45:32PM +0800, Kai Chieh Chuang wrote: > + /* don't sent stop event if this BE is used by other FE */ > + if (event == SND_SOC_DAPM_STREAM_STOP && > + be->dpcm[dir].users >= 1) { > + pr_warn("kc, %s(), be->dai_link->name %s skip stop event\n", > __func__, be->dai_link->name); > + continue; > + } > + > snd_soc_dapm_stream_event(be, dir, event); > } If this isn't happening that seems like a bug, I'm a bit surprised nobody else ran into it? Shouldn't the counts of stream events that happen be symmetric (ie, we get as many stops as starts), or are we possibly missing some from things being switched in and out or something?
diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 70e8088..9c2d159 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -163,6 +163,13 @@ int dpcm_dapm_stream_event(struct snd_soc_pcm_runtime *fe, int dir, dev_dbg(be->dev, "ASoC: BE %s event %d dir %d\n", be->dai_link->name, event, dir); + /* don't sent stop event if this BE is used by other FE */ + if (event == SND_SOC_DAPM_STREAM_STOP && + be->dpcm[dir].users >= 1) { + pr_warn("kc, %s(), be->dai_link->name %s skip stop event\n", __func__, be->dai_link->name); + continue; + } + snd_soc_dapm_stream_event(be, dir, event);