* no_period_wakeup, axfer and --sched-model=timer @ 2021-05-13 11:34 Amadeusz Sławiński 2021-05-13 13:25 ` Takashi Sakamoto 0 siblings, 1 reply; 6+ messages in thread From: Amadeusz Sławiński @ 2021-05-13 11:34 UTC (permalink / raw) To: Takashi Iwai, Jaroslav Kysela, Takashi Sakamoto Cc: alsa-devel@alsa-project.org, Cezary Rojewski Hi, 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? Amadeusz ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: no_period_wakeup, axfer and --sched-model=timer 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 0 siblings, 1 reply; 6+ messages in thread From: Takashi Sakamoto @ 2021-05-13 13:25 UTC (permalink / raw) To: Amadeusz Sławiński Cc: Takashi Iwai, alsa-devel@alsa-project.org, Cezary Rojewski 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: no_period_wakeup, axfer and --sched-model=timer 2021-05-13 13:25 ` Takashi Sakamoto @ 2021-05-13 13:37 ` Amadeusz Sławiński 2021-05-13 13:59 ` Takashi Sakamoto 0 siblings, 1 reply; 6+ messages in thread From: Amadeusz Sławiński @ 2021-05-13 13:37 UTC (permalink / raw) To: Takashi Iwai, Jaroslav Kysela, alsa-devel@alsa-project.org, Cezary Rojewski 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! ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: no_period_wakeup, axfer and --sched-model=timer 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 0 siblings, 2 replies; 6+ messages in thread From: Takashi Sakamoto @ 2021-05-13 13:59 UTC (permalink / raw) To: Amadeusz Sławiński Cc: Takashi Iwai, alsa-devel@alsa-project.org, Cezary Rojewski 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: no_period_wakeup, axfer and --sched-model=timer 2021-05-13 13:59 ` Takashi Sakamoto @ 2021-05-13 14:06 ` Amadeusz Sławiński 2021-05-13 14:10 ` Cezary Rojewski 1 sibling, 0 replies; 6+ messages in thread From: Amadeusz Sławiński @ 2021-05-13 14:06 UTC (permalink / raw) To: Takashi Iwai, Jaroslav Kysela, alsa-devel@alsa-project.org, Cezary Rojewski 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! ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: no_period_wakeup, axfer and --sched-model=timer 2021-05-13 13:59 ` Takashi Sakamoto 2021-05-13 14:06 ` Amadeusz Sławiński @ 2021-05-13 14:10 ` Cezary Rojewski 1 sibling, 0 replies; 6+ messages in thread From: Cezary Rojewski @ 2021-05-13 14:10 UTC (permalink / raw) To: Takashi Sakamoto, Amadeusz Sławiński; +Cc: Takashi Iwai, alsa-devel On 2021-05-13 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? ... >>> 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... No problem Takashi, happens to us all. We thank you for a very quick reply and solving the issue. Regards, Czarek ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-05-13 14:11 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2021-05-13 14:10 ` Cezary Rojewski
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.