* Re: [REGRESSION 6.14 -> 7.0] ALSA snd-ctxfi: no PCM playback on Creative X-Fi Titanium HD (EMU20k2 / SB1270)
2026-09-28 12:30 ` Takashi Iwai
@ 2026-09-29 1:22 ` Dany Patoine
2026-09-30 3:33 ` Dany Patoine
1 sibling, 0 replies; 4+ messages in thread
From: Dany Patoine @ 2026-09-29 1:22 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel, regressions
On Mon, 28 Sep 2026, Takashi Iwai wrote:
> Could you verify the latest 7.3-rc5 kernel to see whether the
> regression is still present at first? If the bug is still there,
> please go bisection.
The regression is still present on v7.3-rc5.
I built v7.3-rc5 from the mainline git tree (tag v7.3-rc5, commit
72d3fcf802c4), without distro patches, using a config derived from
the working Ubuntu 6.14 config (localmodconfig). use_system_timer=1.
Results on v7.3-rc5:
- speaker-test -D plughw:CARD=XFi,DEV=0 -c 2 -t sine -f 440
exits with 0, but no sound is produced.
- MP3 playback through PipeWire: no sound either.
- A short pop/click is heard at desktop session start, where the
login sound would normally play, but there is no continuous
PCM output.
- dmesg only shows "chip 20K2 model SB1270 (1102:0062) is found"
and "Use system timer", with no errors.
I am starting the bisection now. Since builds are slow on this
machine, I plan to:
1. confirm that vanilla v6.14, built the same way, works;
2. bisect over the commits touching sound/pci/ctxfi between v6.14
and v7.3-rc5 (33 commits);
3. confirm the result on the full tree (the suspect commit vs its
parent, and a revert on top of v7.3-rc5).
Please let me know if you would prefer a full-tree bisection instead.
I can send the full dmesg and alsa-info output from the v7.3-rc5
boot if useful.
Thanks,
Dany
Le 2026-09-28 à 08:30, Takashi Iwai a écrit :
> On Mon, 28 Sep 2026 01:51:04 +0200,
> Dany Patoine wrote:
>> Hello,
>>
>> I am reporting a playback regression in the snd-ctxfi driver affecting a
>> Creative Sound Blaster X-Fi Titanium HD. The card works perfectly on kernel
>> 6.14 but produces no audible PCM playback on kernel 7.0.
>>
>> HARDWARE
>> - Card: Creative Sound Blaster X-Fi Titanium HD (model SB1270)
>> - Chip: EMU20k2 / CA20K2
>> - PCI: 02:00.0 Audio device [0403]: Creative Labs EMU20k2
>> [Sound Blaster X-Fi Titanium Series] [1102:000b] (rev 03)
>> - Driver: snd_ctxfi (with module option use_system_timer=1)
>> - System: ASUS P8H67-M PRO, Intel Core i5-2400, x86_64
>>
>> SOFTWARE
>> - Distribution: Linux Mint 22.3 (Ubuntu 24.04 "noble" base)
>> - Sound server: PipeWire + WirePlumber
>> - WORKS: kernel 6.14.0-37-generic (Ubuntu HWE)
>> - BROKEN: kernel 7.0.0-31-generic and 7.0.0-34-generic (Ubuntu HWE 7.0)
>>
>> SYMPTOM
>> On 7.0, PCM playback produces no audible output, through BOTH paths:
>>
>> (a) Direct ALSA, bypassing PipeWire:
>> speaker-test -D plughw:CARD=XFi,DEV=0 -c 2 -t sine -f 440
>> completes with exit code 0, but no sound is produced.
>>
>> (b) The normal PipeWire path (default sink = the X-Fi):
>> also completely silent.
>>
>> Details of the failure mode:
>> - kernel 7.0.0-31: truncated / choppy fragments with use_system_timer=1,
>> and total silence with use_system_timer=0.
>> - kernel 7.0.0-34: total silence with use_system_timer=1.
>> - No xrun and no error is logged; playback appears to stall silently.
>>
>> On kernel 6.14.0-37, the exact same commands and configuration
>> (use_system_timer=1) produce clean, continuous audio.
>>
>> RULED OUT (all verified while booted on the failing 7.0 kernel)
>> - Card detection: OK. snd_ctxfi loads without error; `aplay -l` lists
>> card "XFi [Creative X-Fi]" with all PCM devices (Front/WaveIn,
>> Surround, Center/LFE, Side, IEC958 Non-audio).
>> - Mixer / routing: Master 98%, PCM 100% (no playback mute), Front [on]
>> 100%, "Analog Output" = Speakers. PipeWire's default sink is the X-Fi
>> at 94% and is not muted.
>> - use_system_timer: both values tested (0 and 1), neither gives
>> continuous sound on 7.0.
>>
>> RELATION TO A KNOWN FIX
>> This appears to be DISTINCT from the EMU20k2 regression fixed by commit
>> e9418da50d9e ("ALSA: ctxfi: Limit PTP to a single page"): that issue only
>> affected PulseAudio while direct ALSA (speaker-test) kept working. Here,
>> direct ALSA is ALSO silent, so it looks like a different problem.
>>
>> WHAT I CAN PROVIDE
>> These kernels are Ubuntu-packaged, not vanilla mainline. On request I can:
>> - provide full dmesg from a 7.0 boot and `alsa-info.sh` output,
>> - test a vanilla mainline 7.0.x / 7.1.x kernel,
>> - test any candidate patch,
>> - perform a git bisect between 6.14 and 7.0 if that would help.
> Could you verify the latest 7.3-rc5 kernel to see whether the
> regression is still present at first? If the bug is still there,
> please go bisection.
>
>
> thanks,
>
> Takashi
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [REGRESSION 6.14 -> 7.0] ALSA snd-ctxfi: no PCM playback on Creative X-Fi Titanium HD (EMU20k2 / SB1270)
2026-09-28 12:30 ` Takashi Iwai
2026-09-29 1:22 ` Dany Patoine
@ 2026-09-30 3:33 ` Dany Patoine
1 sibling, 0 replies; 4+ messages in thread
From: Dany Patoine @ 2026-09-30 3:33 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel, regressions, me, linux-sound
On Mon, 28 Sep 2026, Takashi Iwai wrote:
> Could you verify the latest 7.3-rc5 kernel to see whether the
> regression is still present at first? If the bug is still there,
> please go bisection.
The bisection is done. The first bad commit is:
4b490e0d103c ("ALSA: ctxfi: Add ADC helper functions for GPIO")
and a one-line fix on top of v7.3-rc5 restores the sound on my
Titanium HD (SB1270). Details below.
Bisection
---------
As announced, I bisected over the commits touching sound/pci/ctxfi.
All kernels were built from the mainline tree with the same config
method, and use_system_timer=1:
git bisect start 'v7.3-rc5' 'v6.14' '--' 'sound/pci/ctxfi'
git bisect skip 86f17f37a1fb4121229a76e6b9888072aadc334a
git bisect bad 75dc1980cf48826287e43dc7a49e310c6691f97e
git bisect bad 9bb003a1f98b11b80238d522778115ad07355149
git bisect good 5ebd054272718334c543998a6d0b77a9846c16d9
git bisect bad 4b490e0d103cbd353bb136d67a6cdb0e94558a85
# first bad commit: [4b490e0d103c] ALSA: ctxfi: Add ADC helper
# functions for GPIO
Vanilla v6.14 built the same way works, so the good end of the range
is not an Ubuntu-specific effect.
The skip: on 86f17f37a1fb the card does not probe at all (UBSAN
array-index-out-of-bounds in cthw20k2.c:955, daio_mgr_enb_dai(),
index 4294967274, then a crash in set_field()), so the playback
problem could not be evaluated there. I assume this was fixed later
by 277c6960d4dd or b045ab3dff97, but I have not verified it.
5ebd05427271 is the direct parent of 4b490e0d103c in the full tree,
so the good/bad pair differs only by that commit. (Their configs
differed by two netfilter options, CONFIG_NETFILTER_XTABLES and
CONFIG_NETFILTER_XTABLES_COMPAT, because of localmodconfig; I don't
think it matters.)
Root cause
----------
In hw_adc_init(), the GPIO_DATA read that preceded the Titanium HD
setup was moved into hw_adc_stop(), but the SB1270 block still uses
the local variable:
/* Set ADC reset bit as output */
data = hw_read_20kx(hw, GPIO_CTRL);
...
hw_adc_stop(hw);
if (hw->model == CTSB1270) {
/* Set up the PCM4220 ADC on Titanium HD */
data &= ~0x0C;
...
hw_write_20kx(hw, GPIO_DATA, data);
}
So "data" still holds the GPIO_CTRL value (0x9E5F on SB1270, set in
hw_card_init()), and that value is written to GPIO_DATA. This sets
bits 11-12, which hw_output_switch_put() uses to mute the line and
headphone outputs, and also overwrites the DAC speed mode bits 9-10
set by hw_dac_init(). hw_output_switch_put() is the only place that
clears the mute bits, and it returns early when the position does not
change, so the outputs stay muted: playback runs without any error,
but is silent.
Consistent with this, on the bad kernels (9bb003a1f98b and
4b490e0d103c), switching "Analog Output" from Speakers to Headphones
and back to Speakers makes the sound come back, clean.
Fix
---
Re-read GPIO_DATA in the SB1270 block, as the code did before:
diff --git a/sound/pci/ctxfi/cthw20k2.c b/sound/pci/ctxfi/cthw20k2.c
index 36066ffe8784..9716e16ebbab 100644
--- a/sound/pci/ctxfi/cthw20k2.c
+++ b/sound/pci/ctxfi/cthw20k2.c
@@ -1895,6 +1895,7 @@ static int hw_adc_init(struct hw *hw, const struct adc_conf *info)
if (hw->model == CTSB1270) {
/* Set up the PCM4220 ADC on Titanium HD */
+ data = hw_read_20kx(hw, GPIO_DATA);
data &= ~0x0C;
if (1 == info->msr)
data |= 0x00; /* Single Speed Mode 32-50kHz */
Tested on top of v7.3-rc5, with exactly the same config as the silent
v7.3-rc5 build: the sound works right after boot (desktop login sound
and speaker-test), without touching the "Analog Output" control. The
file builds without warnings with W=1.
Not tested:
- capture (line-in / mic): the fix is in the ADC init path, but I
only tested playback;
- sample rates other than 48 kHz;
- since 4b490e0d103c, hw_adc_stop() waits 10 ms before the SB1270
mode bits are written instead of after, so with the fix they are
written right before hw_adc_start(). I don't know whether the
PCM4220 cares about that timing; I leave that to you.
Correction to my previous mail: the short pop at desktop session start
also seems to happen with working kernels, so it is probably
unrelated.
About the tools used
--------------------
I am a user, not a kernel developer. I did this bisection with the
help of an AI assistant (Claude Opus 5.5, in Claude Code), which
automated the kernel builds and installs over SSH; I did the
listening tests on the hardware. The root cause was found by the
assistant reading the code of the suspect commits: it predicted the
remaining bisection results before they were tested, and suggested
the "Analog Output" check. The assistant also wrote the one-line fix
and helped me draft this mail. If you use the fix as is, please add:
Assisted-by: Claude:claude-opus-5-5
Feel free to add:
Reported-by: Dany Patoine <dany_patoine@hotmail.com>
Tested-by: Dany Patoine <dany_patoine@hotmail.com>
I'm happy to test any patch, or to resend this as a formal patch if
you prefer. I can also send the full dmesg and alsa-info output of
the good and bad kernels.
Thanks,
Dany
^ permalink raw reply related [flat|nested] 4+ messages in thread