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