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:25:20 +0900 [thread overview]
Message-ID: <20210513132520.GA109626@workstation> (raw)
In-Reply-To: <687f9871-7484-1370-04d1-9c968e86f72b@linux.intel.com>
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:
```
$ ./axfer list playback device
**** List of PLAYBACK Hardware Devices ****
card 0: Generic [HD-Audio Generic], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Generic [HD-Audio Generic], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Generic [HD-Audio Generic], device 8: HDMI 2 [HDMI 2]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Generic_1 [HD-Audio Generic], device 0: ALC1220 Analog [ALC1220 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Generic_1 [HD-Audio Generic], device 1: ALC1220 Digital [ALC1220 Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Generic_1 [HD-Audio Generic], device 4: ALC1220 Analog [ALC1220 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: FCA610 [FCA610], device 0: BeBoB [FCA610 PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
$ ./axfer transfer playback -vv --sched-model=timer -D hw:1,0 -r 48000 -c2 -f S16_LE /dev/urandom -d1
Container: parser
format: raw
sample format: S16_LE
bytes/sample: 2
samples/frame: 2
frames/second: 48000
frames: 4611686018427387903
attributes for mapped page frame:
sample number: 0
address: 0x7f92086f7000
bits for offset: 0
bits/frame: 32
sample number: 1
address: 0x7f92086f7000
bits for offset: 16
bits/frame: 32
Hardware PCM card 1 'HD-Audio Generic' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 24064
period_size : 6016
period_time : 125333
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 6016
period_event : 1
start_threshold : 1
stop_threshold : 24064
silence_threshold: 0
silence_size : 0
boundary : 6773413839565225984
appl_ptr : 0
hw_ptr : 0
Scheduling model:
timer
Waiter type:
default
Transfer: libasound
access: MMAP_INTERLEAVED
sample format: S16_LE
bytes/sample: 2
samples/frame: 2
frames/second: 48000
frames/buffer: 24064
Mapper: muxer
target: single
access: MMAP_INTERLEAVED
bytes/sample: 2
samples/frame: 2
frames/buffer: 24064
PLAYBACK: Format 'Signed 16 bit Little Endian', Rate 48000 Hz, Channels 'Stereo'
handled: 0
rewound: 24032/24064
handled: 20218
handled: 3814
handled: 18844
handled: 5124
PLAYBACK: Expected 48000frames, Actual 48000frames
Handled bytes: 192000
```
Thanks
Takashi Sakamoto
next prev parent reply other threads:[~2021-05-13 13:26 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 [this message]
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
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=20210513132520.GA109626@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.