Re: [RFC PATCH v2 5/5] ASoC: apple: Add macaudio machine driver
On 9. 6. 2022, at 17:50, Mark Brown broonie@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@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?
On Thu, Jun 09, 2022 at 06:19:37PM +0200, Martin Povišer wrote:
On 9. 6. 2022, at 17:50, Mark Brown broonie@kernel.org wrote:
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.
Sure, but why?
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?
Yes, that should DTRT. If the mux is working properly with DAPM (not sure it does with DPCM but ICBW) then you shouldn't even need the jack integration since the mux would disconnect the unused output when it gets switched.
participants (2)
-
Mark Brown -
Martin Povišer