Sound Blaster Audigy Rx (SB1550) surround71 - side speakers have output, but not from side channels (6 & 7)

[ESSEMDEE]

In short, Side Left speaker seems to always output the same as Front Left, and the same for Side Right acting as a duplicate of Front Right.

I am not sure if there is a setting somewhere that I am not seeing, or if this is a driver issue, or what, but even with speaker-test or routing via ttable in asound.conf, channels 6 and 7 seem like dummy outputs to nowhere — though the side speaker connections do have output, albeit always the same as that of the front speakers.

mpv reports requesting 2 channels and getting 8, but still, using --af=channelmap="0-6|1-7|" results in silence, whereas otherwise, the side speakers mirror the output of the front.

Should it make a difference, I am running a live USB of Debian 11.4 Standard. The kernel is version 5.10.16, I believe.

[ESSEMDEE]

Here is the output from amixer scontents after a fresh boot: amixer scontents (fresh boot).txt

Here is the output after I made a couple of tweaks via alsamixer: amixer scontents (modified).txt

And in case more detailed is helpful, the output from amixer contents: amixer contents (modified).txt

I am not sure what other information might be useful, but here is the cards output from lspci -vvv: lspci.txt

Let me know if any other uploads and/or information is needed.

Pulseaudio is not installed, and I do not see any sort of configuration files for alsa in /etc or the user's home directory...

amixer is version 1.2.4.

[ESSEMDEE]

Here is what I get from aplay --dump-hw-params: aplay --dump-hw-params.txt

Trying mpv --audio-device=alsa/"hw:0,3" --audio-channels=16, I get the same general error about not being able to set the access type. (I presume that neither aplay nor mpv support noninterleaved access modes?)

I configured a PCM device using the plug plugin as follows: /etc/asound.conf.txt (Appended the .txt file extension for uploading here.)

However, although mpv manages to open the device without issue, even with a combination of --audio-channels=1, --af=channelmap="0-0|", and/or --alsa-ignore-chmap, output seems to be going to all speakers (some at full volume, some at half), even if set channels 1 through 15 in the ttable from 1 to 0! (The ttable seems to have no effect on output.)

I am baffled by what could be performing this up-mixing... Is there anything else that I should check or try before testing with a different distribution or version?

[perexg]

Use speaker-test utility to test all channels. If somethings does not work, it's most probably a driver issue.

[ESSEMDEE]

Use speaker-test utility to test all channels. If somethings does not work, it's most probably a driver issue.

As mentioned in my first post, I had been using speaker-test (albeit to test surround71, not direct hardware access, since attempts at that had failed with eight channels). But now that I know that the card needs sixteen channels for direct access, I will try speaker-test again this evening, and report back.

[ESSEMDEE]

_speaker-test -D"hw:0,3" -r48000 -c16 -f60 -FS16LE -tsine -l1 -S100 results in this: speaker-test-hw.txt Seems like speaker-test cannot handle noninterleaved access modes, either?

Changing the -D parameter to "plughw:0,3" or the PCM defined in the asound.conf posted earlier (both provide identical output), I receive the mess of results as outlined below.

LINE_OUT_1 FRONT_LEFT = 2.041V (0-FL and 8-CH9) FRONT_RIGHT = 2.021V (1-FR and 9-CH10)

LINE_OUT_2 REAR_LEFT = 2.034V (0-FL and 2-RL) REAR_RIGHT = 2.031V (1-FR and 3-RR) SIDE_RIGHT = 2.029V (1-FR and 9-CH10)

LINE_OUT_3 CENTER = 1.021V (0-FL and 1-FR) and 2.016V (6-SL) LFE = 1.028V (0-FL and 1-FR) and 2.031V (7-SR) SIDE_LEFT = 2.019V (0-FL and 8-CH9)

The names in parenthesis are abbreviations of those displayed by speaker-test. As you can see, there are eight channels with output, but for many of them, that output is seen across multiple speaker connections.

Bold text is the correct (or workable) output, provided the interference (mixing) of the other channels were not at play.

[perexg]

If my memory is right for this old piece of hw, you're trying to use the PCM device which connects to the EFX. Use "Multichannel PCM Send Routing" control to set the proper configuration (amixer contents and amixer set iface=PCM,name="Multichannel PCM Send Routing" ...array...).

Anyway this device was not intended for the standard use. You should use the standard plug:surround71 PCM where the routing should be correct.

[perexg]

And if the routing is not correct for plug:surround71 then you can try another by changing https://github.com/alsa-project/alsa-lib/blob/master/src/conf/cards/Audigy2.conf#L184 .

[ESSEMDEE]

And if the routing is not correct for plug:surround71 then you can try another by changing https://github.com/alsa-project/alsa-lib/blob/master/src/conf/cards/Audigy2.conf#L184 .

Thanks, I will give all of that a try.

As for the Audigy2.conf file, is there a reason that pcm.rear is missing the "EMU10K1 PCM Send Routing" present for the front, center_lfe, and side PCM interfaces? Could that be the issue?

[perexg]

I think that the default routing settings is for rear. So it's not required to change it.

[ESSEMDEE]

plug:surround71 provides the same results as surround71, save for the latter not accepting sixteen channels, only eight.

By modifying /usr/share/alsa/cards/Audigy2.conf and changing pcm.side's "EMU10K1 PCM Send Routing" values from 14 and 15 to 0 and 1 or 8 and 9, respectively, I can get the side channels to output during speaker-test, but the front channels seem to also be controlled by these same two pairs of values, with results like those seen with my speaker-test -D"plughw:0,3" attempt.

Actually, this apparent correspondence between 0<->8 and 1<->9 also can be seen in my results from the other day, in Line Out 2's Side Right and Line Out 3's Side Left readings.

What more can you tell me about these "EMU10K1 PCM Send Routing" value parameters? What range of values can be accepted, and why do the same eight values seem to be repeated three times for each PCM configuration?

And what about the "EMU10K1 PCM Send Volume" values?

[perexg]

It seems that the driver initialization code requires more work:

• https://github.com/torvalds/linux/blob/987a926c1d8a40e4256953b04771fbdb63bc7938/sound/pci/emu10k1/emu10k1_main.c#L1274-L1335
• see line 1320 https://github.com/torvalds/linux/blob/987a926c1d8a40e4256953b04771fbdb63bc7938/sound/pci/emu10k1/emu10k1_main.c#L1320 (identical configuration)

I am afraid, it's out of scope of the alsa-lib package to resolve this. You may enter a bug to kernel's bugzilla: https://bugzilla.kernel.org (Audio group), but we do not have active emu10k1/emu10k2 developers at this time. Also, most of information was gathered using the reverse engineering for this hw. Creative Labs does not co-operate with us.