220 26314 <0CBC13EE-E8D2-47D8-A7E9-484B6AF0F02A@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:46:50 -0500 Lines: 356 Approved: news@gmane.org Message-ID: <0CBC13EE-E8D2-47D8-A7E9-484B6AF0F02A@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-738C6CDE-EAD2-4C84-9A9B-DBAC83FBEF25 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1465818422 4961 80.91.229.3 (13 Jun 2016 11:47:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Jun 2016 11:47:02 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCS7TY6DTQOBBLN27K5AKGQE7FUIAKQ@isocpp.org Mon Jun 13 13:46:57 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f72.google.com ([209.85.220.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bCQKV-00088b-UY for gclcip-std-proposals@m.gmane.org; Mon, 13 Jun 2016 13:46:56 +0200 Original-Received: by mail-pa0-f72.google.com with SMTP id ug1sf205533154pab.3 for ; Mon, 13 Jun 2016 04:46:55 -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=jsbvW/ECSHza/kOsZNg3jnEU5jsE1MENcQDgGPk1ew4=; b=UnEiu9UFQHBkYIP+/wN0snMFd14N9YjyQkeDVfP63vKXi8G2lgSZEdyVgLA24L5acp oTi5UiPbjuUg0OngYskOe+h08E9aCj9s/UV8FGzx6XNXD21LDj9xy08c2iAEqt8KSGtf SBr2j2qZGZ5cPZPc8u9aMszhGqcpgdAl2pf7Y1fTeK/B2Z+P0d1PvqrQPXpYnlAfbu7H KAph1Ike+eW8LkerScODNMFisfvn5moL2Tc9SRgvrptEU8kTmcnivYaxW/E9E1lmJwbE s5nHZ7BU7wy8yNsuoyVRG2ibv84h+p5DB2iNa56Tndujgm7GdkWwZqZr+9FnuEWU/ByI XuKQ== 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=jsbvW/ECSHza/kOsZNg3jnEU5jsE1MENcQDgGPk1ew4=; b=FcVaXaYnYj3LsH83t7Cyiqwzv33TDr+HGZa+OK3NEHUP3sj3N9dFH+mkH94g2DamI1 LD46ldG+HDAYtgkPAATd3blMi3y7E4eqh27bswclTGtEFTsU/9nD6syFleVN8RTj2lQ8 IJwmV3BMCtANBCvanlkUgUXiRJ6KlT5omK9AUO/NoIW3KafjrxCixECnAdQ6hzENU0z8 IWu9HjraRyAiybN3QWLWDVphuQ9rjOWOfmwG9zXXwxa0Gg0ui4Sj2+xtgYGXhNnnzoy1 tMPw9HAsD1EEuW91uTMsoe/VTIjXByeGrKUuOSboSljDRtx5Eeap0Gsp5NCU8UHzIpjH 1UE X-Gm-Message-State: ALyK8tLNSXzxLbvjLCSrmx/1KMk7iB5RwZm3O2Pfku9ENyb5RWGYXf2vC+0xIN/0ZA326Q== X-Received: by 10.66.187.237 with SMTP id fv13mr7380165pac.23.1465818414800; Mon, 13 Jun 2016 04:46:54 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.236.6 with SMTP id g6ls880262ith.36.gmail; Mon, 13 Jun 2016 04:46:53 -0700 (PDT) X-Received: by 10.107.11.26 with SMTP id v26mr17076203ioi.107.1465818413597; Mon, 13 Jun 2016 04:46:53 -0700 (PDT) Original-Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com. [2607:f8b0:4001:c06::22d]) by mx.google.com with ESMTPS id e16si25927768iof.104.2016.06.13.04.46.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jun 2016 04:46:53 -0700 (PDT) Received-SPF: pass (google.com: domain of alexander.zywicki@gmail.com designates 2607:f8b0:4001:c06::22d as permitted sender) client-ip=2607:f8b0:4001:c06::22d; Original-Received: by mail-io0-x22d.google.com with SMTP id n127so117426654iof.3 for ; Mon, 13 Jun 2016 04:46:53 -0700 (PDT) X-Received: by 10.107.24.7 with SMTP id 7mr24973242ioy.171.1465818413226; Mon, 13 Jun 2016 04:46:53 -0700 (PDT) Original-Received: from [10.178.170.106] ([166.175.187.35]) by smtp.gmail.com with ESMTPSA id j143sm2745225ita.16.2016.06.13.04.46.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Jun 2016 04:46:51 -0700 (PDT) X-Mailer: iPhone Mail (13F69) In-Reply-To: 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::22d 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:26314 Archived-At: --Apple-Mail-738C6CDE-EAD2-4C84-9A9B-DBAC83FBEF25 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That could be a workable idea. The definition proposed earlier would be for= just the high resolution clock though. That definition provides a type tha= t will always be steady and could be high resolution as well. The important= part is steady. Please note that the standard says that high_resolution_cl= ock can be an alias of steady clock, system clock or its own third clock ty= pe. A sample clock would need to be custom built to count in samples as wel= l as somehow sync with other clocks(hardware and software) and would probab= ly not be as useful as I had originally thought. Having a steady high resol= ution clock in seconds would be much more versatile than a sample clock. > On Jun 13, 2016, at 4:32 AM, ron novy wrote: >=20 > Well, what if we just had both a sample clock and a high resolution clock= together? One could then use either or both at their own discretion. And= theoretically you could then calculate some approximation of clock jitter = or drift between buffers/packets or separate record devices. Or does that = even make sense? >=20 >> On Mon, Jun 13, 2016 at 1:24 AM, Andrey Semashev wrote: >> As I suggested earlier, I think the clock should be specified by the use= r (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 wr= ote: >> > > In that case I would argue for the use of the "std::chrono::steady_c= lock" >> > > 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" a= lways >> > > 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 w= rote: >> > > > Or at least store a time point each time the stream is started usi= ng a >> > > >> > > clock >> > > >> > > > with a well defined epoch, so that we might be able to find the le= ngth >> > > > of >> > > > >> > > > time that the stream has been active and have meaningful measureme= nts of >> > > > >> > > > time within the stream. >> > > >> > > There is no need to have the epoch bound to the beginning of the str= eam 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 t= he >> > > epoch; what is important is that it has to be the same for all strea= ms you >> > > are processing. >> =20 >> =20 >> --=20 >> You received this message because you are subscribed to the Google Group= s "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n 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/iso= cpp.org/d/msgid/std-proposals/2897526.WjqoZ8n3I9%40lastique-pc. >=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/CAOcFa%3DdvmLW0u8R3MesuJMc7rbkewr%2Bmbv1qjVSQ3= ip_U%3DsbZA%40mail.gmail.com. --=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/0CBC13EE-E8D2-47D8-A7E9-484B6AF0F02A%40gmail.com= .. --Apple-Mail-738C6CDE-EAD2-4C84-9A9B-DBAC83FBEF25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That could be a workabl= e idea. The definition proposed earlier would be for just the high resoluti= on clock though. That definition provides a type that will always be steady= and could be high resolution as well. The important part is steady. Please= note that the standard says that high_resolution_clock can be an alias of = steady clock, system clock or its own third clock type. A sample clock woul= d need to be custom built to count in samples as well as somehow sync with = other clocks(hardware and software) and would probably not be as useful as = I had originally thought. Having a steady high resolution clock in seconds = would be much more versatile than a sample clock.

On Jun 13, = 2016, at 4:32 AM, ron novy <rsn101= 00@gmail.com> wrote:

Well, what if we just had both a sample clock and a high reso= lution clock together?  One could then use either or both at their own= discretion.  And theoretically you could then calculate some approxim= ation of clock jitter or drift between buffers/packets or separate record d= evices.  Or does that even make sense?

On Mon, Jun 13, 2016 at 1:24 AM, Andrey Sem= ashev <andrey.semashev@gmail.com> wrote:

As I suggested earlier, I think the clock should be spe= cified by the user (probably as a template parameter for the audio frame).<= /p>

 

On Monday, 13 June 2016 11:22:50 MSK alexander.zywicki@gmail.com<= /a> wrote:

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

>

> #include <chrono>

> #include <type_traits>

>

> //define audio_clock as high_resolution clock if h= igh_resolution clock

> is_steady=3D=3Dtrue else use steady_clock

> //conditional will result in a clock that is monot= onic either way

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

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

> 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.co= m wrote:

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

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

> >

> > Or a clock defined in a similar manor that co= unts in samples.

> >

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

> > be true?

> >

> >

> > On Jun 11, 2016, at 4:09 AM, Andrey Semashev = <andrey.s= emashev@gmail.com>

> > wrote:

> >

> > On Saturday, 11 June 2016 11:03:41 MSK alexander.zywick= i@gmail.com wrote:

> > > Or at least store a time point each time= the stream is started using a

> >

> > clock

> >

> > > with a well defined epoch, so that we mi= ght be able to find the length

> > > of

> > >

> > > time that the stream has been active and= have meaningful measurements of

> > >

> > > time within the stream.

> >

> > There is no need to have the epoch bound to t= he beginning of the stream to

> > calculate its duration. Or any particular epo= ch 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 impo= rtant what exactly is the

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

> > are processing.

 

 

--
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.go= ogle.com/a/isocpp.org/d/msgid/std-proposals/2897526.WjqoZ8n3I9%40lastique-p= c.

--
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/CAOcFa%= 3DdvmLW0u8R3MesuJMc7rbkewr%2Bmbv1qjVSQ3ip_U%3DsbZA%40mail.gmail.com.

--
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/0CBC13EE-E8D2-47D8-A7E9-484B6AF0F02A%= 40gmail.com.
--Apple-Mail-738C6CDE-EAD2-4C84-9A9B-DBAC83FBEF25-- .