220 26312 article Path: news.gmane.org!not-for-mail From: ron novy Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Any interest to adding audio support to the std library? Date: Mon, 13 Jun 2016 02:32:00 -0700 Lines: 350 Approved: news@gmane.org Message-ID: 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 Content-Type: multipart/alternative; boundary=001a1135b1949711a80535258fb2 X-Trace: ger.gmane.org 1465810325 7919 80.91.229.3 (13 Jun 2016 09:32:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Jun 2016 09:32:05 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDO2TPGE4QNBBE737G5AKGQEGZMK24Q@isocpp.org Mon Jun 13 11:32:05 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f198.google.com ([209.85.213.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bCOE0-0007h1-RT for gclcip-std-proposals@m.gmane.org; Mon, 13 Jun 2016 11:32:05 +0200 Original-Received: by mail-ig0-f198.google.com with SMTP id lp2sf94671281igb.3 for ; Mon, 13 Jun 2016 02:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject: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=I9BeHmkWUu6XnQ3FO+bUCaO3t6P+iXdBIsYE0heMtMA=; b=eCtzWqLx2N6zXQ4M/Ru3LgqUumysv2082EjVEdulS7ffWRws7ixObqWSNn/rK7fobm hnw/Q6eEHCUjd2peOFWIRTN3WCK+Z0fe9RbvvEc/pHttqdpTT32wExZ0DXEmbGWhOZDQ vXM3K3U37GS6NURYL6RSxg2YQm75m8zPkchK/YfrzADP2to8OcsdxTsmm1NbTbIKGLcN vWte19701M5KDUlJkhXC9rVed24CCRUo84gGn+a2Q01IMRdE79QGaPyUdZYT4TRPcRMl mWDe2fchhYFL9C4fXziFmjz2G/O6EnPdD1hSCkhNmRDC6ucG4Rl6SUKkxbtk1Zw4bn+b 7ONg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject: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=I9BeHmkWUu6XnQ3FO+bUCaO3t6P+iXdBIsYE0heMtMA=; b=FMXoG2x5TfdLsgVMP6Vz7bFPa027Hfj2L/vxseIaYaZCY0KCTamSfbajHTZWzp344e AVKpOFRt/h+ZvI1SKwFX03rKYdmNC3+VrAQ2wlGk0ZmoFFuksDiWivlDEEBVkvfL4QRz tqqkmsoG9fD36Nz8C628gbDeI/dOPDhZHhQneCZ1SeBAtbFmEZRzJgg+I83QAeUoZSeG 3EFunniL9JneroiP4PZvvOz6Z5OrIoKhOsRDuOKre3+t/1MOoIZxe5tBJvu8CI/dTat/ AgHrut77BCZkBGGl++5p88UKre7gY8YnTZJpGkEiJE3rOUTue39G73YkCFn7KVIo5Bwb NlUA== X-Gm-Message-State: ALyK8tLD0s+U0ZuZujtc8l8DOYMgwdEa4lPsEyDuEPGRcW5T4Kys7u+97j8SE/KwkHKQOw== X-Received: by 10.157.61.38 with SMTP id a35mr11400059otc.20.1465810323894; Mon, 13 Jun 2016 02:32:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.227.200 with SMTP id d191ls228333ith.5.gmail; Mon, 13 Jun 2016 02:32:02 -0700 (PDT) X-Received: by 10.36.210.198 with SMTP id z189mr13268920itf.32.1465810322894; Mon, 13 Jun 2016 02:32:02 -0700 (PDT) Original-Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com. [2607:f8b0:4001:c0b::22a]) by mx.google.com with ESMTPS id j27si25219446ioi.109.2016.06.13.02.32.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jun 2016 02:32:02 -0700 (PDT) Received-SPF: pass (google.com: domain of rsn10100@gmail.com designates 2607:f8b0:4001:c0b::22a as permitted sender) client-ip=2607:f8b0:4001:c0b::22a; Original-Received: by mail-it0-x22a.google.com with SMTP id a5so44233482ita.1 for ; Mon, 13 Jun 2016 02:32:02 -0700 (PDT) X-Received: by 10.36.29.5 with SMTP id 5mr3277998itj.61.1465810322656; Mon, 13 Jun 2016 02:32:02 -0700 (PDT) Original-Received: by 10.64.29.204 with HTTP; Mon, 13 Jun 2016 02:32:00 -0700 (PDT) In-Reply-To: <2897526.WjqoZ8n3I9@lastique-pc> X-Original-Sender: rsn10100@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of rsn10100@gmail.com designates 2607:f8b0:4001:c0b::22a as permitted sender) smtp.mailfrom=rsn10100@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:26312 Archived-At: --001a1135b1949711a80535258fb2 Content-Type: text/plain; charset=UTF-8 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? 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 user > (probably as a template parameter for the audio frame). > > > > 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==true 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 = 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 > 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 counts in samples. > > > > > > > > I also would imagine that our clock would need to have "is_steady" > always > > > > be true? > > > > > > > > > > > > On Jun 11, 2016, at 4:09 AM, Andrey Semashev < > andrey.semashev@gmail.com> > > > > wrote: > > > > > > > > On Saturday, 11 June 2016 11:03:41 MSK alexander.zywicki@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 might 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 the beginning of the > stream 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 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 > 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 "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/CAOcFa%3DdvmLW0u8R3MesuJMc7rbkewr%2Bmbv1qjVSQ3ip_U%3DsbZA%40mail.gmail.com. --001a1135b1949711a80535258fb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, what if we just had both a sample clock and a high r= esolution clock together?=C2=A0 One could then use either or both at their = own discretion.=C2=A0 And theoretically you could then calculate some appro= ximation of clock jitter or drift between buffers/packets or separate recor= d devices.=C2=A0 Or does that even make sense?

On Mon, Jun 13, 2016 at 1:24 AM, Andrey = Semashev <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>

=C2=A0

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 = important what exactly is the

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

> > are processing.

=C2=A0

=C2=A0

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