From mboxrd@z Thu Jan  1 00:00:00 1970
From: Takashi Iwai <tiwai@suse.de>
Subject: Re: Master Plan on rewinding
Date: Mon, 15 Sep 2014 11:19:38 +0200
Message-ID: <s5hiokpw89h.wl-tiwai@suse.de>
References: <540C76E0.9050808@gmail.com> <54148E72.2050903@gmail.com>
 <CAN8cciYj4fo01XZwJ-NhFQDNv6Ua5mqaAEq1zU7PYxHkJyOQ5A@mail.gmail.com>
 <541584FB.2030208@gmail.com>
Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <alsa-devel-bounces@alsa-project.org>
Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15])
 by alsa0.perex.cz (Postfix) with ESMTP id 7E7A0265B3E
 for <alsa-devel@alsa-project.org>; Mon, 15 Sep 2014 11:19:41 +0200 (CEST)
In-Reply-To: <541584FB.2030208@gmail.com>
List-Unsubscribe: <http://mailman.alsa-project.org/mailman/options/alsa-devel>,
 <mailto:alsa-devel-request@alsa-project.org?subject=unsubscribe>
List-Archive: <http://mailman.alsa-project.org/pipermail/alsa-devel/>
List-Post: <mailto:alsa-devel@alsa-project.org>
List-Help: <mailto:alsa-devel-request@alsa-project.org?subject=help>
List-Subscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>,
 <mailto:alsa-devel-request@alsa-project.org?subject=subscribe>
Errors-To: alsa-devel-bounces@alsa-project.org
Sender: alsa-devel-bounces@alsa-project.org
To: "Alexander E. Patrakov" <patrakov@gmail.com>
Cc: Raymond Yau <superquad.vortex2@gmail.com>, ALSA Development Mailing List <alsa-devel@alsa-project.org>, Clemens Ladisch <clemens@ladisch.de>, David Henningsson <david.henningsson@canonical.com>, Takashi Sakamoto <o-takashi@sakamocchi.jp>
List-Id: alsa-devel@alsa-project.org

At Sun, 14 Sep 2014 18:07:23 +0600,
Alexander E. Patrakov wrote:
> 
> 14.09.2014 17:37, Raymond Yau wrote:
> >
> >  >
> >  >
> >  >> === On the rewind safeguard ===
> >  >
> >  >
> >  > Result 1: it has been decided that the return value of
> > snd_pcm_rewindable() is not changed, and the safeguard is returned by a
> > separate function.
> >
> > It is unlikely to return any value which is safe, it is the
> > responsiability of the application to decide how much can be rewind
> 
> You are placing a responsibility on an application without giving it any 
> means to make an informed decision. E.g. 4 ms is OK on snd-hda-intel, 
> but definitely not OK on ymfpci even on infinitely fast CPU (because of 
> the fixed 5 ms interrupt interval). The whole question here is: how is 
> an application supposed to know that?

Well, maybe the word "safeguard" is somewhat confusing to be used as
a driver API.  There is no "safety" at all there.  There is only
"theoretically minimal" (and it often lies even if the hardware chip
says so).  How much value to be taken as "safeguard" is rather a
choice by each application or sound backend.

Right now, the only information we give from the sound driver is
INFO_BATCH flag.  And I agree with a bit more detailed information to
be exposed from the driver -- but only if possible.  This must be an
optional information and not mandatory.


Takashi