* 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.