Re: Void PPC: PulseAudio issue with sound updates 7.4-rc1

[Takashi Iwai <tiwai@suse.de>]

On Sun, 01 Nov 2026 15:53:07 +0100,
Christian Zigotzky wrote:
> 
> On 01/11/26 10:15, Christian Zigotzky wrote:
> > Hi,
> > 
> > Although PulseAudio recognises the sound cards, it is unable to
> > successfully initialise the corresponding output profiles on Void
> > PPC since the sound updates 7.4-rc1 [1]. The output via ALSA works.
> > 
> > Tested with the onboard HDA ATI SB sound device, Soundblaster LIVE
> > Player 1024 PCI card, AMD HDMI audio and with USB audio. Strangely
> > enough Pulseaudio can enable the sound devices on MintPPC32. I think
> > the latest sound updates are responsible for the issue on Void PPC.
> > 
> > I bisected last week [2] and
> > ad28d2f607d1792c04531f2c5fd9ac0bf5bdcc9c (ALSA: pcm: Serialize and
> > check HW_REFINE ioctls) is the first bad commit.
> > 
> > I was able to revert the first bad commit and this solved the issue. [2]
> > 
> > Then I created a patch for reverting the bad commit. [3]
> > 
> > Could you please check the sound updates 7.4-rc1? [1]
> > 
> > Thanks,
> > Christian
> > 
> > [1]
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=75c1cb8178fe84403fd95236ddf21754f0a4156c
> > [2] https://github.com/chzigotzky/kernels/issues/21
> > [3]
> > https://github.com/chzigotzky/kernels/commit/644ec7c1f2f812d5eb89741e643f742596a49b2d
> > [4] Screenshots:
> >      - With the sound updates:
> > https://i.ibb.co/675Yjxvd/Kernel-7-4-0-with-sound-updates.png
> >      - With the patched kernel:
> > https://i.ibb.co/9HDrnnm1/Kernel-7-4-0-alpha8-Power-PC-1.png and
> > https://i.ibb.co/vx77FdHV/Kernel-7-4-0-alpha8-Power-PC-2.png
> > 
> 
> The sound-fixes-7.4-rc1 [1] don't solve the issue with PulseAudio on
> Void PPC. We still need the sound patch [2] for reverting the bad
> commit.

Hm, could you verify whether the below oneliner recovers from your
problem or not?

-- 8< --
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -965,7 +965,8 @@ static int snd_pcm_hw_refine_user(struct snd_pcm_substream *substream,
 	if (IS_ERR(params))
 		return PTR_ERR(params);
 
-	err = snd_pcm_hw_refine_with_lock(substream, params);
+	//err = snd_pcm_hw_refine_with_lock(substream, params);
+	err = snd_pcm_hw_refine(substream, params);
 	if (err < 0)
 		return err;
 
-- 8< --

If this works, clear this change again, and figure out which check in
snd_pcm_hw_refine_with_lock() gives the error.  The function has three
preliminary checks: PCM_RUNTIME_CHECK(), snd_pcm_buffer_access_lock()
(& unlock()), and hw_parms_state_check.  The first one must be
harmless, and the real problem must be either
snd_pcm_buffer_access_lock() or hw_params_state_check().

```
static int snd_pcm_hw_refine_with_lock(struct snd_pcm_substream *substream,
				       struct snd_pcm_hw_params *params)
{
	struct snd_pcm_runtime *runtime;
	int err;

	if (PCM_RUNTIME_CHECK(substream))
		return -ENXIO;
	runtime = substream->runtime;
	err = snd_pcm_buffer_access_lock(runtime);
	if (err < 0)
		return err;
	err = hw_params_state_check(substream);
	if (err)
		goto unlock;

	err = snd_pcm_hw_refine(substream, params);

 unlock:
	snd_pcm_buffer_access_unlock(runtime);
	return err;
}
```

OTOH, if the oneliner above doesn't change the behavior, something
else overlooked obviously.

Oh wait, it might be the 32bit compat path?  If so, the call at
snd_pcm_ioctl_hw_params_compat() needs to be tested, instead.


thanks,

Takashi