220 26315 <8DC89BEC-9ED2-4268-9D12-77D7C57128CC@gmail.com> article Path: news.gmane.org!not-for-mail From: alexander.zywicki@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Any interest to adding audio support to the std library? Date: Mon, 13 Jun 2016 06:48:45 -0500 Lines: 340 Approved: news@gmane.org Message-ID: <8DC89BEC-9ED2-4268-9D12-77D7C57128CC@gmail.com> References: <5751B06A.4080501@mail1.stofanet.dk> <8AB38C1F-590D-4F81-9839-D7A4604E1831@gmail.com> <2943c5c2-2c46-4447-b8f6-7647fc34d52c@isocpp.org> <2897526.WjqoZ8n3I9@lastique-pc> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-07E7F8DF-30EC-4467-9F11-C5FF69FD73F6 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1465818545 6844 80.91.229.3 (13 Jun 2016 11:49:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Jun 2016 11:49:05 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCS7TY6DTQOBBIF37K5AKGQEBLTTFPQ@isocpp.org Mon Jun 13 13:48:50 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bCQMM-0000yF-Dn for gclcip-std-proposals@m.gmane.org; Mon, 13 Jun 2016 13:48:50 +0200 Original-Received: by mail-vk0-f69.google.com with SMTP id k189sf228041633vkg.3 for ; Mon, 13 Jun 2016 04:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to :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=SuArmMM+qRjqAYfSgBROTVR8vW8QvYx4n2eDpeUHzhc=; b=CQtBQl8Ga2kFyaSeHbo3fu3MgPWom4Kxu8tL8xdGKqBMF+mCngGfAL9YUbRFgg4jdT gRgjGZH9/tAe+16fdo1JyUNqoqKA3fkq/DSqH40QnPXQ2AeJcDieMTlSRiZsZb0Kj/45 2t8Rn0LLfLMpVGf97opFoldaeQmWoiRGUTpAZ5OZC3i6Mm5kNZUlPL8FU5RvK7A4u6QU kfcht8fMwbu2s0+LJO1DHd3n5dYgjMiEDIQh8aRvj5cdVBwtI/BnRflC960DaJkJhwUS YE0fX7SMvOpnz7DcxF8OaTZdJolUWmIR5f48NdZNzHAU8GOzni6JaIJ84yXLOz6Naftv F3bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to :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=SuArmMM+qRjqAYfSgBROTVR8vW8QvYx4n2eDpeUHzhc=; b=IKqEQrGgHsqXn3/8M0lgNuwie1gmWIMxliFsOx5L2/7UAiGzrG0a2JPQmL9K1WNgpY beXXz2W1heO4lRaCx/9d2lE5ZNu3hsSBLGp1T0+iw5I40+CE74Y6XRg+7W0XKvMg03nj aCbDnO+JDnLHG1QSJ/HZxDargsGvvKgPYbZRAqNtk1L1VXePFbxRS0rKDx1ElcLAx2QQ ZOx8cdlsDa9bxTU2+LOYkgQNw7Btl3Y2EKri2dylUfK8RbEmOKcoKhMhcj0gVxP3MVtR p8HN9sDcBKx2piDoZF9FqlR5yVamfqSOIqY0vCytpkQGDg8JeVMSJcxIBiUg0FVd3Hnz ZsN X-Gm-Message-State: ALyK8tKD9JQPAOZh31uB972GRC7nUQWw6l17mZTeQ/AfjgXNjJwyalNRJtiDGkK73VQrwA== X-Received: by 10.129.157.129 with SMTP id u123mr11793166ywg.33.1465818529498; Mon, 13 Jun 2016 04:48:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.155.85 with SMTP id o82ls967913itd.12.canary; Mon, 13 Jun 2016 04:48:48 -0700 (PDT) X-Received: by 10.107.131.98 with SMTP id f95mr22117232iod.136.1465818528528; Mon, 13 Jun 2016 04:48:48 -0700 (PDT) Original-Received: from mail-io0-x234.google.com (mail-io0-x234.google.com. [2607:f8b0:4001:c06::234]) by mx.google.com with ESMTPS id p138si12494296itg.34.2016.06.13.04.48.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jun 2016 04:48:48 -0700 (PDT) Received-SPF: pass (google.com: domain of alexander.zywicki@gmail.com designates 2607:f8b0:4001:c06::234 as permitted sender) client-ip=2607:f8b0:4001:c06::234; Original-Received: by mail-io0-x234.google.com with SMTP id o127so71266780iod.2 for ; Mon, 13 Jun 2016 04:48:48 -0700 (PDT) X-Received: by 10.107.10.35 with SMTP id u35mr21765568ioi.92.1465818528300; Mon, 13 Jun 2016 04:48:48 -0700 (PDT) Original-Received: from [10.178.170.106] ([166.175.187.35]) by smtp.gmail.com with ESMTPSA id r19sm1072130itc.17.2016.06.13.04.48.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Jun 2016 04:48:46 -0700 (PDT) X-Mailer: iPhone Mail (13F69) In-Reply-To: <2897526.WjqoZ8n3I9@lastique-pc> X-Original-Sender: alexander.zywicki@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of alexander.zywicki@gmail.com designates 2607:f8b0:4001:c06::234 as permitted sender) smtp.mailfrom=alexander.zywicki@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:26315 Archived-At: --Apple-Mail-07E7F8DF-30EC-4467-9F11-C5FF69FD73F6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If that should be the case we would have to write a type trait that makes s= ure that the user supplied clock was an acceptable clock source. I suggest = using the built in ones for the mean time because the std makes certain gua= rantees about those clocks that can make sure that thy meet our needs. Not = to mention that a default would be needed even if we allowed user supplied = clocks > On Jun 13, 2016, at 3:24 AM, Andrey Semashev = wrote: >=20 > As I suggested earlier, I think the clock should be specified by the user= (probably as a template parameter for the audio frame). > =20 > On Monday, 13 June 2016 11:22:50 MSK alexander.zywicki@gmail.com wrote: > > How do you all feel about this definition for a clock? > > > > #include > > #include > > > > //define audio_clock as high_resolution clock if high_resolution clock > > is_steady=3D=3Dtrue else use steady_clock > > //conditional will result in a clock that is monotonic either way > > //but can result in using a high_resolution_clock on certain platforms > > using audio_clock =3D typename std::conditional > high_resolution_clock::is_steady, > > std::chrono:: > > high_resolution_clock, > > std::chrono::steady_clock>:: > > type; > > > > On Sunday, June 12, 2016 at 4:09:44 PM UTC-5, alexande...@gmail.com wro= te: > > > In that case I would argue for the use of the "std::chrono::steady_cl= ock" > > > based on the fact that it is specified to be a monotonic clock. > > > > > > Or a clock defined in a similar manor that counts in samples. > > > > > > I also would imagine that our clock would need to have "is_steady" al= ways > > > be true? > > > > > > > > > On Jun 11, 2016, at 4:09 AM, Andrey Semashev > > > wrote: > > > > > > On Saturday, 11 June 2016 11:03:41 MSK alexander.zywicki@gmail.com wr= ote: > > > > Or at least store a time point each time the stream is started usin= g a > > > > > > clock > > > > > > > with a well defined epoch, so that we might be able to find the len= gth > > > > of > > > > > > > > time that the stream has been active and have meaningful measuremen= ts of > > > > > > > > time within the stream. > > > > > > There is no need to have the epoch bound to the beginning of the stre= am to > > > calculate its duration. Or any particular epoch at all. All you need = is > > > the > > > timestamp of its first and last frames. > > > > > > > > > > > > A fixed epoch becomes important when you try to synchronize multiple > > > streams together. But even then it's not important what exactly is th= e > > > epoch; what is important is that it has to be the same for all stream= s you > > > are processing. > =20 > =20 > --=20 > You received this message because you are subscribed to a topic in the Go= ogle Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.= org/d/topic/std-proposals/Hkdh02Ejx6s/unsubscribe. > To unsubscribe from this group and all its topics, send an email to std-p= roposals+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/isoc= pp.org/d/msgid/std-proposals/2897526.WjqoZ8n3I9%40lastique-pc. --=20 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 e= mail 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/8DC89BEC-9ED2-4268-9D12-77D7C57128CC%40gmail.com= .. --Apple-Mail-07E7F8DF-30EC-4467-9F11-C5FF69FD73F6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If that should be the c= ase we would have to write a type trait that makes sure that the user suppl= ied clock was an acceptable clock source. I suggest using the built in ones= for the mean time because the std makes certain guarantees about those clo= cks that can make sure that thy meet our needs. Not to mention that a defau= lt would be needed even if we allowed user supplied clocks

On= Jun 13, 2016, at 3:24 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:

As I sugges= ted earlier, I think the clock should be specified by the user (probably as= a template parameter for the audio frame).

&nb= sp;

On Monday, = 13 June 2016 11:22:50 MSK al= exander.zywicki@gmail.com wrote:

> How do= you all feel about this definition for a clock?

>

> #inclu= de <chrono>

> #inclu= de <type_traits>

>

> //defi= ne audio_clock as high_resolution clock if high_resolution clock

> is_ste= ady=3D=3Dtrue else use steady_clock

> //cond= itional will result in a clock that is monotonic either way

> //but = can result in using a high_resolution_clock on certain platforms

> using = audio_clock =3D typename std::conditional<std::chrono::

> high_r= esolution_clock::is_steady,

> = std::chrono::

> high_r= esolution_clock,

> = std::chrono::steady_clock>::

> type;<= /p>

>

> On Sun= day, June 12, 2016 at 4:09:44 PM UTC-5, alexande...@gmail.com wrote:

> > I= n that case I would argue for the use of the "std::chrono::steady_clock"

> > b= ased on the fact that it is specified to be a monotonic clock.

> > <= /p>

> > O= r a clock defined in a similar manor that counts in samples.

> > <= /p>

> > I= also would imagine that our clock would need to have "is_steady" always

> > b= e true?

> > <= /p>

> > <= /p>

> > O= n Jun 11, 2016, at 4:09 AM, Andrey Semashev <andrey.semashev@gmail.com>

> > w= rote:

> > <= /p>

> > O= n Saturday, 11 June 2016 11:03:41 MSK alexander.zywicki@gmail.com wrote:

> > &= gt; Or at least store a time point each time the stream is started using a<= /p>

> > <= /p>

> > c= lock

> > <= /p>

> > &= gt; with a well defined epoch, so that we might be able to find the length<= /p>

> > &= gt; of

> > &= gt;

> > &= gt; time that the stream has been active and have meaningful measurements o= f

> > &= gt;

> > &= gt; time within the stream.

> > <= /p>

> > T= here is no need to have the epoch bound to the beginning of the stream to

> > c= alculate its duration. Or any particular epoch at all. All you need is

> > t= he

> > t= imestamp of its first and last frames.

> > <= /p>

> > <= /p>

> > <= /p>

> > A= fixed epoch becomes important when you try to synchronize multiple

> > s= treams together. But even then it's not important what exactly is the

> > e= poch; what is important is that it has to be the same for all streams you

> > a= re processing.

&nb= sp;

&nb= sp;

--
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.= google.com/a/isocpp.org/d/topic/std-proposals/Hkdh02Ejx6s/unsubscribe.<= br> To unsubscribe from this group and all its topics, 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/2897526.WjqoZ8n3I9%40lastique-pc.

--
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.c= om/a/isocpp.org/d/msgid/std-proposals/8DC89BEC-9ED2-4268-9D12-77D7C57128CC%= 40gmail.com.
--Apple-Mail-07E7F8DF-30EC-4467-9F11-C5FF69FD73F6-- .