From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AF754C433C1 for ; Sun, 28 Mar 2021 07:41:27 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4E7316196D for ; Sun, 28 Mar 2021 07:41:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4E7316196D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id EC7EA166F; Sun, 28 Mar 2021 09:40:33 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz EC7EA166F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1616917284; bh=iKMurowpp8GnI32r0/6aeqC5wPktiV5mynJQitefHqw=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=QhxvbNTe7tcHok0zIMUFT1GU+vgboZAZkPSmrWIVJQoNSfMoG/n7NLrHMQR8IDyFj 0cvxefpw40W1Nqt1M+qsj7VtzUoTRpw3JP5bl/LUZtPwgkFs7BdBFStNO/RZ8ICGSg h7EN0BaEOYUjjWmJHrI62PB35/W8vpWJsj+AQcZ0= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 71C89F8023E; Sun, 28 Mar 2021 09:40:32 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id DBF9FF80240; Sun, 28 Mar 2021 09:40:29 +0200 (CEST) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 82D50F800B9 for ; Sun, 28 Mar 2021 09:40:19 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 82D50F800B9 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 2BEBBAF13; Sun, 28 Mar 2021 07:40:19 +0000 (UTC) Date: Sun, 28 Mar 2021 09:40:18 +0200 Message-ID: From: Takashi Iwai To: David Henningsson Subject: Re: [PATCH v2] sound: rawmidi: Add framing mode In-Reply-To: References: <20210324054253.34642-1-coding@diwic.se> <20210324124430.GA3711@workstation> <057ef387-9ee1-2678-29ce-d644f2a3a90a@diwic.se> <20210326044615.GA51246@workstation> <2ca71809-9872-bfee-c19d-76b6ce143212@diwic.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: alsa-devel@alsa-project.org X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 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" On Sun, 28 Mar 2021 08:39:46 +0200, David Henningsson wrote: > > Hi Takashi and Takashi, > > You both question the usability of the patch, so let's take a step back. > > Suppose you're writing the next JACK, or a DAW, or something like that. > When writing a DAW, you need to support the users who need ultra-low > latency for live playing of an instrument. These users (unfortunately) > need to reconfigure their Linux installation, have special kernels, > buy expensive sound cards etc, in order to get the best possible > latency. > You also should give the best possible experience for people who don't > have the time to do that. Just recording a simple MIDI file should not > require any extra kernel options, RT_PRIO privileges or anything like > that. (And then there are people in between, who try to get the best > possible latency given their limited time, money and skills.) > > Now you're asking yourself whether to use rawmidi or seq API. It seems > silly to have to support both. > The seq interface is suboptimal for the first use case, due to the > latency introduced by the workqueue. But rawmidi is entirely > impossible for the second use case, due to the lack of timestamping. > (From a quick look at Ardour's sources, it does support both rawmidi > and seq. The rawmidi code mostly timestamps the message and sends it > to another thread. [1] I e, essentially what I believe the kernel > should do, because that timestamp is better.) > > What you don't need is exact measurements of burst interval or even > timestamp accuracy. All you have use for is the best possible > timestamp, because that's what's going to be written into the MIDI > file. There might be other use cases for burst intervals etc, but I > don't see them helping here. > > On 2021-03-26 17:44, Takashi Iwai wrote: > > On Fri, 26 Mar 2021 17:29:04 +0100, > > David Henningsson wrote: > >>> But actually I'd like to see some measurement how much we can improve > >>> the timestamp accuracy by shifting the post office. This may show > >>> interesting numbers. > >> Sorry, I don't know the idiom "shifting the post office" and neither > >> does the urban dictionary, so I have no idea what this means. :-) > > It was just joking; you basically moved the place to stamp the > > incoming data from one place (at the delivery center of a sequencer > > event) to another earlier place (at the irq handler). > > > > The question is: how much time difference have you measured by this > > move? > > Ok, thanks for the explanation. I have not done any measurements > because it would be quite time consuming to do so, across different > hardware, kernel configurations, and so on. I don't have that time > right now, sorry. But the claim that workqueues can be delayed up to a > second (!) from just adding a few RT_PRIO tasks [2] is enough to scare > me from using the seq interface for accurate timestamping. > > > >>> Also, one thing to be more considered is the support for MIDI v2 in > >>> future. I haven't seen any development so far (and no device > >>> available around), so I cannot comment on this much more, but it'd be > >>> worth to take a quick look before defining the solid API/ABI. > >> I had a quick look at MIDI 2.0. It offers something called "Jitter > >> reduction timestamps". After some searching I found that its > >> resolution is 16 bit, and in units of 1/31250 seconds [1]. So the > >> suggested timestamp format of secs + nsecs would suit us well for that > >> case, I believe. When implemented, MIDI 2.0 jitter reduction > >> timestamps would be another clock ID on top of the existing frame > >> format (or a new frame format, if we prefer). > >> > >> A midi 2.0 UMP (Universal Midi Packet) seems to be 4, 8, 12 or 16 > >> bytes, excluding the timestamp. If we want to fit that format with the > >> existing patch, we could increase the frame to 32 bytes so we can fit > >> more data per packet. Do you think we should do that? Otherwise I > >> think Patch v3 is ready for merging. > > Let's evaluate a bit what would be the best fit. I see no big reason > > to rush the merge right now. > > Does this mean "evaluate for a week or two because of kernel cadence, > merge windows etc" or does this mean "evaluate for months or years > until someone does a full MIDI 2.0 kernel implementation"? Well, without the actual measurement, it's purely a theoretical problem, and it implies that we haven't seen any real improvement by that, too. So, the first priority is to measure and prove the need of the changes. Then the next thing is to determine the exact format for the new API in a solid form. It's still not fully agreed which frame size fits at best, for example. Also, we may have two individual frame types, e.g. a timestamp frame and a data frame, too, depending on the frame size and the implementation. And, it might be handy if the ioctl returns the frame size to user-space, too. And, of course, thinking on MIDI 2.0 wouldn't be bad. Though I don't think tying with MIDI 2.0 is needed right now; instead, we should assure only that the new timestamp would be accurate enough for new extensions like MIDI 2.0. Takashi > > // David > > [1] > https://github.com/Ardour/ardour/blob/master/libs/backends/alsa/alsa_rawmidi.cc > [2] http://bootloader.wikidot.com/linux:android:latency >