From: Michael Harrell <michael.harrell455@gmail.com>
To: linux-sound@vger.kernel.org
Subject: Title: ALSA: hda/ca0132 - Sound BlasterX AE-5 Plus (1102:0191): center, rear-right and LFE randomly silent after codec init
Date: Wed, 30 Sep 2026 01:25:56 -0600 [thread overview]
Message-ID: <abcda578-9bef-4c96-952b-022daa276a98@gmail.com> (raw)
Title: ALSA: hda/ca0132 - Sound BlasterX AE-5 Plus (1102:0191): center,
rear-right and LFE randomly silent after codec init
Hardware: Creative Sound BlasterX AE-5 Plus, PCI 1102:0012, subsystem
1102:0191
(driver reports "CA0132: picked fixup for PCI SSID 1102:0191" and
identifies it
as "Sound BlasterX AE-5"). Analog 5.1 to a Logitech Z906 (3x 3.5mm).
AMD Ryzen (Granite Ridge) board, card is sole device behind bridge
00:02.2.
Kernel: 7.2.7-200.fc44.x86_64 (Fedora 44), alsa-firmware installed,
"ca0132 DSP downloaded and running" every time.
Works correctly under Windows 11 on the same machine and cables.
Problem:
After each codec initialisation (boot, driver unbind/bind, PCI bus reset,
or PCI remove+rescan), analog 5.1 output comes up in one of two states at
random:
- good: all six channels correct
- bad: only FL, FR and RL audible; FC, RR and LFE silent
Roughly 3 of 8 initialisations were good in testing. Nothing in software
distinguishes the two states:
- All ALSA controls identical (alsactl store diff): Output Select =
Speakers,
Surround Channel Config = 5.1, Center/LFE/Surround switches on,
HP/Speaker Auto Detect off, Bass Redirection off, Full-Range
Front/Rear on.
- /proc/asound/cardN/codec#1 dumps identical apart from master amp
volume.
- Pin configs identical.
- GPIO IO[1] data bit differs between some good and bad dumps, but
was also
observed as 1 in a bad state, so it is not a reliable indicator.
- Result is independent of whether a plug is present in the headphone
jack.
Toggling Output Select or Surround Channel Config after init (which re-runs
ca0132_alt_select_out / AE-5 ca0113 setup) sometimes turns a bad state into
a good one, but not reliably.
Separate but related: with runtime PM enabled (snd_hda_intel power_save=10,
set by tuned "balanced"), a good state is lost after the codec runtime-
suspends and resumes. Keeping the codec at power/control=on prevents that.
This suggests the AE-5 output setup (ca0113 MMIO / DAC) is not fully
re-applied on resume, and may be racy on initial setup.
Happy to test patches or provide codec dumps, alsactl state files and
kernel logs for good and bad states (collected on several boots).
Thanks,
Michael
reply other threads:[~2026-09-30 7:25 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=abcda578-9bef-4c96-952b-022daa276a98@gmail.com \
--to=michael.harrell455@gmail.com \
--cc=linux-sound@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox