bullseye vc4-hcmi.conf is missing DMIX

[vanfanel]

Describe the bug

Hi,

Since I need to play two simultaneous sounds using only ALSA and the vc4hdmi device, I found out that current vc4-hdmi.conf doesn't have a dmix section.

I have seen that older vc4-hdmi.conf versions had this dmix section:

# default with dmix
vc4-hdmi.pcm.default {
	@args [ CARD ]
	@args.CARD {
		type string
	}
	type asym
	playback.pcm {
		type plug
		slave.pcm {
			@func concat
			strings [ "dmix:" $CARD ]
		}
	}
}

Shouldn't that be present on current vc4-hdmi.conf?

Thanks!

Steps to reproduce the behaviour

Try to reproduce two simultaneous audio streams using ALSA (not PA).
For example, run "speaker-test" on a TTY, and try it again on another TTY: second speaker-test instance will fail. DMIX should allow to run both instances.

Device (s)

Raspberry Pi 3 Mod. A+, Raspberry Pi 3 Mod. B, Raspberry Pi 3 Mod. B+, Raspberry Pi 4 Mod. B, Raspberry Pi 400

System

Raspberry Pi reference 2021-10-30
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, c12b1df4ed6416fb0df33ba1731c5b13c1bdbdf8, stage2

Linux minimal 5.10.103-v8+ #1530 SMP PREEMPT Tue Mar 8 13:06:35 GMT 2022 aarch64 GNU/Linux

Logs

No response

Additional context

No response

[6by9]

Originally asked at https://forums.raspberrypi.com/viewtopic.php?p=1985824 (now locked)

[bluestang2006]

Does this thread still apply?

towards the end:

> > (Note that plug over plug doesn't work -- that's the likely reason it
> >  failed before.)
> > 
> > 
> > Then, about the default PCM: I wonder whether the dmix is feasible at
> > all with this kind of setup.  What format does work with this device?
> 
> Only IEC958_SUBFRAME_LE

OK, then even you can drop the explicit format specification in the
above.

And I'm afraid that dmix won't work with IEC958 subframe type.  dmix
can deal with the direct hw access, and it's limited with the normal
linear PCM types.  In theory, we can apply the dmix-style plugin onto
iec958 subframes, but the current code doesn't do it.

That said, the default should be rather passing iec958 or hdmi without
the mixing.  If the stream mixing is required, you need to use some
sound server instead.


Takashi

[6by9]

Thanks @bluestang2006 - I never can find that thread when I want it.

Takashi is one of the Linux audio experts, so that is one solution, and almost certainly the easiest.
vanfanel seems not to like sound servers though based on previous threads.

Looking at the code for dmix, it would be plausible to mix IEC958 streams.
https://github.com/alsa-project/alsa-lib/blob/master/src/pcm/pcm_dmix.c and https://github.com/alsa-project/alsa-lib/blob/master/src/pcm/pcm_dmix_generic.c
IEC958 is 32bits per sample, but only mix bits 8-27, and then recompute the parity bit in bit 31. Not something I'm going to be looking at though.

@HiassofT knows a fair amount of ALSA configuration, so may be able to advise if you can control the order of dmix vs iec958 encapsulation.

[HiassofT]

it's very very tricky and I don't know of a somewhat realistic way to achieve that.

You'd need to put iec958 formatting into pcm_dmix or into pcm_direct as you also need to set the samplerate in channel status bits. dmix runs the hw pcm at a fixed rate so it won't help if you have IEC958 subframes with formatted channel status bits fed into dmix, that would need to be trashed anyways when doing sample rate conversion (which is usually happening).

pcm_dmix is heavily tied to pcm_direct and that again is heavily tied to the hw so I don't think there's an easy way to put pcm_iec958 somewhere between it.

Likewise duplicating pcm_iec958 functionality into pcm_direct or pcm_dmix isn't too great an idea either and might be quite involved, too.

So, the original statement from Takashi is stil valid - use a sound server if you want mixing.

[vanfanel]

@HiassofT Understood, sir.
I will investigate alternatives...

Thanks for your time and explanation, really :)