[RFC PATCH v2 5/5] ASoC: apple: Add macaudio machine driver

[Martin Povišer]

> On 9. 6. 2022, at 17:50, Mark Brown <broonie at kernel.org> wrote:
> 
> On Thu, Jun 09, 2022 at 05:24:49PM +0200, Martin Povišer wrote:
>>> On 9. 6. 2022, at 17:03, Mark Brown <broonie at kernel.org> wrote:
> 
> Why is this off list?

By accident, added the CC list back with this reply (hopefully it
still attaches to the thread when people receive it).

>>> 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.
>> 
>> FWIW I know of at least one user of the WIP audio support on Macs who
>> would welcome this feature. My preference is to keep it in, but in
>> the end I guess it’s your call.
> 
> I'd rather not have this open coded in individual drivers, we already
> have an unfortunate abundance of jack detection interfaces.  If we're
> going to add anything I'd rather it were in core code and TBH I'm
> struggling to be enthusiastic.

Noted.

> Can you say anything more about the use case?

I can restate: The alleged use case is running userspace without sound
server, but having playback switch transparently between speakers and
headphones even mid-stream based on jack detection.

>>>> 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.
> 
>> I don’t understand what’s meant by streaming the same audio here.
> 
> Playing one audio stream from the host which appears on both speakers
> and headphones - I don't know what the mixing and muxing capabilities of
> the hardware are.
> 
>> Taking a guess: The existing DAPM integration can enable the headphones
>> path based on jack being plugged in, but it can’t disable the speakers
>> path like the demux does?
> 
> No, that works perfectly fine - you can enable or disable pins depending
> on the jack state.

Ah, I peeked into soc-jack.c. What about this then: If I understand what
pins represent, they would be at the remote end of the DAPM paths. So if
for the speakers I add something like

   Headphones Codec Out —> Jack pin

                       +--> Always-on pin
                       |
   Speaker Amp Out -> Mux
                       |
                       +--> Jack inverted pin

and let userspace control the mux, it would in effect support the same
use cases as what I attempted in the code so far. Sounds somewhat right?