From patchwork Sat Jan 5 08:42:09 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Takashi Sakamoto X-Patchwork-Id: 10749195 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id C0DD314E5 for ; Sat, 5 Jan 2019 08:42:41 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B11832846F for ; Sat, 5 Jan 2019 08:42:41 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A52A42877B; Sat, 5 Jan 2019 08:42:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F05F12846F for ; Sat, 5 Jan 2019 08:42:40 +0000 (UTC) Received: from alsa0.perex.cz (localhost [127.0.0.1]) by alsa0.perex.cz (Postfix) with ESMTP id EE8F9267CEC; Sat, 5 Jan 2019 09:42:28 +0100 (CET) X-Original-To: alsa-devel@alsa-project.org Delivered-To: alsa-devel@alsa-project.org Received: by alsa0.perex.cz (Postfix, from userid 1000) id D7977267C36; Sat, 5 Jan 2019 09:42:24 +0100 (CET) Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by alsa0.perex.cz (Postfix) with ESMTP id D20CF267C62 for ; Sat, 5 Jan 2019 09:42:22 +0100 (CET) Received: by mail-pl1-f194.google.com with SMTP id e11so18492317plt.11 for ; Sat, 05 Jan 2019 00:42:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=SSZbwtcMRdOUKJhkk+trmdlNrO+enbhzSd96kJbzkjE=; b=oCYFl76vM6doiBlJtPpCfIPT16JlN3p+OYqmpLQ1NKDJNS2S0FsyFZ7+1umc1CiXla pePS3os9iOdsrh8qnkCS0zmk6/i8P3BxkrP9l1eXu6/u2Ak3rwH1NfPiLolGkcVaDlgl XALBE6IMvcbhaDEV5lZ6Y5V8V20TDbQmRpwF4kCaBkRcsRvVnpORcT5wIbSy2W0/GqUS jA+guqkh7UrTqzeoT0pZZZYq/xuquQzlz6HjDDgt4CEOoq+1ThfBqs+ANR/W1ZZdkpKi jDUvz3TDLEvvOsWvUCg5tpehAiX248tvhmjfjpswqa2d/FJLUHYSdPfMepymoFrLRsrU GCaA== X-Gm-Message-State: AJcUukdTC1lkBufnoB7wWGFd2boRjxveV1iJQWVX5cWuu5JOVjnbzAbH /y36l4RRKpHXf0ey8pbNF818MkLa X-Google-Smtp-Source: ALg8bN7QmDv4dpMLoB6M9dxXhrdobK2GIzWYjdu2npRa3A6XuEcR3XyS1YnR7b5xkVL97YOQkdv5cg== X-Received: by 2002:a17:902:15a8:: with SMTP id m37mr54473768pla.129.1546677741537; Sat, 05 Jan 2019 00:42:21 -0800 (PST) Received: from localhost.localdomain ([2405:6580:9660:3200:b9c8:a675:a8c9:91f7]) by smtp.gmail.com with ESMTPSA id s21sm96345180pfk.133.2019.01.05.00.42.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Jan 2019 00:42:20 -0800 (PST) From: Takashi Sakamoto To: tiwai@suse.de, perex@perex.cz Date: Sat, 5 Jan 2019 17:42:09 +0900 Message-Id: <20190105084210.29616-3-o-takashi@sakamocchi.jp> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20190105084210.29616-1-o-takashi@sakamocchi.jp> References: <20190105084210.29616-1-o-takashi@sakamocchi.jp> MIME-Version: 1.0 Cc: alsa-devel@alsa-project.org Subject: [alsa-devel] [PATCH 2/3] axfer: add an explanation about Timer-based scheduling model X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org X-Virus-Scanned: ClamAV using ClamSMTP 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 --- 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