[alsa-devel] Linking ALSA playback devices and DRM connectors
Hi,
I'm trying to link ALSA playback devices and DRM connectors. In other words, I'd like to be able to know which ALSA device I should open to play audio on a given connector.
Unfortunately, I haven't found a way to extract this information. I know /proc/asound/cardN/eld* expose the EDID-like data. However by looking at the ALSA API (also: aplay -l and -L) I can't find a way to figure out which PCM device maps to the ELD.
Am I missing something?
If not, what would be the best way to expose this?
- A symlink to the ALSA audio PCM device in /sys/class/drm/cardN-CONNECTOR? - A symlink to the DRM connector in /sys/class/sound/pcm*? - A DRM connector property? - Somehow expose the connector name via the ALSA API? - Expose the connector EDID via ALSA? - Other ideas?
Thanks!
Simon Ser
Am 04.06.19 um 17:05 schrieb Ser, Simon:
Hi,
I'm trying to link ALSA playback devices and DRM connectors. In other words, I'd like to be able to know which ALSA device I should open to play audio on a given connector.
Unfortunately, I haven't found a way to extract this information. I know /proc/asound/cardN/eld* expose the EDID-like data. However by looking at the ALSA API (also: aplay -l and -L) I can't find a way to figure out which PCM device maps to the ELD.
Am I missing something?
Is that actually fixed on all hardware? Or do we maybe have some hardware with only one audio codec and multiple connectors?
If not, what would be the best way to expose this?
- A symlink to the ALSA audio PCM device in /sys/class/drm/cardN-CONNECTOR?
- A symlink to the DRM connector in /sys/class/sound/pcm*?
If it's fixed than those two options sound sane to me.
- A DRM connector property?
If it's configurable than that sounds like a good option to me.
Anyway added our DC team, stuff like that is their construction site.
Regards, Christian.
- Somehow expose the connector name via the ALSA API?
- Expose the connector EDID via ALSA?
- Other ideas?
Thanks!
Simon Ser _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Jun 4, 2019 at 5:15 PM Christian König ckoenig.leichtzumerken@gmail.com wrote:
Am 04.06.19 um 17:05 schrieb Ser, Simon:
Hi,
I'm trying to link ALSA playback devices and DRM connectors. In other words, I'd like to be able to know which ALSA device I should open to play audio on a given connector.
Unfortunately, I haven't found a way to extract this information. I know /proc/asound/cardN/eld* expose the EDID-like data. However by looking at the ALSA API (also: aplay -l and -L) I can't find a way to figure out which PCM device maps to the ELD.
Am I missing something?
Is that actually fixed on all hardware? Or do we maybe have some hardware with only one audio codec and multiple connectors?
If not, what would be the best way to expose this?
- A symlink to the ALSA audio PCM device in /sys/class/drm/cardN-CONNECTOR?
- A symlink to the DRM connector in /sys/class/sound/pcm*?
If it's fixed than those two options sound sane to me.
- A DRM connector property?
If it's configurable than that sounds like a good option to me.
Anyway added our DC team, stuff like that is their construction site.
Regards, Christian.
- Somehow expose the connector name via the ALSA API?
- Expose the connector EDID via ALSA?
- Other ideas?
I think on our MST hw you get a combination of CRTCs x CONNECTORs on the alsa side. I.e. for every pair of connector and crtc you get a separate alsa pin. This is because with mst, you could have up to num_crtcs streams on a single connector. Not sure how to model that.
Bigger question: How do you want to make the cooperation happen? There's been some ideas floating about making the hdmi connection between drm and alsa somehow represented in the code, but nothing ever really happened. there's drm_audio_component.h, but that's just the interface, it doesn't really solve how to make the connection. Also only used by i915/hda. -Daniel
Thanks!
Simon Ser _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Jun 04, 2019 at 05:24:35PM +0200, Daniel Vetter wrote:
On Tue, Jun 4, 2019 at 5:15 PM Christian König ckoenig.leichtzumerken@gmail.com wrote:
Am 04.06.19 um 17:05 schrieb Ser, Simon:
Hi,
I'm trying to link ALSA playback devices and DRM connectors. In other words, I'd like to be able to know which ALSA device I should open to play audio on a given connector.
Unfortunately, I haven't found a way to extract this information. I know /proc/asound/cardN/eld* expose the EDID-like data. However by looking at the ALSA API (also: aplay -l and -L) I can't find a way to figure out which PCM device maps to the ELD.
Am I missing something?
Is that actually fixed on all hardware? Or do we maybe have some hardware with only one audio codec and multiple connectors?
Certain old i915 hardware is like that. You can drive multiple HDMI connectors at once but only one of them can get the audio. If you try to output audio to multiple ports at once you get no audio whatsoever. ATM we don't really handle that case properly.
If not, what would be the best way to expose this?
- A symlink to the ALSA audio PCM device in /sys/class/drm/cardN-CONNECTOR?
- A symlink to the DRM connector in /sys/class/sound/pcm*?
If it's fixed than those two options sound sane to me.
- A DRM connector property?
If it's configurable than that sounds like a good option to me.
Anyway added our DC team, stuff like that is their construction site.
Regards, Christian.
- Somehow expose the connector name via the ALSA API?
- Expose the connector EDID via ALSA?
- Other ideas?
I think on our MST hw you get a combination of CRTCs x CONNECTORs on the alsa side. I.e. for every pair of connector and crtc you get a separate alsa pin. This is because with mst, you could have up to num_crtcs streams on a single connector. Not sure how to model that.
IIRC the current i915 vs. alsa model is that for SST/HDMI you have a 1:1 relationship between the port and the pcm device, but with MST you nave a 1:1 relationship between the pipe and the pcm device.
I think the only way to have any kind of static connector<->pcm relationship with MST would involve dynamically adding/removing pcm devices when the correcponding drm connector is added/removed. If we don't want to/can't add such pcm devices then we'd need to dynamically change the symlinks/whatever whenever an MST stream is started/stopped. And probably we should do the same for SST/HDMI as well, if for no other reason than to make sure userspace is prepared for it even if they didn't test with MST.
On Tue, 04 Jun 2019 18:25:53 +0200, Ville Syrjälä wrote:
On Tue, Jun 04, 2019 at 05:24:35PM +0200, Daniel Vetter wrote:
On Tue, Jun 4, 2019 at 5:15 PM Christian König ckoenig.leichtzumerken@gmail.com wrote:
Am 04.06.19 um 17:05 schrieb Ser, Simon:
Hi,
I'm trying to link ALSA playback devices and DRM connectors. In other words, I'd like to be able to know which ALSA device I should open to play audio on a given connector.
Unfortunately, I haven't found a way to extract this information. I know /proc/asound/cardN/eld* expose the EDID-like data. However by looking at the ALSA API (also: aplay -l and -L) I can't find a way to figure out which PCM device maps to the ELD.
Am I missing something?
Is that actually fixed on all hardware? Or do we maybe have some hardware with only one audio codec and multiple connectors?
Certain old i915 hardware is like that. You can drive multiple HDMI connectors at once but only one of them can get the audio. If you try to output audio to multiple ports at once you get no audio whatsoever. ATM we don't really handle that case properly.
If not, what would be the best way to expose this?
- A symlink to the ALSA audio PCM device in /sys/class/drm/cardN-CONNECTOR?
- A symlink to the DRM connector in /sys/class/sound/pcm*?
If it's fixed than those two options sound sane to me.
- A DRM connector property?
If it's configurable than that sounds like a good option to me.
Anyway added our DC team, stuff like that is their construction site.
Regards, Christian.
- Somehow expose the connector name via the ALSA API?
- Expose the connector EDID via ALSA?
- Other ideas?
I think on our MST hw you get a combination of CRTCs x CONNECTORs on the alsa side. I.e. for every pair of connector and crtc you get a separate alsa pin. This is because with mst, you could have up to num_crtcs streams on a single connector. Not sure how to model that.
IIRC the current i915 vs. alsa model is that for SST/HDMI you have a 1:1 relationship between the port and the pcm device, but with MST you nave a 1:1 relationship between the pipe and the pcm device.
I think the only way to have any kind of static connector<->pcm relationship with MST would involve dynamically adding/removing pcm devices when the correcponding drm connector is added/removed. If we don't want to/can't add such pcm devices then we'd need to dynamically change the symlinks/whatever whenever an MST stream is started/stopped. And probably we should do the same for SST/HDMI as well, if for no other reason than to make sure userspace is prepared for it even if they didn't test with MST.
The idea with the dynamic PCM device creation pops up occasionally, but it never flies. The biggest reason so far is the support of PulseAudio and others; although PA can deal with the hotplug *card* device, the devices below the card level aren't managed dynamically, hence the dynamic creation of PCM device doesn't work for them.
From API POV, the cleanest way would be to provide some information over ALSA control element for each PCM stream that indicates the corresponding DRM connector. But other methods shouldn't be too hard to implement -- once when we have a certain way to obtain the DRM connector / PCM relationship :)
thanks,
Takashi
On Tue, 2019-06-04 at 17:24 +0200, Daniel Vetter wrote:
On Tue, Jun 4, 2019 at 5:15 PM Christian König ckoenig.leichtzumerken@gmail.com wrote:
Am 04.06.19 um 17:05 schrieb Ser, Simon:
Hi,
I'm trying to link ALSA playback devices and DRM connectors. In other words, I'd like to be able to know which ALSA device I should open to play audio on a given connector.
Unfortunately, I haven't found a way to extract this information. I know /proc/asound/cardN/eld* expose the EDID-like data. However by looking at the ALSA API (also: aplay -l and -L) I can't find a way to figure out which PCM device maps to the ELD.
Am I missing something?
Is that actually fixed on all hardware? Or do we maybe have some hardware with only one audio codec and multiple connectors?
If not, what would be the best way to expose this?
- A symlink to the ALSA audio PCM device in /sys/class/drm/cardN-CONNECTOR?
- A symlink to the DRM connector in /sys/class/sound/pcm*?
If it's fixed than those two options sound sane to me.
- A DRM connector property?
If it's configurable than that sounds like a good option to me.
Anyway added our DC team, stuff like that is their construction site.
Regards, Christian.
- Somehow expose the connector name via the ALSA API?
- Expose the connector EDID via ALSA?
- Other ideas?
I think on our MST hw you get a combination of CRTCs x CONNECTORs on the alsa side. I.e. for every pair of connector and crtc you get a separate alsa pin. This is because with mst, you could have up to num_crtcs streams on a single connector. Not sure how to model that.
I assume this means "up to num_crtcs streams an a physical connector". With MST a physical connector can back more than one DRM connector.
Bigger question: How do you want to make the cooperation happen? There's been some ideas floating about making the hdmi connection between drm and alsa somehow represented in the code, but nothing ever really happened. there's drm_audio_component.h, but that's just the interface, it doesn't really solve how to make the connection. Also only used by i915/hda.
To be completely honest I have no idea. That's why I sent this e- mail. :P
Indeed, it seems that the interface isn't enough (get_eld and pin2port are interesting though).
Thanks!
Simon Ser _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, 2019-06-04 at 17:15 +0200, Christian König wrote:
Am 04.06.19 um 17:05 schrieb Ser, Simon:
Hi,
I'm trying to link ALSA playback devices and DRM connectors. In other words, I'd like to be able to know which ALSA device I should open to play audio on a given connector.
Unfortunately, I haven't found a way to extract this information. I know /proc/asound/cardN/eld* expose the EDID-like data. However by looking at the ALSA API (also: aplay -l and -L) I can't find a way to figure out which PCM device maps to the ELD.
Am I missing something?
Is that actually fixed on all hardware? Or do we maybe have some hardware with only one audio codec and multiple connectors?
If not, what would be the best way to expose this?
- A symlink to the ALSA audio PCM device in /sys/class/drm/cardN-CONNECTOR?
- A symlink to the DRM connector in /sys/class/sound/pcm*?
If it's fixed than those two options sound sane to me.
- A DRM connector property?
If it's configurable than that sounds like a good option to me.
I'm still not sure whether this is fixed on all hardware or not.
Ville, on this old Intel hw, is the single connector that gets the audio configurable?
Additional thought: since I need this for the IGT test suite I don't really care how this info is exposed as long as it's exposed, but other userspace programs (DEs) are probably interested in this information too. This would allow users to actually have the name of the monitor in the audio output selection UI. Having something that doesn't depend on sysfs would be better for this.
Would there be a way to expose some info about the monitor in the ALSA API?
Anyway added our DC team, stuff like that is their construction site.
Regards, Christian.
- Somehow expose the connector name via the ALSA API?
- Expose the connector EDID via ALSA?
- Other ideas?
Thanks!
Simon Ser _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Am 06.06.19 um 11:13 schrieb Ser, Simon:
On Tue, 2019-06-04 at 17:15 +0200, Christian König wrote:
Am 04.06.19 um 17:05 schrieb Ser, Simon:
Hi,
I'm trying to link ALSA playback devices and DRM connectors. In other words, I'd like to be able to know which ALSA device I should open to play audio on a given connector.
Unfortunately, I haven't found a way to extract this information. I know /proc/asound/cardN/eld* expose the EDID-like data. However by looking at the ALSA API (also: aplay -l and -L) I can't find a way to figure out which PCM device maps to the ELD.
Am I missing something?
Is that actually fixed on all hardware? Or do we maybe have some hardware with only one audio codec and multiple connectors?
If not, what would be the best way to expose this?
- A symlink to the ALSA audio PCM device in /sys/class/drm/cardN-CONNECTOR?
- A symlink to the DRM connector in /sys/class/sound/pcm*?
If it's fixed than those two options sound sane to me.
- A DRM connector property?
If it's configurable than that sounds like a good option to me.
I'm still not sure whether this is fixed on all hardware or not.
Well from reading up on the thread I think the answer is that this is NOT fixed.
At least from AMD hardware I know that the original R600 had only one audio codec which could be routed to multiple HDMI connectors at the same time.
And I understand the reply about MST so that you can even have multiple streams over the same codec routed to different connectors.
Christian.
Ville, on this old Intel hw, is the single connector that gets the audio configurable?
Additional thought: since I need this for the IGT test suite I don't really care how this info is exposed as long as it's exposed, but other userspace programs (DEs) are probably interested in this information too. This would allow users to actually have the name of the monitor in the audio output selection UI. Having something that doesn't depend on sysfs would be better for this.
Would there be a way to expose some info about the monitor in the ALSA API?
Anyway added our DC team, stuff like that is their construction site.
Regards, Christian.
- Somehow expose the connector name via the ALSA API?
- Expose the connector EDID via ALSA?
- Other ideas?
Thanks!
Simon Ser _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Jun 06, 2019 at 09:13:51AM +0000, Ser, Simon wrote:
On Tue, 2019-06-04 at 17:15 +0200, Christian König wrote:
Am 04.06.19 um 17:05 schrieb Ser, Simon:
Hi,
I'm trying to link ALSA playback devices and DRM connectors. In other words, I'd like to be able to know which ALSA device I should open to play audio on a given connector.
Unfortunately, I haven't found a way to extract this information. I know /proc/asound/cardN/eld* expose the EDID-like data. However by looking at the ALSA API (also: aplay -l and -L) I can't find a way to figure out which PCM device maps to the ELD.
Am I missing something?
Is that actually fixed on all hardware? Or do we maybe have some hardware with only one audio codec and multiple connectors?
If not, what would be the best way to expose this?
- A symlink to the ALSA audio PCM device in /sys/class/drm/cardN-CONNECTOR?
- A symlink to the DRM connector in /sys/class/sound/pcm*?
If it's fixed than those two options sound sane to me.
- A DRM connector property?
If it's configurable than that sounds like a good option to me.
I'm still not sure whether this is fixed on all hardware or not.
Ville, on this old Intel hw, is the single connector that gets the audio configurable?
The force-audio property can be used for that. That is, you can force audio off for all the connector where you don't want audio and then it should get automagically routed to the remaining connector.
participants (6)
-
Christian König -
Daniel Vetter -
Koenig, Christian -
Ser, Simon -
Takashi Iwai -
Ville Syrjälä