On Thu, Jun 09, 2022 at 03:42:09PM +0200, Martin Povišer wrote: > > On 9. 6. 2022, at 15:16, Mark Brown <broonie@xxxxxxxxxx> wrote: > > As far as I can tell this demux is entirely software based - why not > > just expose the routing control to userspace and let it handle > > switching (which I suspect may be more featureful than what's > > implemented here)? > Well, userspace should have the other two muxes at its disposal to > implement any routing/switching it wishes -- but in addition we are > also offering letting kernel take care of the switching, by pointing > the muxes to the demux. > I assume (but I don’t know the extent of what’s possible with UCM files), > that this will be of some value to users running plain ALSA with no > sound server. That's basically no userspaces at this point TBH. I'm not convinced it's a good idea to be adding custom code for that use case. > > This should be integrated with the core jack detection stuff in > > soc-jack.c and/or the core stuff that's wrapping - that way you'll > > ensure that events are generated and status readable via all the > > interfaces userspace might be looking for. The ASoC stuff also has some > > DAPM integration for turning on/off outputs which might DTRT for you if > > you do need it in kernel. > Aren’t all the right events to userspace generated already by the > codec calling snd_soc_jack_report? I wasn't able to find any references to snd_soc_jack_report() in your series? > I looked at the existing DAPM integration but I couldn’t figure out > how to switch the demux with it. Yes, it won't do that. If you can't stream the same audio to both then you'd need something else.
Attachment:
signature.asc
Description: PGP signature
