Open victorallume opened 3 months ago
I've been able to re-create this using aplay
and an 8-channel .wav file (I made the wav file in audacity by creating 8 tracks, putting a unique 30-second tone into each channel, then exporting, ensuring each track was mapped to a unique channel). Stopping and re-starting the playback shows different channel pairs appearing on my oscilloscope
Further to the previous comment with the wav file - it shows the inconsistent mapping when I Ctrl-C the playback and re-start it. However, when I let the file play out, and start it again, the mapping seems to be the same every time (I've repeated this about 10 times and it's worked consistently every time). Similarly, in the original python program, if I call pcm.close()
prior to terminating the program, then next time it seems to be fine (again, I repeated this about 10 times).
So I'm thinking that the driver or the device is left in an inconsistent state when the stream is interrupted. Closing the PCM resets this state, but I'm surprised this doesn't happen when the PCM is initialised (either via aplay or the python library).
As an attempt for a workaround, I tried the following:
None of this worked, so it seems there's some other initialisation or de-initialisation happening when the process is started
pcm = alsaaudio.PCM(device='surround71:CARD=ICUSBAUDIO7D,DEV=0', format=alsaaudio.PCM_FORMAT_S16_LE, channels=8, rate=48000, type=alsaaudio.PCM_PLAYBACK, periodsize=960, periods=1)
for i in range(4):
pcm.write(frames)
pcm.close()
time.sleep(5)
del pcm
pcm = alsaaudio.PCM(device='surround71:CARD=ICUSBAUDIO7D,DEV=0', format=alsaaudio.PCM_FORMAT_S16_LE, channels=8, rate=48000, type=alsaaudio.PCM_PLAYBACK, periodsize=960, periods=1)
I've also tried alsactl init
, alsa force-reload
and usbreset 0d8c:0102
(and combinations of both of these) and they don't reliably get the card back from an inconsistent state. Rebooting seems to be the only thing that reliably works.
Actually, rebooting doesn't work reliably - the channel mapping is occassionally different after a reboot. If I close the pcm every time, it seems to reliably open with the same mapping the next run, but the initial run is not always consistent
I think I experience exactly this problem when using HDMI multichannel (5.1) output using a NVidia GPU and a surround set-up.
When I run speaker-test -c 6 -D hdmi:CARD=NVidia,DEV=1
on Ubuntu 24.10, the speaker mapping changes every time I run the command. I tried to remap the channels in pipewire/wireplumber using these instructions, but it fails because the mapping is constantly changing on the ALSA (or driver) layer.
I think the mapping isn't totally random, because after a few tries (about 3 or 4) I do get the correct mapping. But, it doesn't persist. So my guess is that there are a few standard surround configurations that are rotated somehow.
edit: If I can help by providing extra info feel free to ask.
I have a USB sound device (Startech ICUSBAUDIO7D, which comes up as
ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device
through lsusb) which I'm trying to program the output of for 8 channels. The python code (outputs a 50Hz sine wave) I'm using is below (each channel gets a different amplitude so I can identify them with an oscilloscope).The sound card has 4 stereo jacks, to which I have a scope connected.
The problem is that on different runs of the program, the output mappings are not consistent - each run of the program might have the order of the channels different to the previous. So running it one time might have amplitudes (0, 0.125) on the first jack, but the next run it might have those (0.75, 0.25) on the first jack (it doesn't appear to be 'paired' per jack)
I initially discovered this when using portaudio, and decided to try using alsa-only and the issue persists.
Is this likely to be a problem with the driver, alsa-lib, or is there something else going on here?
alsa-info output is attached alsa-info.txt