On 8/25/21 12:14 AM, Takashi Iwai wrote:
On Tue, 24 Aug 2021 19:38:08 +0200, Jens Axboe wrote:
Hi,
Got a new notebook recently, it's a Lenovo X1 Carbon 9th gen. Sound works fine, but sometimes I get really stuttering playback from nestopia and I finally decided to look into it. When this happens, azx_get_pos_skl() is seemingly called a lot, at least it uses a ton of CPU cycles. This comes and goes, sometimes 1 minute in between, sometimes 2, and sometimes 30 seconds.
If I comment out the udelay() in that function it does seems to be noticeably better, though it's not a complete fix. I guess it just reduces the pain of calling it so many times?
This is running 5.14-rc7, but it's not a recent regression.
Any clues as to what this might be?
Are you using PulseAudio? Or pipewire? The former might cause lots of position update calls when the device doesn't give back the stable (or consistent) position report.
I'm using the default (mint) which is pulseaudio. But after reading your reply, I switched to pipewire - hopefully that'll work better!
The code there was borrowed from the ASoC Intel Skylake driver (sound/soc/intel/skylake/skl-pcm.c), and the same is also carried to the recent ASoC SOF HDA driver, too. As far as I understand from the comment, the udelay() itself could be reduced only for the case right after the interrupt wakeup. That is, a hackish patch like below might help.
But, as far as I see with PulseAudio, it still results in a lot of register read -- so PA seems repeatedly reading the position.
A better result (only from the CPU usage POV) could be gained on my machine by just switching to another position inquiry; namely, pass position_fix=1 option to snd-hda-intel module. But I checked this only for a short period, so am not sure about the long run.
Let me know if you want to test the patch or using that option, for now I just went with pipewire and will see if that works any better.