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
