audiosettings: support the ARM-side HDMI driver
Needed for configurations using the 'vc4-kms-v3d' overlay on Pi3/Pi4. The names are (almost) similar, but the default order of the cards is different:
- (fkms) the order is HDMI 1[+2], Headphones
- (kms) the order is Headphones, HDMI 0[1] (!)
We may have to add a function to set the HDMI0 port as default, let's wait for Bullseye to land and check then.
Needs an adjustment for Pi3 et. al now that 'vc4-kms-v3d' is default all Pi models.
Fixed the display and detection for models < 4 when they use the new vc4-kms-v3d overlay.
Added a slightly different .asoundrc variant when vc4hdmi driver is used for audio (enabled by the vc4-kms-v3d overlay), since the PCM configuration is different - which allows aplications to use the HDMI output without any conversion.
From my testing, the HDMI cards with the new driver will be configured only when audio is detected from HDMI connection, that's why my initial testing on the Pi4 failed (I only have video plugged in).
I'll do some more testing with the new vc4hdmi driver on the Pi4 and a HDMI (with audio) connection, just to make sure that the correct output is detected and enabled.
Did some testing on the PI4 and the audio output is fine - switching to Headphones or HDMI[1|2] is working correctly.
What doesn't work - and I don't think it's something that can be done here - is the mixer control. Strangely it works on a Pi3 (which has only one HDMI card), but not on the Pi4.
@cmitu does this need more changes?
I've been meaning to pick this up again. I'll see if the mixer can be enabled on the Pi4, which is the only thing missing (can't control the volume of the sound card).
@cmitu thanks. No pressure, I was just going through the tickets. Cheers.
Works well for me. For hdmi volume can be controlled on the hdmi device I guess. I'm happy to include this now and can always adjust it later if needed.
Es will complain on stdout/stderr if there's no mixer but maybe we can adjust that and just log it instead.
I'm happy to include this now and can always adjust it later if needed.
I guess it's better than nothing (which is what we have at the moment) :). I have a question opened in the forums, let me see if we can get some info out of it. If nothing conclusive comes up, we can merge it.
Sounds good. Thanks.
@joolswills since the default config doesn't implement the volume control properly, I've added it to the generated $HOME/.asoundrc. Tested on Pi3/Pi4 (on bullseye, using the VC4 HDMI ARM driver).
This should get rid of EmulationStation errors, the new volume control has the same name (HDMI), it may help the transition of existing configs.
Still needed to be considered:
-
dmixis not present, this will break multiple applications accessing the card - defaults for new systems/images. HDMI was the default card before the the VC4 driver was used for HDMI, now it's the analog output (Headphones). Additional configs need to be added on new images if we want to default to HDMI.
Should be ready for testing - I don't have a Pi 400, so that may interesting to test.
Thanks. I can test on a pi 400.
@cmitu Not tested on a RPI400 yet sorry. I was just testing it on a rpi4, and the HDMI volume control works well.
I think we should handle this system-wide via a /etc/alsa/conf.d/99-retropie.conf. I think it will be easier to manage, and will allow users to have an additional custom .asoundrc if they want.
I tested doing it like this, and it seemed to work fine.
(I have the changes ready, if you are happy for me to include them)
Using a sistem wide .conf sounds ok, you can include any changes to add the functionality.
I added a commit with a dialog to ask the user if they want to move their ALSA config. It's not ideal but there's no markers in the file around the RetroPie config, so not easy to test if it's our configuration or not.
Before if a user had a custom ~/.asoundrc it would be overwritten if switching output before, so this is still an improvement I think.
Before if a user had a custom ~/.asoundrc it would be overwritten if switching output before, so this is still an improvement I think.
Yes, seems right. I have just one more observation with the changes (added inline), but I'll give it another test before merging.
Thanks. I'll fix it up.and review. I'll squash the last two commits I think.
I squashed the commits keeping your main change and the other changes as a separate commit.
Looks fine to merge.
One minor punctuation correction maybe - the text in the move file has a . after ?, maybe a leftover from when the phrase was not a question.
You have a configuration in $home/.asoundrc - do you want to move it to the new location?. If $home/.asoundrc contains...
I'll correct that, then merge. Thank you.