In CDSP I am mixing 2 stereo channels to 8 (2x4) channels out to hdmi:vc4hdmi0. I expected that the channel mapping would auto-magically follow the CEA-861 CA=0x13 mapping. I.e. [FL, FR, LFE, FC, RL, RR, RLC, RRC].
In practice the CDSP outputs do not appear to follow this mapping at all. Based on listening to the AVR outputs they are currently mapped [RL, RR, RLC, RRC, FL, FR, LFE, FC]. I also suspect that this mapping actually changes in some sessions, but I am not yet sure what conditions cause a change. This is of particular concern for speaker x-over applications.
In contrast, the speaker-test application consistantly conforms to CEA-861 CA=0x13 (assuming the numbers it displays really are it's output channel indices.).
I did notice that the alsa Loopback device has auto-magically acquired several associated surroundXX plugs, but the hdmi devices have not. - this might be significant, or not.
Config: rpi4b, bookworm, os-lite, pyCamillaDSP 2.0.2 Backend 2.0.1, Onkyo TX-SR875 AVR
In practice the CDSP outputs do not appear to follow this mapping at all. Based on listening to the AVR outputs they are currently mapped [RL, RR, RLC, RRC, FL, FR, LFE, FC]. I also suspect that this mapping actually changes in some sessions, but I am not yet sure what conditions cause a change. This is of particular concern for speaker x-over applications.
In contrast, the speaker-test application consistantly conforms to CEA-861 CA=0x13 (assuming the numbers it displays really are it's output channel indices.).
I did notice that the alsa Loopback device has auto-magically acquired several associated surroundXX plugs, but the hdmi devices have not. - this might be significant, or not.
Config: rpi4b, bookworm, os-lite, pyCamillaDSP 2.0.2 Backend 2.0.1, Onkyo TX-SR875 AVR
Update: The HDMI channel mapping definitely changes - on the fly!!!
I was listening to raspotify ... after an hour or more, my treble channels on RLC & RFC had swapped with LFE, & FC. I did not notice immediately as luckily LFE & FC are currently silent AND I am keeping the capacitors in-line with the tweeters for now/for ever! At first I just thought the material was extremely poorly mastered!
I was listening to raspotify ... after an hour or more, my treble channels on RLC & RFC had swapped with LFE, & FC. I did not notice immediately as luckily LFE & FC are currently silent AND I am keeping the capacitors in-line with the tweeters for now/for ever! At first I just thought the material was extremely poorly mastered!
That is very plausible - there was an underrun warning near the time of the latest channel switch:
P.S. I did not notice this issue with the rpi moOde/bullseye image - but I did not use it as much so that may just be luck - or the fact that I had the buffer set to 4096 rather than 2048?
I will monitor this more closely to try and confirm the correlation.
P.S. I did not notice this issue with the rpi moOde/bullseye image - but I did not use it as much so that may just be luck - or the fact that I had the buffer set to 4096 rather than 2048?
Last edited:
@HenrikEnquist
Please could you link the specific posts by @gordoste and @MRamone in the CamillaDSP thread that you referred me to? I tried a bit, but could not find anything about channel swapping.
Please could you link the specific posts by @gordoste and @MRamone in the CamillaDSP thread that you referred me to? I tried a bit, but could not find anything about channel swapping.
Update: With buffer = 4096 = no underruns and no channel swaps in about 1 hour of listening.
This is not conclusive - but the red wine is now open and it means I can sit and seriously enjoy my Linns tri-amped for the first time in 16 years of owning them! Unbelievable improvement - and they weren't bad before!
This is not conclusive - but the red wine is now open and it means I can sit and seriously enjoy my Linns tri-amped for the first time in 16 years of owning them! Unbelievable improvement - and they weren't bad before!
As this is potentially a-very-expensive-speaker-destroying-bug I am prepared to put in some effort to resolving it but could do with as many pointers as possible as to where to even start looking! (my name is on quite a few linux drivers but alsa & hdmi is still a black box to me at the moment!)
@HenrikEnquist - Sorry ... With a bit more effort I have found those posts you were referring to.
Sounds like you may have a quite useful background then 😀
Maybe you and @gordoste could join forces?
Hello all,
If I am not mistaken we have now a total of 4 reports of HDMI channel swapping:
I believe the (my) previous suspicion the issue was related to the Explore transceiver chips is mistaken, seems to be something more general, driver related? something different?
If I am not mistaken we have now a total of 4 reports of HDMI channel swapping:
- Gordoste and myself with audio extractors using Explore HDMI transceivers
- Nisse10000 using a Yamaha RX-V775 AVR with SIi9589 HDMI switch and Analog Devices adv7619ksvz HDMI receiver per service manual
- Oomzay using a Onkyo tx-sr875 AVR with a Silicon Image SII9135 HDMI transceiver per service manual
I believe the (my) previous suspicion the issue was related to the Explore transceiver chips is mistaken, seems to be something more general, driver related? something different?
Progress of sorts: I can reproduce the channel swap using the small bash script below to force x-runs while speaker-test is running. For some reason the swaps are more frequent on my bookworm (full-fat) (every 2 or 3 x-runs) than on my bullseye (lite) (every 9 or 10 x-runs).
I have posted this in the rPi forum some time ago but its waiting for moderation. If someone else could check that this script reproduces the problem then I'd hope this would be enough for rPi engineers to get their teeth into.
I have posted this in the rPi forum some time ago but its waiting for moderation. If someone else could check that this script reproduces the problem then I'd hope this would be enough for rPi engineers to get their teeth into.
#!/bin/env bash
# Script to provoke vc4 audio channel swapping bug
#
# Requires:
# speaker-test
# stress
# Arrange to kill speakertest process on CTL-C etc
trap "killall background" EXIT
# Run speaker-test at low priority in the background
nice -n 15 speaker-test -D hdmi:vc4hdmi1 -c 8&
# Hijack (stress) the CPU every 10 seconds to force x-run
# Too often and not enough time to be 100% sure of the swap.
# Too seldom and it takes too long for swap to happen.
while true
do
sleep 10
echo Force overrun...
stress -t 1 -c 8
done
More progress: This hdmi channel-swapping bug hunt is now gaining momentum over on the rPi forum. It seems it has been lurking for quite a while - and is possibly not just restricted to rPis!
I wonder how many others have scratched their heads in complete confusion and even given up on their projects due to this!
I wonder how many others have scratched their heads in complete confusion and even given up on their projects due to this!
@oomzay @gordoste @MRamone : Please look at https://forums.raspberrypi.com/viewtopic.php?p=2188328#p2188328 . Can you try the xruns in speaker-test with period set at multiples of 24 frames (i.e. blocks of 192 samples)? E.g. for period of 4080 frames (=170*24) the period time would be 85ms, i.e. sth like:
speaker-test -c 8 -r 48000 -D hdmi:vc4hdmi1 -F S32_LE -p 85000
Please check the actual period size in /proc/asound/vc4hdmi1/pcm0p/sub0/hw_params that it stayed at 4080 and was not changed by the iec958 plugin:
speaker-test -c 8 -r 48000 -D hdmi:vc4hdmi1 -F S32_LE -p 85000
Please check the actual period size in /proc/asound/vc4hdmi1/pcm0p/sub0/hw_params that it stayed at 4080 and was not changed by the iec958 plugin:
Code:
period_size: 4080
buffer_size: 16320Sure, I can test. Couple of clarifications:
- Do I need speakers connected to all channels? I can only connect 2 channels at a time, but this should be OK as I think speaker-test will announce the channel numbers sequentially.
- Should I first verify that doing the test with some different period size always causes the issue? And then, we are trying to see if -p 85000 avoids the issue?
- Should I use the script from that thread that runs stress in the background to cause xruns? Or do you want the test done without that?