[PATCH 0/3] alsa-utils: axfer: fulfill scheduling model section for manual

[PATCH 0/3] alsa-utils: axfer: fulfill scheduling model section for manual

[Takashi Sakamoto]

Hi,

This patchset fulfills a section about scheduling model for axfer manual.
This is my attempt to describe well-known issue for 'no-period-wakeup'
mode of PCM runtime, discussed in some recent Audio miniconferences[1].

[1] http://www.alsa-project.org/main/index.php/Miniconf_2018#PCM_improvements

Takashi Sakamoto (3):
  axfer: add an explanation about IRQ-based scheduling model
  axfer: add an explanation about Timer-based scheduling model
  axfer: add an explanation about advantages/issues of Timer-based
    scheduling model

 axfer/axfer-transfer.1 | 112 ++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 111 insertions(+), 1 deletion(-)

-- 
2.19.1

[PATCH 1/3] axfer: add an explanation about IRQ-based scheduling model

[Takashi Sakamoto]

This commit adds a section titled as 'SCHEDULING MODEL' and fulfill a
subsection titled as 'IRQ-based scheduling model'.

This scheduling model is for a typical applications to operate a kind of
data sampled against actual time. In this model, ALSA PCM core maintains
timing of the applications with notification of hardware by
blocking/waking up their processes. This is a default behaviour of
runtime of PCM substream.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
---
 axfer/axfer-transfer.1 | 45 +++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/axfer/axfer-transfer.1 b/axfer/axfer-transfer.1
index 272e601..a84ab3a 100644
--- a/axfer/axfer-transfer.1
+++ b/axfer/axfer-transfer.1
@@ -665,7 +665,50 @@ named \(aqchannels\-1.au\(aq and \(aqchannels\-2.au\(aq.
 
 .SH SCHEDULING MODEL
 
-(placeholder)
+In a design of ALSA PCM core, runtime of PCM substream supports two modes;
+.I period\-wakeup
+and
+.I no\-period\-wakeup.
+These two modes are for different scheduling models.
+
+.SS IRQ\-based scheduling model
+
+As a default,
+.I period\-wakeup
+mode is used. In this mode, in\-kernel drivers should operate hardware to
+generate periodical notification for transmission of audio data frame. The
+interval of notification is equivalent to the same amount of audio data frame
+as one period of buffer, against actual time.
+
+In a handler assigned to the notification, a helper function of ALSA PCM core
+is called to update a position to head of hardware transmission, then compare
+it with a position to head of application operation to judge overrun/underrun
+(XRUN) and to wake up blocked processes.
+
+For this purpose, hardware IRQ of controller for serial audio bus such as
+Inter\-IC sound is typically used. In this case, the controller generates the
+IRQ according to transmission on the serial audio bus. In the handler assigned
+to the IRQ, direct media access (DMA) transmission is requested between
+dedicated host memory and device memory.
+
+If target hardware doesn't support this kind of mechanism, the periodical
+notification should be emulated by any timer; e.g. hrtimer, kernel timer.
+External PCM plugins generated by PCM plugin SDK in alsa\-lib should also
+emulate the above behaviour.
+
+In this mode, PCM applications are programmed according to typical way of I/O
+operations. They execute blocking system calls to read/write audio data frame
+in buffer of PCM substream, or blocking system calls to wait until any audio
+data frame is available. In
+.I axfer
+, this is called
+.I IRQ\-based
+scheduling model and a default behaviour. Users can explicitly configure this
+mode by usage of
+.I \-\-sched\-model
+option with
+.I irq
+value.
 
 .SH COMPATIBILITY TO APLAY
 
-- 
2.19.1

[PATCH 2/3] axfer: add an explanation about Timer-based scheduling model

[Takashi Sakamoto]

This commit fulfills a subsection titled as 'Timer-based scheduling model'.

This scheduling model is introduced in a recent decade. In this model,
applications should take care of its timing to operate sampled data
according to any timer. This is an optional behaviour of runtime of
PCM substream.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
---
 axfer/axfer-transfer.1 | 45 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/axfer/axfer-transfer.1 b/axfer/axfer-transfer.1
index a84ab3a..fbe0747 100644
--- a/axfer/axfer-transfer.1
+++ b/axfer/axfer-transfer.1
@@ -710,6 +710,51 @@ option with
 .I irq
 value.
 
+.SS Timer\-based scheduling model
+
+The
+.I no\-period\-wakeup
+mode is an optional mode of runtime of PCM substream. The mode assumes a
+specific feature of hardware and assist of in\-kernel driver and PCM
+applications. In this mode, in\-kernel drivers don't operate hardware to
+generate periodical notification for transmission of audio data frame.
+The hardware should automatically continue transmission of audio data frame
+without periodical operation of the drivers; e.g. according to auto\-triggered
+DMA transmission, a chain of registered descriptors.
+
+In this mode, nothing wakes up blocked processes, therefore PCM applications
+should be programmed without any blocking operation. For this reason, this mode
+is enabled when the PCM applications explicitly configure hardware parameter to
+runtime of PCM substream, to prevent disorder of existing applications.
+Additionally, nothing maintains timing for transmission of audio data frame,
+therefore the PCM applications should voluntarily handle any timer to queue
+audio data frame in buffer of the PCM substream for lapse of time. Furthermore,
+instead of driver, the PCM application should call a helper function of ALSA
+PCM core to update a position to head of hardware transmission and to check
+XRUN.
+
+In
+.I axfer
+, this is called
+.I timer\-based
+scheduling model and available as long as hardware/driver assists
+.I no\-period\-wakeup
+runtime. Users should explicitly set this mode by usage of
+.I \-\-sched\-model
+option with
+.I timer
+value.
+
+In the scheduling model, PCM 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 convenient to a kind of applications, like sound
+servers. when an I/O thread of the server wait for the timeout, the other
+threads can process audio 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.
+
 .SH COMPATIBILITY TO APLAY
 
 The
-- 
2.19.1

[PATCH 3/3] axfer: add an explanation about advantages/issues of Timer-based scheduling model

[Takashi Sakamoto]

Timer-based scheduling model has some merits against IRQ-based
scheduling model. However, as of Linux kernel v4.21, ALSA PCM interface
between kernel/userspace has a lack of some features.

This commit adds a subsection to describe it.

Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
---
 axfer/axfer-transfer.1 | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/axfer/axfer-transfer.1 b/axfer/axfer-transfer.1
index fbe0747..4ff6082 100644
--- a/axfer/axfer-transfer.1
+++ b/axfer/axfer-transfer.1
@@ -755,6 +755,28 @@ usage of rewinding/forwarding, applications can achieve low latency between
 transmission position and handling position even if they uses large size of
 PCM buffers.
 
+.SS Advantages and issues
+
+Ideally, timer\-based scheduling model has some advantages than IRQ\-based
+scheduling model. At first, no interrupt context runs for PCM substream. The
+PCM substream is handled in any process context only. No need to care of race
+conditions between IRQ and process contexts. This reduces some concerns for
+some developers of drivers and applications. Secondary, 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. Thirdly, hardware
+is not configured to generate interrupts. This is good in a point of reduction
+of overall power consumption possibly.
+
+In either scheduling model, the hardware should allow drivers to read the
+number of audio data frame transferred between the dedicated memory and the
+device memory for audio serial bus. However, in timer\-based scheduling model,
+fine granularity and accuracy of the value is important. Actually hardware
+performs transmission between dedicated memory and device memory for a small
+batch of audio data frames or bytes. In a view of PCM applications, the
+granularity in current transmission is required to decide correct timeout for
+each I/O operation. As of Linux kernel v4.21, ALSA PCM interface between
+kernel/userspace has no feature to report it.
+
 .SH COMPATIBILITY TO APLAY
 
 The
-- 
2.19.1

Re: [PATCH 0/3] alsa-utils: axfer: fulfill scheduling model section for manual

[Takashi Iwai]

On Sat, 05 Jan 2019 09:42:07 +0100,
Takashi Sakamoto wrote:
> 
> Hi,
> 
> This patchset fulfills a section about scheduling model for axfer manual.
> This is my attempt to describe well-known issue for 'no-period-wakeup'
> mode of PCM runtime, discussed in some recent Audio miniconferences[1].
> 
> [1] http://www.alsa-project.org/main/index.php/Miniconf_2018#PCM_improvements
> 
> Takashi Sakamoto (3):
>   axfer: add an explanation about IRQ-based scheduling model
>   axfer: add an explanation about Timer-based scheduling model
>   axfer: add an explanation about advantages/issues of Timer-based
>     scheduling model

Applied all three patches now.  Thanks.


Takashi