220 26240 <485D94E9-3386-4C2E-8C90-2AE821C3B7E6@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: Fri, 10 Jun 2016 07:24:47 -0500 Lines: 350 Approved: news@gmane.org Message-ID: <485D94E9-3386-4C2E-8C90-2AE821C3B7E6@gmail.com> References: <5751B06A.4080501@mail1.stofanet.dk> <83016a47-e902-4292-b109-652e811d17fb@isocpp.org> <2271827.u9FbM9WbyY@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-7E39CDD2-52E1-441D-87C6-FBDC55D40E01 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1465561548 14578 80.91.229.3 (10 Jun 2016 12:25:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jun 2016 12:25:48 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCS7TY6DTQOBBEXD5K5AKGQEBA4LUWA@isocpp.org Fri Jun 10 14:25:44 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f200.google.com ([209.85.220.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bBLUa-0006Hi-8z for gclcip-std-proposals@m.gmane.org; Fri, 10 Jun 2016 14:24:52 +0200 Original-Received: by mail-qk0-f200.google.com with SMTP id t65sf140236825qkh.3 for ; Fri, 10 Jun 2016 05:24:52 -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=RZ+AQ/7LFG1PjDFUD/8xRmkX63Cj8DAymubCnnTkpjY=; b=wbLxhaWCpRSeZzBbbxOQbJFlFOBie/WMBQEU2DgpjedA0nXoLyJBNxx/mJkRb0WjLX ojELCfY8MjhLLI0zJy/v3wcfO9ox3iEsKPDFcNnM+e8H2F1+wDrtelpnX3MUduEXThqO jag3ie/y+QK8wwRNgjKY0o8AmLaK2D3oSR1Db/gBTd44Yvq9JZTmIgWv1HHVHmrZCyw2 0BUNZ6aq0U+hAYI0RUGxHxzMVAew9ke2m8/GUVJkTN52+47SKhSbuEkkp+q9uRRS7Dum lMnnR9VsVak6wU5mVrt3ZlptnO2dtxLzSslgOEHijV58fdgXaPMngFyiesP/Xnn6q8Rn NsJA== 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=RZ+AQ/7LFG1PjDFUD/8xRmkX63Cj8DAymubCnnTkpjY=; b=QL95t7QZTWgpt9jg1J21ykgmUlHwfh6SrP7EqjtweWR+gcpaQAv8Zy70Mr1BhdpXWp AslTb0bCRnqKgqWJJZT4LdBDNsktv+EU7gOREdzm8ioYNGtbgGbvcVpMd8wICxrE2INX +a9ouDSH9CBM0fmLs90Y//lJEVyutRF5uQVOlf5M1PWXtN2IY2dYBT3xmoc+7yUwwfY+ Ilm3oxEP2+hOVuUFOVSzCYo9RoyieVVaz/e55y8H3dmOmoBjKENRAEPmijLnKc/I2ppJ BH3qqtz0F/bot/H9lrmlVbinODHSf6mBRGkKG+QBeRtVAOMKP/+rcC91nazG2RPsZjiK wkr X-Gm-Message-State: ALyK8tJ+zqAEKZwfG4oCdw3uyLeEDb/huHQh7DhSUZOzO2OhFmN2nWpOhZhIuUQNpvkKhw== X-Received: by 10.140.107.7 with SMTP id g7mr1078603qgf.23.1465561491525; Fri, 10 Jun 2016 05:24:51 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.68.73 with SMTP id o70ls208400ita.42.gmail; Fri, 10 Jun 2016 05:24:50 -0700 (PDT) X-Received: by 10.36.112.199 with SMTP id f190mr30350261itc.6.1465561490567; Fri, 10 Jun 2016 05:24:50 -0700 (PDT) Original-Received: from mail-io0-x229.google.com (mail-io0-x229.google.com. [2607:f8b0:4001:c06::229]) by mx.google.com with ESMTPS id f123si1417076ita.23.2016.06.10.05.24.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jun 2016 05:24:50 -0700 (PDT) Received-SPF: pass (google.com: domain of alexander.zywicki@gmail.com designates 2607:f8b0:4001:c06::229 as permitted sender) client-ip=2607:f8b0:4001:c06::229; Original-Received: by mail-io0-x229.google.com with SMTP id n127so63990023iof.3 for ; Fri, 10 Jun 2016 05:24:50 -0700 (PDT) X-Received: by 10.107.140.6 with SMTP id o6mr3766159iod.42.1465561490152; Fri, 10 Jun 2016 05:24:50 -0700 (PDT) Original-Received: from [10.194.86.160] ([166.170.220.135]) by smtp.gmail.com with ESMTPSA id o4sm5441898itc.18.2016.06.10.05.24.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 05:24:48 -0700 (PDT) X-Mailer: iPhone Mail (13F69) In-Reply-To: <2271827.u9FbM9WbyY@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::229 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:26240 Archived-At: --Apple-Mail-7E39CDD2-52E1-441D-87C6-FBDC55D40E01 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 "ar= bitrary epoch" and a "dynamic epoch" as I had proposed. It would not be arb= itrary in that it would be set to some random point, but rather would be se= t too a significant time point in terms of the current instance of the prog= ram... 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 tha= t as a reference point would allow you to manage the local time within that= stream easily.=20 As a second note the sample rate will most likely need to be a runtime para= meter 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 r= ates at compile time > On Jun 10, 2016, at 5:34 AM, Andrey Semashev = wrote: >=20 > On Friday, 10 June 2016 13:11:14 MSK alexander.zywicki@gmail.com wrote: > > I suppose we could use the std::chrono library as a basis, and define a > > clock type that has a dynamically set epoch. This would allow a time-po= int > > to have a value relative to when the stream was started? > > > > So maybe the introduction of: > > > > std::audio::sample_clock;//a clock type that counts in frames(or sample= s) > > /* > > -has internal member of "rate" that is used for conversion > > -keeps track of number of frames(or samples) elapsed > > -can produce a time_point that is a real number of seconds from epoch. > > -epoch can be reset > > -clock will be synced with hardware??? if possible?? or good idea?? > > > > */ > > std::chrono::time_point foo;//the current tim= e > > since epoch in seconds > =20 > +1 for using chrono. > =20 > +1 for monotonic clock (as Ross suggested). At least, by default. > =20 > -1 for using an arbitrary epoch clock. > =20 > In my practice I found it useful to be able to synchronize multiple strea= ms, which may not have started at the same time. Or in the same process at = all. > =20 > I'm not sure there is much use in binding particular frames to the real w= orld clock, at least not in audio processing domain. In video/image process= ing this could be useful, e.g. to present an image to the user at the given= time. However, I feel it would still be useful to allow specifying a custo= m clock to the audio processing framework as well. > =20 > One use case I have in mind is providing a custom clock which is guarante= ed to be equivalent to CLOCK_MONOTONIC on POSIX systems. Unlike std::chrono= ::steady_clock, this custom clock would be useful in interfacing with OS pr= imitives like condition variables or events. Having such clock time points = in audio frames would be useful. > =20 > One other thing that could be useful is a clock adaptor, which implements= the usual clock interface, but provides time points in sample rate units. = The actual time readings would be obtained from an underlying clock. Someth= ing like this: > =20 > template< typename BaseClock, unsigned int SampleRate > > class sample_rate_clock > { > public: > typedef BaseClock base_clock; > static constexpr unsigned int sample_rate =3D SampleRate; > typedef ratio< 1, sample_rate > period; > typedef typename base_clock::rep rep; > typedef std::chrono::duration< rep, period > duration; > typedef std::chrono::time_point< sample_rate_clock > time_point; > // ...etc. - other clock members as usual, > // imported from BaseClock as needed > =20 > static time_point now() > { > return time_point(duration_cast< duration >( > base_clock::now().time_since_epoch())); > } > }; > =20 > Or, on the second thought, this might be a generic tool, not related to a= udio processing at all... > =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/2271827.u9FbM9WbyY%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/485D94E9-3386-4C2E-8C90-2AE821C3B7E6%40gmail.com= .. --Apple-Mail-7E39CDD2-52E1-441D-87C6-FBDC55D40E01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I lie your thought on t= he clock idea and +1 for the example. A few thoughts though, I would like t= o explain the distinction that I draw between an "arbitrary epoch" and a "d= ynamic 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 tim= e point in terms of the current instance of the program... It would be rese= t 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. 

As a second note the sample rate will most likely n= eed 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 differe= nt sample rates) we will probably not know the desired sample rate or even = the supported sampling rates at compile time

On Jun 10, 2016,= at 5:34 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:

On Friday, = 10 June 2016 13:11:14 MSK al= exander.zywicki@gmail.com wrote:

> I supp= ose we could use the std::chrono library as a basis, and define a

> clock = type that has a dynamically set epoch. This would allow a time-point

> to hav= e a value relative to when the stream was started?

>

> So may= be the introduction of:

>

> std::a= udio::sample_clock;//a clock type that counts in frames(or samples)

> /*

> -has i= nternal member of "rate" that is used for conversion

> -keeps= track of number of frames(or samples) elapsed

> -can p= roduce a time_point that is a real number of seconds from epoch.

> -epoch= can be reset

> -clock= will be synced with hardware??? if possible?? or good idea??

>

> */

> std::c= hrono::time_point<std::audio::sample_clock> foo;//the current time

> since = epoch in seconds

&nb= sp;

+1 for usin= g chrono.

&nb= sp;

+1 for mono= tonic clock (as Ross suggested). At least, by default.

&nb= sp;

-1 for usin= g an arbitrary epoch clock.

&nb= sp;

In my pract= ice I found it useful to be able to synchronize multiple streams, which may= not have started at the same time. Or in the same process at all.

&nb= sp;

I'm not sur= e there is much use in binding particular frames to the real world clock, a= t least not in audio processing domain. In video/image processing this coul= d be useful, e.g. to present an image to the user at the given time. Howeve= r, I feel it would still be useful to allow specifying a custom clock to th= e audio processing framework as well.

&nb= sp;

One use cas= e I have in mind is providing a custom clock which is guaranteed to be equi= valent to CLOCK_MONOTONIC on POSIX systems. Unlike std::chrono::steady_cloc= k, this custom clock would be useful in interfacing with OS primitives like= condition variables or events. Having such clock time points in audio fram= es would be useful.

&nb= sp;

One other t= hing that could be useful is a clock adaptor, which implements the usual cl= ock interface, but provides time points in sample rate units. The actual ti= me readings would be obtained from an underlying clock. Something like this= :

&nb= sp;

template&= lt; typename BaseClock, unsigned int SampleRate >

class sam= ple_rate_clock

{

public:

typedef= BaseClock base_clock;

static = constexpr unsigned int sample_rate =3D SampleRate;

typedef= ratio< 1, sample_rate > period;

typedef= typename base_clock::rep rep;

typedef= std::chrono::duration< rep, period > duration;

typedef= std::chrono::time_point< sample_rate_clock > time_point;

// ...e= tc. - other clock members as usual,

// impo= rted from BaseClock as needed

&nb= sp;

static = time_point now()

{

retur= n time_point(duration_cast< duration >(

bas= e_clock::now().time_since_epoch()));

}

};

&nb= sp;

Or, on the = second thought, this might be a generic tool, not related to audio processi= ng at all...

&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/2271827.u9FbM9WbyY%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/485D94E9-3386-4C2E-8C90-2AE821C3B7E6%= 40gmail.com.
--Apple-Mail-7E39CDD2-52E1-441D-87C6-FBDC55D40E01-- .