[pulseaudio-discuss] HDA HDMI audio PCM names

Kai Vehmanen kai.vehmanen at linux.intel.com
Fri Aug 30 07:58:29 UTC 2019


Hi,

On Wed, 28 Aug 2019, Tanu Kaskinen wrote:

> On Tue, 2019-08-27 at 17:39 +0300, Kai Vehmanen wrote:
> > Hi all,
> > 
> > we are considering removing the backup-PCM logic from snd_hda_intel 
> > HDMI/DP audio driver (note: this is used for wide variety of HDA 
> > controllers, not just Intel ones). See mail thread on alsa-devel:
> > 
> > https://mailman.alsa-project.org/pipermail/alsa-devel/2019-August/154561.html
> > 
> > In short, with DisplayPort-MST, additional monitors connected to a MST 
> > hub, and/or to monitor upstream DP ports, these would be routed to 
> > separate ALSA PCMs, e.g. PCM9 and PCM10, leaving the "standard" PCM 
> > numbers free for non-MST monitors.
> > 
> > This is getting highly problematic, especially when we support HDMI audio
> > with systems that have a DSP, and the PCM<->HDMI-audio-converter mapping
> > can be essentially arbitrary. The proposal is to just expose N pieces 
> > of PCMs (N number of converters in hw, e.g. 3 with i915), and any 
> > connected monitor (MST or not), is roured to one these PCMs.
> > 
> > Tanu added the ELD autodetect support in PA-12.x, and after that, HDA + PA 
> > works pretty nicely even without the backup PCMs, and a non-standard PCM 
> > device numbering for HDMI audio.
> > 
> > Now, I'm writing here as some kernel devs have referred to Pulseaudio 
> > as the source for the requirement to map MST monitors to the 
> > backup/virtual PCMs. Can anyone of you recall what was this about?
> 
> I don't recall, in fact I don't even remember hearing about the "backup
> PCM" concept before. As far as I can tell, PulseAudio imposes or has
> imposed the following limitations:

the backup PCM logic is best described in the original commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a76056f2e57ec2825d6ae4be016596dd37300750

It's quite an extreme use-case with multiple audio-enabled HDMI/DP 
monitors connected at the same time. E.g. if you have 3 such monitors 
connected via daisy-chaining (or a DP-MST hub), with the backup PCMs 
enabled in driver, the monitor ALSA PCMs will show up as PCM3, PCM9 and 
PCM10 (PCMs 5 and 7 are not connected). With backup PCM disabled (our 
proposal for new default), the audio devices of the three monitors show up 
as PCM1, PCM2 and PCM3.

Without eld autodetection, the above change is problematic as you needed 
to hardcoded the PCM device numbers to the PA path files. But that's more 
related to just how the PCMs are numbered.

Anyways, it seems there is no real issues with disabling the backup PCMs 
mode. We are still discussing whether to just change the behaviour 
unconditionally in the kernel, or whether to add a Kconfig option that 
allows distros more control for the migration.

>  * PCMs can't be added and removed dynamically on a card. PulseAudio
> doesn't have support for dynamic PCMs.
> 
>  * Previously HDMI jack detection required that specific PCM numbers
> are used, but as you noted, we have autodetection for this now.
> 
>  * The "hdmi:x,y" PCM devices must exist in the alsa configuration,
> bare "hw:x,z" won't be detected properly.

Thanks a lot for summarizing. I think we can meet these. The third one
of course requires care and if the PCM numbers are changed, we need
to ensure the config files get changed in sync.

Br, Kai


More information about the pulseaudio-discuss mailing list