In timer-based scheduling model, event waiting is just to measure time
elapse since no event is expected to occur. However, as a result to
applying commit e5e6a7838b, -ETIMEDOUT returns in the case and
the caller handles it as error. This results in disorder of the
scheduling model.
This commit fixes the regression so that the -ETIMEDOUT case is expected.
Reported-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/alsa-devel/687f9871-7484-1370-04d1-9c968e86f72b@linux.intel.com/
Fixes: e5e6a7838b ("axfer: return ETIMEDOUT when no event occurs after waiter expiration")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The pointer operand to the binary `+` operator must be to a complete
object type.
Signed-off-by: Michael Forney <mforney@mforney.org>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In 2010, ALSA PCM interface got an flag of hardware parameters to suppress
periodical interrupts, according to a request from PulseAudio developer.
In typical PCM operation for usual hardware, PCM drivers configure the
hardware to generate the periodical interrupts to notify that the same
amount of data frames as a period of PCM buffer is actually transferred
via serial sound interface. The flag can suppress this if the driver
support it.
There's some merits of this configuration:
- No interrupt context run for PCM substream. The PCM substream is
handled in any process context only. No need to care of race
conditions between interrupt/process contexts. This is good for
developers of drivers and applications.
- CPU time is not used for handlers on the interrupt context. The CPU
time can be dedicated for the other tasks. This is good in a point
of Time Sharing System.
- Hardware is not configured to generate interrupts. This is good in a
point of reduction of overall power consumption.
Disabling period interrupt is used for 'Timer-based scheduling' to
consume data frames on PCM buffer independently of interrupt context. As
noted, no interrupt context runs for PCM substream, thus any blocking
operation is not released. Furthermore, system calls for multiplexed I/O
is not also released without timeout.
In this scheduling model, applications need to care of available space on
PCM buffer by lapse of time, typically by yielding CPU and wait for
rescheduling. For the yielding, timeout is calculated for preferable
amount of PCM frames to process. This is an additional merit for
applications, like sound servers. when an I/O thread of the server wait
for the timeout, the other threads can process data frames for server
clients. Furthermore, with usage of rewinding/forwarding, applications
can achieve low latency between transmission position and handling
position even if they uses large size of PCM buffers.
But the timeout should be calculated with enough care of hardware
capabilities. To disable period interrupt, used hardware should satisfy
some requirements for data transmission:
1. Even if drivers don't handle interrupts to queue next data transmission,
hardware voluntarily perform the data transmission when needed
(typically by requesting DMA automatically).
2. hardware has a capability to report current position of data
transmission with enough accuracy against the data transmission.
developers refer this as 'granularity'. If hardware can always
reports updated position after the data transmission finishes, the
granularity equals to the size of period of PCM buffer.
3. a fine size of data transmission in one time. This size is decided
depending on configuration of hardware or DMA controller, but for
efficiency it may not be one byte. Thus some amount of data frame is
transferred by one data transmission. Developers refer this as
'burst-ness'.
The timeout should be calculated according to the item 2 and 3, however
in current ALSA PCM interface supplemental information is not delivered
from drivers to applications. Although at present userspace applications
should be written by a speculative way for this point, there's few
problems because there're a few hardware which satisfy the above items.
However, when more drivers supports this feature, the problem may largely
be exposed and bothers application developers.
This commit adds an option to use 'timer-based scheduling' for data
transmission. This commit adds '--sched-model' option, and the scheduling
mode is enabled when 'timer' is assigned to the option by equal sign.
Although there's some TODOs, you can see the scheduling mode in this
simple program, like:
$ axfer transfer --sched-model=timer -P -d 2 -D hw:0,3 /dev/urandom -f dat -vvv
$ axfer transfer --sched-model=timer -C -d 2 -D hw:1,0 /dev/null -r 48000 -vvv
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
