220 26271 <4997224.LIi1sQ1Xyy@lastique-pc> article Path: news.gmane.org!not-for-mail From: Andrey Semashev Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Any interest to adding audio support to the std library? Date: Sat, 11 Jun 2016 11:03:21 +0300 Lines: 130 Approved: news@gmane.org Message-ID: <4997224.LIi1sQ1Xyy@lastique-pc> References: <5751B06A.4080501@mail1.stofanet.dk> <2271827.u9FbM9WbyY@lastique-pc> <485D94E9-3386-4C2E-8C90-2AE821C3B7E6@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart2681720.v7ipKe8ngQ" Content-Transfer-Encoding: 7Bit X-Trace: ger.gmane.org 1465632216 8303 80.91.229.3 (11 Jun 2016 08:03:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Jun 2016 08:03:36 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCXY5TXHWYJRBTEL565AKGQE6JBG3BQ@isocpp.org Sat Jun 11 10:03:26 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f198.google.com ([209.85.217.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bBdt7-0003Uq-G0 for gclcip-std-proposals@m.gmane.org; Sat, 11 Jun 2016 10:03:25 +0200 Original-Received: by mail-lb0-f198.google.com with SMTP id js8sf3213486lbc.2 for ; Sat, 11 Jun 2016 01:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=XkhqMCDreFD0ry2tElwsBQCZT59+IS9oRWK8PMNbCaU=; b=AZoDFWKfl63WA+H/Rzoh0wiDxslRtQa+VBlY4lyTbGLOhTLW2nJdq2UvFIFNPfYixv zGRA9CogtZ1Z7e+SkCDSC9mdu70Y7XAzl9bQU/qvRC0ztNROSY+ws95MwEsSLKK/LFS3 sJubvCoqWMJIArAZy13nY0b96n8Y3xENoR2NEJV2ZryqucfJJLLHDrdjfs6o5rc5cF1A JTgx+wPhe5OlDr6YGH1topQlEX+AtHij98Bxlly/3urnjnWUYJvkdcFhKz3Un1jf6Zzr wClGuvsXjG4wLIQCtvhdabFRcFEoTAr9JaRnRsMmqC79Nwq0ELqqkuH2S2AcKcZPVYI8 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=XkhqMCDreFD0ry2tElwsBQCZT59+IS9oRWK8PMNbCaU=; b=mYDR6zggYAwLL5/6joTgfwa/D+nlgiLhXiqYJ2bmkVZXfat4PvKkDHc04wzhJOht4S bhZhEIbmfGUDONGsz92z9RMjz3+mutfkhOzzd8N9vmBPJGHKuCHpvFGS+WVaYoboVGcc IF0sKWy7++z3MgYZXJD8HJiwFrcj+aJjag9zH9yIIPmLnxajeXUEVbYBcWfqcd3ortop 2dks0POusHECp2BzZnwf0OxfSzhBNKTvV/AxPDIKuNjX4RJNKXvVcOuhn9sHLt7yiHTZ HkNAHMEFpOfqOgv+Mr/ETm8E1/LgVpKOlsl1Z2bZiYndn4w8n7776FCtXPpe9ix3ZV/Z X-Gm-Message-State: ALyK8tKJcu5VKboydfIO9S4zvO6KY6ghXf+qQQI1MQw2vJklC0rT3AMopG8Bj5iZH4Quzg== X-Received: by 10.25.201.129 with SMTP id z123mr831317lff.10.1465632204953; Sat, 11 Jun 2016 01:03:24 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.33.209 with SMTP id h200ls145408lfh.33.gmail; Sat, 11 Jun 2016 01:03:23 -0700 (PDT) X-Received: by 10.25.29.138 with SMTP id d132mr1675610lfd.142.1465632203692; Sat, 11 Jun 2016 01:03:23 -0700 (PDT) Original-Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com. [2a00:1450:4010:c07::22a]) by mx.google.com with ESMTPS id 32si8747724lfx.97.2016.06.11.01.03.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Jun 2016 01:03:23 -0700 (PDT) Received-SPF: pass (google.com: domain of andrey.semashev@gmail.com designates 2a00:1450:4010:c07::22a as permitted sender) client-ip=2a00:1450:4010:c07::22a; Original-Received: by mail-lf0-x22a.google.com with SMTP id q132so20483454lfe.3 for ; Sat, 11 Jun 2016 01:03:23 -0700 (PDT) X-Received: by 10.46.0.219 with SMTP id e88mr1608656lji.55.1465632203334; Sat, 11 Jun 2016 01:03:23 -0700 (PDT) Original-Received: from lastique-pc.localnet (broadband-90-154-68-136.nationalcablenetworks.ru. [90.154.68.136]) by smtp.googlemail.com with ESMTPSA id dt5sm1605117lbc.47.2016.06.11.01.03.21 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 11 Jun 2016 01:03:22 -0700 (PDT) User-Agent: KMail/5.1.3 (Linux/4.4.0-24-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <485D94E9-3386-4C2E-8C90-2AE821C3B7E6@gmail.com> X-Original-Sender: andrey.semashev@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of andrey.semashev@gmail.com designates 2a00:1450:4010:c07::22a as permitted sender) smtp.mailfrom=andrey.semashev@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:26271 Archived-At: This is a multi-part message in MIME format. --nextPart2681720.v7ipKe8ngQ Content-Type: text/plain; charset=UTF-8 On Saturday, 11 June 2016 10:55:17 MSK alexander.zywicki@gmail.com wrote: > I lie your thought on the clock idea and +1 for the example. A few thoughts > though, I would like to explain the distinction that I draw between an > "arbitrary epoch" and a "dynamic epoch" as I had proposed. It would not be > arbitrary in that it would be set to some random point, but rather would be > set too a significant time point in terms of the current instance of the > program... It would be reset to the time when the stream was started. In > port audio it would be set to the time when Pa_StartStream was called, > having that as a reference point would allow you to manage the local time > within that stream easily. If I understood you right, that's exactly what I'm arguing against. > As a second note the sample rate will most likely need to be a runtime > parameter and cannot be a template parameter because of such( unless we > specify the need for a factory to create clocks of different sample rates) > we will probably not know the desired sample rate or even the supported > sampling rates at compile time A runtime-set precision cannot be implemented with chrono. I would suggest to just avoid the sample rate based clocks then and use timestamps in conventional units (ms, us, ns...). -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4997224.LIi1sQ1Xyy%40lastique-pc. --nextPart2681720.v7ipKe8ngQ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

On Saturday= , 11 June 2016 10:55:17 MSK alexander.zywicki@gmail.com wrote:

> I lie = your thought on the clock idea and +1 for the example. A few thoughts

> though= , I would like to explain the distinction that I draw between an

> "= arbitrary epoch" and a "dynamic epoch" as I had proposed. It= would not be

> arbitr= ary in that it would be set to some random point, but rather would be

> set to= o a significant time point in terms of the current instance of the

> progra= m... It would be reset to the time when the stream was started. In

> port a= udio it would be set to the time when Pa_StartStream was called,

> having= that as a reference point would allow you to manage the local time

> within= that stream easily.

&nb= sp;

If I unders= tood you right, that's exactly what I'm arguing against.

&nb= sp;

> As a s= econd note the sample rate will most likely need to be a runtime

> parame= ter and cannot be a template parameter because of such( unless we

> specif= y the need for a factory to create clocks of different sample rates)

> we wil= l probably not know the desired sample rate or even the supported

> sampli= ng rates at compile time

&nb= sp;

A runtime-s= et precision cannot be implemented with chrono. I would suggest to just avo= id the sample rate based clocks then and use timestamps in conventional uni= ts (ms, us, ns...).

&nb= sp;

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/= d/msgid/std-proposals/4997224.LIi1sQ1Xyy%40lastique-pc.
--nextPart2681720.v7ipKe8ngQ-- .