Re: pulseaudio / alc1220 sound clicks interruptions etc

On 2025-06-04 21:55 +0200, Olivier Certner wrote:
> Hi,
> 
> > > If this is a scheduling/video driver issue, I would say, definitely
> > > upgrade and test whether the problem is still present.
> > 
> > I'll update later today but this issue has been present for 3 years now.
> 
> If you're upgrading from 14.1, nothing special has changed in the scheduler.

Yep I upgraded no change.

> Previously, there were scheduler bugs causing annoying pops from time to time, 
> but these were fixed around July/August 2022, and the fix was in 13.2 and 
> onwards (if the problem occured with 13.0 or 13.1, you should normally have 
> seen an improvement with later versions, not a degradation).

Yes I'm aware of these it made no difference.


> I'm not aware of any scheduler bugs causing this kind of behavior, and would 
> say they are currently unlikely.

It seems related but it's also depending on how busy the system is graphics 
especially cause a lot of issues I'm assuming due to the amount of I/O.

> Testing an upgrade in case of such a problem is always a good idea in absence 
> of a clear culprit.

Everything was updated including all packages, drivers.  Tested with and without 
(no video) same problem.


> The common denominator of all your reports seems to be Intel Hybrid 
> Architecture (Alder Lake and onwards), which the scheduler does not especially 
> support now.  I'm currently working on this support (this is not going to be 
> ready soon).

Yes the scheduler has always been terrible and you're correct that I've only had 
this issue on machines with P/E cores.  Very happy to hear that you're working 
on this.  There are for sure other issues that are noticeable in Xorg little 
hiccups that never used to exist before I upgraded.

> Could you please try the following (preferably 1):
> 1. Disable E (Efficiency) cores from your BIOS if possible, reboot, test again and report.

I had to disable my E cores for a while due to UFS corruption: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261169 and it made no 
difference to the audio.

I chronicled my issues with logs here for audio: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263385

The debug logs were interesting because you could do certain things with the GUI 
and make it click like moving a terminal around quickly and that did not cause 
the CPU to spike at all.


> 2. Pin the application reading audio to a P (Performance) core with cpuset, 
> test again and report.  To know which cores are performance ones, run 
> 'cpucontrol -i 0x1a /dev/cpuctlXXX' on your cores and check that the first 
> hexadecimal value starts with 4 (a 2 indicates an efficiency core).

I've tried this before and it again makes no difference.


> If that doesn't show any difference, something else is at play and we'll then advise.

Thanks let me know if there's anything else you think would be good to checkout 
happy to run debugging, too.


Amar.