[alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
Hello!
I have been working on prototypes for the ASoC OMAP HDMI audio driver to propagate events from the HDMI output (e.g., display getting enabled/disabled/suspended). This for the users of the driver to react to such events. For instance, if the display is disabled or disconected, audio could be stopped, rerouted or whatever other decision the user makes. This is needed because, if, for instance, the HDMI IP goes off, audio will stall and the audio users will only see a "playback write error (DMA or IRQ trouble?)"
In my prototypes I have used snd_soc_jack for this purpose and I have some questions:
*I see snd_soc_jack is used mostly for headsets and microphones with actual external mechanical connections. Strictly, in my case I propagate events originated by the OMAP display driver (changes in the power state), and not from external events. Some of these events are generated from an actual HDMI cable connection/disconnection, though.
*Maybe the event should be propagated by omapdss/omapdrm/drm and the entity in charge of the audio policy should listen those events instead.
*I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it is feasible for an audio driver to report events from an AV output.
I was wondering about how much sense does it make to you guys use a snd_soc_jack in this case?
Thanks in advance for your comments!
Ricardo
At Mon, 20 Aug 2012 20:47:17 -0500, Ricardo Neri wrote:
Hello!
I have been working on prototypes for the ASoC OMAP HDMI audio driver to propagate events from the HDMI output (e.g., display getting enabled/disabled/suspended). This for the users of the driver to react to such events. For instance, if the display is disabled or disconected, audio could be stopped, rerouted or whatever other decision the user makes. This is needed because, if, for instance, the HDMI IP goes off, audio will stall and the audio users will only see a "playback write error (DMA or IRQ trouble?)"
In my prototypes I have used snd_soc_jack for this purpose and I have some questions:
*I see snd_soc_jack is used mostly for headsets and microphones with actual external mechanical connections. Strictly, in my case I propagate events originated by the OMAP display driver (changes in the power state), and not from external events. Some of these events are generated from an actual HDMI cable connection/disconnection, though.
*Maybe the event should be propagated by omapdss/omapdrm/drm and the entity in charge of the audio policy should listen those events instead.
*I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it is feasible for an audio driver to report events from an AV output.
I was wondering about how much sense does it make to you guys use a snd_soc_jack in this case?
HD-audio already uses the generic jack event for the HDMI/DP connection change notification as well, so I think it would make sense in general.
Takashi
On Tue, Aug 21, 2012 at 07:28:34AM +0200, Takashi Iwai wrote:
Ricardo Neri wrote:
I was wondering about how much sense does it make to you guys use a snd_soc_jack in this case?
HD-audio already uses the generic jack event for the HDMI/DP connection change notification as well, so I think it would make sense in general.
The whole problem here is that we don't *have* a generic jack interface. We've got:
- sound/core/jack.c which was written to be a generic API and is used by everything that does jack support currently.
- sound/core/ctljack.c which was added later and provides separate in-kernel and userspace APIs and is currently only used by HDA.
- extcon which does have a good reason to be a separate API since that it's not audio specific (and is likely to be picked up by Android as the code was originally taken from there); it's currently not supported by the frameworks in ALSA. I'd suggest Pulse should be using it too.
This is a complete shambles for both driver authors and userspace, the ABI varies randomly with drivers and in theory driver authors have to implement everything three times which is just nuts.
What I'd like to see happening is that we merge ctljack into jack (since only HDA is going to be affected by that change it seems like the right direction to make the merge) and also add extcon support, I have looked at the extcon support.
Short term for drivers used on embedded systems I'd have to recommend extcon rather than anything ALSA-specific.
On 08/21/2012 02:05 PM, Mark Brown wrote:
On Tue, Aug 21, 2012 at 07:28:34AM +0200, Takashi Iwai wrote:
Ricardo Neri wrote:
I was wondering about how much sense does it make to you guys use a snd_soc_jack in this case?
HD-audio already uses the generic jack event for the HDMI/DP connection change notification as well, so I think it would make sense in general.
The whole problem here is that we don't *have* a generic jack interface. We've got:
sound/core/jack.c which was written to be a generic API and is used by everything that does jack support currently.
sound/core/ctljack.c which was added later and provides separate in-kernel and userspace APIs and is currently only used by HDA.
This is wrong. PulseAudio uses the new ctljack API. I started out with an implementation which used the input device API (sound/core/jack.c), but since some people did not like this API, the ctljack API was designed and implemented for PA to use, which it does (since PulseAudio 2.0 - the input device API implementation in PulseAudio was never merged upstream).
- extcon which does have a good reason to be a separate API since that it's not audio specific (and is likely to be picked up by Android as the code was originally taken from there); it's currently not supported by the frameworks in ALSA. I'd suggest Pulse should be using it too.
This is a complete shambles for both driver authors and userspace, the ABI varies randomly with drivers and in theory driver authors have to implement everything three times which is just nuts.
What I'd like to see happening is that we merge ctljack into jack (since only HDA is going to be affected by that change it seems like the right direction to make the merge) and also add extcon support, I have looked at the extcon support.
I don't know either why we have two different interfaces for jack detection (not counting extcon) for driver writers. I think we should merge jack and ctljack, as long as that does not mean you break anything I'm relying on in ctljack.
Maybe something for discussion at Plumbers?
Short term for drivers used on embedded systems I'd have to recommend extcon rather than anything ALSA-specific.
I thought that when Takashi did the new ctljack interface, that would effectively deprecate the old input device interface, and that ctljack was the new recommendation.
On Tue, Aug 21, 2012 at 02:30:51PM +0200, David Henningsson wrote:
On 08/21/2012 02:05 PM, Mark Brown wrote:
- sound/core/ctljack.c which was added later and provides separate in-kernel and userspace APIs and is currently only used by HDA.
This is wrong. PulseAudio uses the new ctljack API. I started out with an implementation which used the input device API (sound/core/jack.c), but since some people did not like this API, the ctljack API was designed and implemented for PA to use, which it does (since PulseAudio 2.0 - the input device API implementation in PulseAudio was never merged upstream).
...and the only thing using this API to generate events is HDA which is what I was talking about here given that this is a question from a driver point of view.
What I'd like to see happening is that we merge ctljack into jack (since only HDA is going to be affected by that change it seems like the right direction to make the merge) and also add extcon support, I have looked at the extcon support.
I don't know either why we have two different interfaces for jack detection (not counting extcon) for driver writers. I think we should merge jack and ctljack, as long as that does not mean you break anything I'm relying on in ctljack.
Maybe something for discussion at Plumbers?
We discussed this last time we all met and came to the above conclusion :/
Short term for drivers used on embedded systems I'd have to recommend extcon rather than anything ALSA-specific.
I thought that when Takashi did the new ctljack interface, that would effectively deprecate the old input device interface, and that ctljack was the new recommendation.
Android currently uses the out of tree version of the extcon ABI (like I say it's where the code originated), and some OSs do use the input ABI also but realistically if you've got to pick one Android is where the market is at.
To my knowledge no embedded OS is using the control jacks, it's possible that there's something using them as a function of using PulseAudio but the ones I'm famililar with currently ignore PulseAudio routing and just use the mixing facilities. Given the dependency on alsa-lib it'd be an inconvenient ABI to adopt for most of them.
On 08/21/2012 08:16 AM, Mark Brown wrote:
On Tue, Aug 21, 2012 at 02:30:51PM +0200, David Henningsson wrote:
On 08/21/2012 02:05 PM, Mark Brown wrote:
- sound/core/ctljack.c which was added later and provides separate in-kernel and userspace APIs and is currently only used by HDA.
This is wrong. PulseAudio uses the new ctljack API. I started out with an implementation which used the input device API (sound/core/jack.c), but since some people did not like this API, the ctljack API was designed and implemented for PA to use, which it does (since PulseAudio 2.0 - the input device API implementation in PulseAudio was never merged upstream).
...and the only thing using this API to generate events is HDA which is what I was talking about here given that this is a question from a driver point of view.
What I'd like to see happening is that we merge ctljack into jack (since only HDA is going to be affected by that change it seems like the right direction to make the merge) and also add extcon support, I have looked at the extcon support.
I don't know either why we have two different interfaces for jack detection (not counting extcon) for driver writers. I think we should merge jack and ctljack, as long as that does not mean you break anything I'm relying on in ctljack.
Maybe something for discussion at Plumbers?
We discussed this last time we all met and came to the above conclusion :/
Short term for drivers used on embedded systems I'd have to recommend extcon rather than anything ALSA-specific.
I thought that when Takashi did the new ctljack interface, that would effectively deprecate the old input device interface, and that ctljack was the new recommendation.
Android currently uses the out of tree version of the extcon ABI (like I say it's where the code originated), and some OSs do use the input ABI also but realistically if you've got to pick one Android is where the market is at.
So, it seems that the way to go is extcon. I guess that ALSA will use extcon just like today snd_jack uses the input driver. is this correct? Is there any chance that ctrljack will propagate the events through extcon? Is there any early implementation that I could look at? I am asking to know how feasible is to use ctljack today and be compatible with extcon in the future.
Thanks!
Ricardo
To my knowledge no embedded OS is using the control jacks, it's possible that there's something using them as a function of using PulseAudio but the ones I'm famililar with currently ignore PulseAudio routing and just use the mixing facilities. Given the dependency on alsa-lib it'd be an inconvenient ABI to adopt for most of them.
On Tue, Aug 21, 2012 at 08:24:45PM -0500, Ricardo Neri wrote:
So, it seems that the way to go is extcon. I guess that ALSA will use extcon just like today snd_jack uses the input driver. is this correct? Is there any chance that ctrljack will propagate the events through extcon? Is there any early implementation that I could look at? I am asking to know how feasible is to use ctljack today and be compatible with extcon in the future.
The ctljack API doesn't really map onto the other jack APIs at the minute since the in kernel representation is that it exposes the booleans directly to the callers rather than grouping them together into the overall jack.
On Tue, 2012-08-21 at 13:05 +0100, Mark Brown wrote:
On Tue, Aug 21, 2012 at 07:28:34AM +0200, Takashi Iwai wrote:
Ricardo Neri wrote:
I was wondering about how much sense does it make to you guys use a snd_soc_jack in this case?
HD-audio already uses the generic jack event for the HDMI/DP connection change notification as well, so I think it would make sense in general.
The whole problem here is that we don't *have* a generic jack interface. We've got:
sound/core/jack.c which was written to be a generic API and is used by everything that does jack support currently.
sound/core/ctljack.c which was added later and provides separate in-kernel and userspace APIs and is currently only used by HDA.
extcon which does have a good reason to be a separate API since that it's not audio specific (and is likely to be picked up by Android as the code was originally taken from there); it's currently not supported by the frameworks in ALSA. I'd suggest Pulse should be using it too.
This is a complete shambles for both driver authors and userspace, the ABI varies randomly with drivers and in theory driver authors have to implement everything three times which is just nuts.
What I'd like to see happening is that we merge ctljack into jack (since only HDA is going to be affected by that change it seems like the right direction to make the merge) and also add extcon support, I have looked at the extcon support.
Short term for drivers used on embedded systems I'd have to recommend extcon rather than anything ALSA-specific.
It's been in shambles for an absurdly long time. Would be good to actually try to tackle it again at Plumbers or sth.
-- Arun
On Fri, Aug 24, 2012 at 12:40:37PM +0530, Arun Raghavan wrote:
It's been in shambles for an absurdly long time. Would be good to actually try to tackle it again at Plumbers or sth.
I think all this really needs is someone with the time to do the work - it's more a coding problem with unifying the in kernel API than an issue with working out what to do.
On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote:
Hello!
I have been working on prototypes for the ASoC OMAP HDMI audio driver to propagate events from the HDMI output (e.g., display getting enabled/disabled/suspended). This for the users of the driver to react to such events. For instance, if the display is disabled or disconected, audio could be stopped, rerouted or whatever other decision the user makes. This is needed because, if, for instance, the HDMI IP goes off, audio will stall and the audio users will only see a "playback write error (DMA or IRQ trouble?)"
In my prototypes I have used snd_soc_jack for this purpose and I have some questions:
*I see snd_soc_jack is used mostly for headsets and microphones with actual external mechanical connections. Strictly, in my case I propagate events originated by the OMAP display driver (changes in the power state), and not from external events. Some of these events are generated from an actual HDMI cable connection/disconnection, though.
*Maybe the event should be propagated by omapdss/omapdrm/drm and the entity in charge of the audio policy should listen those events instead.
*I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it is feasible for an audio driver to report events from an AV output.
I was wondering about how much sense does it make to you guys use a snd_soc_jack in this case?
How does DRM handle audio? I made a quick grep, but I see the drm drivers only enabling the audio in the HW, nothing else.
If there's a common generic way to handle this, we should obviously use that. But if we need to choose between doing something custom or doing it in omapdrm driver, I think we should go for drm the only solution and forget about audio with omapfb.
Tomi
participants (6)
-
Arun Raghavan -
David Henningsson -
Mark Brown -
Ricardo Neri -
Takashi Iwai -
Tomi Valkeinen