All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: "Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>
Cc: Takashi Iwai <tiwai@suse.de>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Cezary Rojewski <cezary.rojewski@intel.com>
Subject: Re: no_period_wakeup, axfer and --sched-model=timer
Date: Thu, 13 May 2021 22:59:55 +0900	[thread overview]
Message-ID: <20210513135955.GA124922@workstation> (raw)
In-Reply-To: <954a2bc9-f6aa-6c5f-c3f1-62400f22cb3f@linux.intel.com>

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

  reply	other threads:[~2021-05-13 14:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-13 11:34 no_period_wakeup, axfer and --sched-model=timer Amadeusz Sławiński
2021-05-13 13:25 ` Takashi Sakamoto
2021-05-13 13:37   ` Amadeusz Sławiński
2021-05-13 13:59     ` Takashi Sakamoto [this message]
2021-05-13 14:06       ` Amadeusz Sławiński
2021-05-13 14:10       ` Cezary Rojewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210513135955.GA124922@workstation \
    --to=o-takashi@sakamocchi.jp \
    --cc=alsa-devel@alsa-project.org \
    --cc=amadeuszx.slawinski@linux.intel.com \
    --cc=cezary.rojewski@intel.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.