From: "Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>, Jaroslav Kysela <perex@perex.cz>,
"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 16:06:53 +0200 [thread overview]
Message-ID: <3fb3270e-3deb-3ee3-a95b-b777b89e7d30@linux.intel.com> (raw)
In-Reply-To: <20210513135955.GA124922@workstation>
On 5/13/2021 3:59 PM, Takashi Sakamoto wrote:
> 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
>
And provided fix also works, thanks!
next prev parent reply other threads:[~2021-05-13 14:08 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
2021-05-13 14:06 ` Amadeusz Sławiński [this message]
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=3fb3270e-3deb-3ee3-a95b-b777b89e7d30@linux.intel.com \
--to=amadeuszx.slawinski@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=cezary.rojewski@intel.com \
--cc=perex@perex.cz \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox