[lkml]   [2022]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH v2 5/5] ASoC: apple: Add macaudio machine driver

> On 9. 6. 2022, at 17:50, Mark Brown <> wrote:
> On Thu, Jun 09, 2022 at 05:24:49PM +0200, Martin Povišer wrote:
>>> On 9. 6. 2022, at 17:03, Mark Brown <> 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.


> 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?

 \ /
  Last update: 2022-06-09 18:22    [W:0.076 / U:1.764 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site