no_period_wakeup, axfer and --sched-model=timer

Takashi Sakamoto o-takashi at sakamocchi.jp
Thu May 13 15:59:55 CEST 2021


On Thu, May 13, 2021 at 03:37:02PM +0200, Amadeusz Sławiński wrote:
> On 5/13/2021 3:25 PM, Takashi Sakamoto wrote:
> > Hi,
> > 
> > On Thu, May 13, 2021 at 01:34:25PM +0200, Amadeusz Sławiński wrote:
> > > I was checking some stuff relater to NO_PERIOD_WAKEUP and noticed that axfer
> > > has support for using either --sched-model=irq or --sched-model=timer.
> > > However from few quick tests it seems like it doesn't work?
> > > 
> > > $ aplay -l
> > > **** List of PLAYBACK Hardware Devices ****
> > > card 0: PCH [HDA Intel PCH], device 0: ALC283 Analog [ALC283 Analog]
> > >    Subdevices: 1/1
> > >    Subdevice #0: subdevice #0
> > > 
> > > 
> > > When using  --sched-model=irq  it transfers data until I press Ctrl+C
> > > 
> > > $ axfer transfer playback --sched-model=irq -D hw:0,0 -r 48000 -c2 -f S16_LE
> > > /dev/urandom
> > > PLAYBACK: Format 'Signed 16 bit Little Endian', Rate 48000 Hz, Channels
> > > 'Stereo'
> > > ^CPLAYBACK: Expected 4611686018427387903frames, Actual 163960frames
> > > Aborted by signal: Interrupt
> > > 
> > > 
> > > However with  --sched-model=timer  it time outs by itself:
> > > 
> > > $ axfer transfer playback --sched-model=timer -D hw:0,0 -r 48000 -c2 -f
> > > S16_LE /dev/urandom
> > > PLAYBACK: Format 'Signed 16 bit Little Endian', Rate 48000 Hz, Channels
> > > 'Stereo'
> > > Fail to process frames: Connection timed out
> > > PLAYBACK: Expected 4611686018427387903frames, Actual 16304frames
> > > 
> > > 
> > > How well is NO_PERIOD_WAKEUP tested/supported? Is it a bug in axfer or
> > > perhaps some issue in kernel code?
> > > 
> > >  From some debugging I did, I have my suspicions that it gets stuck on poll
> > > in:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/core/pcm_native.c?id=c06a2ba62fc401b7aaefd23f5d0bc06d2457ccc1#n3489
> > > waiting for runtime->sleep to wake it, but seems like it never happens.
> > > 
> > > What do you think?
> > 
> > It's a regression added by a commit e5e6a7838b06 ("axfer: return ETIMEDOUT
> > when no event occurs after waiter expiration"), and the -ETIMEDOUT come
> > neither from ALSA PCM core nor alsa-lib. Thanks for your reporting!
> > 
> >   * https://github.com/alsa-project/alsa-utils/commit/e5e6a7838b06
> > 
> > As a quick fix, please revert the commit. I'll post better fixes later.
> > 
> > After the revert, it looks work well under my hardware:
> > 
> 
> Yes, I can confirm, that it fixes the problem. Thanks for quick workaround!

That's good. I just filed the better fix. Please apply it with your local
repository instead of the revert patch.

 * alsa-utils: axfer: fix regression of timeout in timer-based scheduling model #88 
  * https://github.com/alsa-project/alsa-utils/pull/88

Anyway, thank you for reporting the bug. In recent years I've been
working for devices in which no-period-wakeup is unavailable, so I
overlooked the bug so long...


Thanks

Takashi Sakamoto


More information about the Alsa-devel mailing list