azx_get_pos_skl() induced system slowness

[Jens Axboe]

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.

-- 
Jens Axboe