[1.0.5] MaxxAudio/Waves firmware: audio dies permanently if a stream starts within the 3 s idle window
Device: Lenovo ThinkPad C14 / primus (Google-Primus-rev4), Alder Lake-U, DSP PCI\VEN_8086&DEV_51C8, rt5682s + max98360a
Driver: csaudiointcsof 1.0.5.0 on Windows 11, with SoFMaxxAudioInstall.exe applied
Summary
With the Waves firmware loaded, every stream teardown leaves the DSP pipeline unusable. The driver never detects or resets this, so the only thing that cleans it up is the 3 second idle timeout: the driver goes to D3, the DSP powers down, and the firmware is reloaded on the next D0. Any stream started before that cleanup runs gets a pipeline that reports success and then never plays — permanently, until the next DSP power cycle.
It is not a race. It is fully deterministic, and it disappears completely on the non-Waves firmware.
Repro (about five seconds)
Click the speaker icon in the notification area to open the volume flyout, then click the volume bar twice in quick succession — each click plays a feedback beep, and the second click needs to land before the driver’s idle timeout expires, so under a second apart is reliable. Audio is dead from that moment on: no more feedback beeps, YouTube in Edge produces no sound and the player hangs. Leave more than 10 seconds between the two clicks and nothing breaks.
Test matrix
| Firmware | Idle → D3 | Gap between streams | Result |
|---|---|---|---|
sof-adl-waves.ri |
3 s (default) | 2 s | dead |
sof-adl-waves.ri |
3 s (default) | 10 s | fine |
sof-adl-waves.ri |
disabled | any | dead on the first re-use after boot |
sof-tgl.ri (waves file renamed away) |
3 s (default) | any | fine |
sof-tgl.ri (waves file renamed away) |
disabled | any | fine |
Renaming C:\Windows\System32\DRIVERS\sof-adl-waves.ri makes the driver fall back to sof-tgl.ri and the problem disappears entirely. It takes effect immediately, no reboot needed. Renaming it back brings the problem back.
The width of that window is exactly the driver’s own idle timeout. csaudiointcsof.inf ships both values at 3 seconds:
HKR,PowerSettings,ConservationIdleTime,3,3,0,0,0 ; 3 seconds ... when on battery
HKR,PowerSettings,PerformanceIdleTime,3,3,0,0,0 ; 3 seconds ... when on AC power
HKR,PowerSettings,IdlePowerState,3,3,0,0,0 ; go to D3 for idle power management
PortCls uses PerformanceIdleTime on AC and ConservationIdleTime on battery, switching automatically as the platform transitions, so on a stock install the window is 3 seconds either way. My timings above were taken with both values at the shipped 3.
The D3 timeout is the smoking gun
net stop audiosrv && net start audiosrv normally recovers it, but that is misleading — stopping the service closes every pin, the driver goes idle, hits D3, the DSP powers down and the firmware is reloaded. The service restart was never the fix; the DSP power cycle was.
To confirm, I disabled idle power management (IdlePowerState = 0, both idle times raised) under HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e96c-e325-11ce-bfc1-08002be10318}\<nnnn>\PowerSettings. With that in place the boot chime plays fine and then the very first click on the volume bar is already dead, no double click needed — and restarting the audio service no longer recovers it. Only a full reboot does.
Things that rule out other explanations
It never breaks while something is already playing. With music playing, the same clicking is harmless. A live stream keeps the device pipe open, so the teardown path is never taken.
The pin opens fine — the data just never flows. Edge media-internals reports status=kPlaying with no error at all, so IAudioClient::Initialize and Start both succeeded. The WaveRT position simply never advances, which is why players hang. This is not a pin creation failure.
It does not self-heal. Once broken, a brand new pipe created later by another application is dead too, so the stuck state is not per-pipe. All applications are on the Default endpoint, so this is not endpoint or jack routing either.
Possible starting point
Upstream SOF implements the Waves processing as a CODEC_ADAPTER module inside the firmware, and its topologies (sof-adl-max98360a-rt5682-waves.tplg) carry separate “Waves Speakers Setup” and “Waves Speakers Runtime” pipelines that the plain topology does not have. Under Linux the topology is parsed and everything that was created gets freed generically, which is presumably why ChromeOS does not show this. If the Windows driver builds that topology from hardcoded IPC sequences, a missing free or reset for the codec adapter instance would produce exactly this behaviour: the next create reports success but the pipeline never runs, and only a firmware reload clears it.
A recovery path would also help a lot independently of the root cause — if a pipeline is created but the position never advances, resetting the DSP and rebuilding would turn a permanently dead endpoint into a brief glitch.
Shortening the idle timeout in the INF would shrink the window, but please don’t let that stand in for a fix — raising it makes things strictly worse, turning “restart the audio service” into “reboot the machine”.
Probably not primus-specific
This is very likely to affect every board on the MaxxAudio list in the driver’s README — the volteer, brya and nissa families — since sof-tgl-waves.ri and sof-adl-waves.ri go through the same firmware selection path in the driver. I have only tested primus.
There is an earlier report that looks like the same bug: Primus - Any video stops playing unless I mute them — same board, videos freezing in browsers and in VLC/MPV, resolved by uninstalling MaxxAudio.
Happy to run a DebugView capture or test a build.