220 26241 <31D8D875-9842-4CC4-98C6-F75FD20155DE@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:37:21 -0500 Lines: 364 Approved: news@gmane.org Message-ID: <31D8D875-9842-4CC4-98C6-F75FD20155DE@gmail.com> References: <5751B06A.4080501@mail1.stofanet.dk> <83016a47-e902-4292-b109-652e811d17fb@isocpp.org> <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 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-86D056F0-B3B8-4F9C-9D24-B9CDB86B9045 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1465562263 25879 80.91.229.3 (10 Jun 2016 12:37:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jun 2016 12:37:43 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCS7TY6DTQOBBBPJ5K5AKGQE372OP6Y@isocpp.org Fri Jun 10 14:37:28 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f200.google.com ([209.85.213.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bBLgk-0008EF-LX for gclcip-std-proposals@m.gmane.org; Fri, 10 Jun 2016 14:37:26 +0200 Original-Received: by mail-ig0-f200.google.com with SMTP id 2sf94052260igy.1 for ; Fri, 10 Jun 2016 05:37:26 -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=D1w4w52t5w0q4SsfrhJqv/uckaOwRH+xgBYuXhiGkug=; b=JSH6BcyZMj6q2lnYBhSWRnLYwXANveZpehQjM/mkYCcLxAvFgxPaAPzaidBA8J74U0 ORuEEH8ksFH1rRM9rf6p6QTpiUgHkvE11D8pDmAYNKjQ+OfTcbD+cs6su+gSfvRW8tP6 UaQ4vLnkxUKcA5QcP4KNoJy09/XK6n7CfsjrJD61pzFC/yrk0UDYzpugTG8UpjJwOkgh yzK6uWSxpUF/g7UmlAbVE4vCsJWiKUb0Gd3TqPVweWUWc/JWv9xr3d6+jVOXichnx/Px Wd4yZlDbC/hHCMuWhByKm8dQoQF/bLNIgmSwgg6ujhooNmHHSa2K5daTBVrc1vjsC9JM dCfQ== 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=D1w4w52t5w0q4SsfrhJqv/uckaOwRH+xgBYuXhiGkug=; b=DxblyyjXZmK8/3hp/LLRSVkAS/BS43y/RKiEHu3OOJ+U44dMNG/ZRAFRR6suaf8WHX hjcdo4aEgxmkzLnRPCoFbTkFDiexTXafSkW1mbvm0wjrfCg9ODdk9m+QiCJCCLqVlLki YivZPL1TcF09DAxzBSzeEE80OuKG4X8lsDKV3QUmiA3NP6rvZU/kQmqxHSBlmoOyjbi5 ng8sIx65sUDHDWqm6LQyRkTibHuMxHmhRpt9Dbk7Q6Yf9+J0C3Tioxw8bXa80kpOH/ps ZX/N7L/u5/BxX0tj9+JeLrG6qR+VqVEvrfQmKRmuS57mlvN8CiuoNVdzuIE8TvdLS8AR OFG X-Gm-Message-State: ALyK8tJziXdphOZI983o3WMosk42Br7JPgDfjFlwMOhy6EoPlKjLxXl6Y3lYQrCzns1Zag== X-Received: by 10.157.13.11 with SMTP id 11mr1166557oti.24.1465562245833; Fri, 10 Jun 2016 05:37:25 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.44.215 with SMTP id s206ls101104ios.71.gmail; Fri, 10 Jun 2016 05:37:25 -0700 (PDT) X-Received: by 10.36.48.138 with SMTP id q132mr31079703itq.82.1465562245004; Fri, 10 Jun 2016 05:37:25 -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 j197si12302777ioj.92.2016.06.10.05.37.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jun 2016 05:37:24 -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 5so64242408ioy.1 for ; Fri, 10 Jun 2016 05:37:24 -0700 (PDT) X-Received: by 10.107.151.195 with SMTP id z186mr3438562iod.191.1465562244793; Fri, 10 Jun 2016 05:37:24 -0700 (PDT) Original-Received: from [10.194.86.160] ([166.170.220.135]) by smtp.gmail.com with ESMTPSA id 63sm291198ioj.41.2016.06.10.05.37.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 05:37:22 -0700 (PDT) X-Mailer: iPhone Mail (13F69) In-Reply-To: <485D94E9-3386-4C2E-8C90-2AE821C3B7E6@gmail.com> 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:26241 Archived-At: --Apple-Mail-86D056F0-B3B8-4F9C-9D24-B9CDB86B9045 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Or at least store a time point each time the stream is started using a cloc= k 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 t= ime within the stream. > On Jun 10, 2016, at 7:24 AM, alexander.zywicki@gmail.com wrote: >=20 > I lie your thought on the clock idea and +1 for the example. A few though= ts 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 a= rbitrary 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 pr= ogram... 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 t= hat as a reference point would allow you to manage the local time within th= at stream easily.=20 >=20 > As a second note the sample rate will most likely need to be a runtime pa= rameter and cannot be a template parameter because of such( unless we speci= fy the need for a factory to create clocks of different sample rates) we wi= ll probably not know the desired sample rate or even the supported sampling= rates at compile time >=20 >> 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-p= oint >> > 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 sampl= es) >> > /* >> > -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 ti= me >> > 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 stre= ams, 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 = world clock, at least not in audio processing domain. In video/image proces= sing this could be useful, e.g. to present an image to the user at the give= n time. However, I feel it would still be useful to allow specifying a cust= om clock to the audio processing framework as well. >> =20 >> One use case I have in mind is providing a custom clock which is guarant= eed to be equivalent to CLOCK_MONOTONIC on POSIX systems. Unlike std::chron= o::steady_clock, this custom clock would be useful in interfacing with OS p= rimitives 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 implement= s the usual clock interface, but provides time points in sample rate units.= The actual time readings would be obtained from an underlying clock. Somet= hing 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 = audio processing at all... >> =20 >> --=20 >> You received this message because you are subscribed to a topic in the G= oogle 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-= 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/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/31D8D875-9842-4CC4-98C6-F75FD20155DE%40gmail.com= .. --Apple-Mail-86D056F0-B3B8-4F9C-9D24-B9CDB86B9045 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Or at least store a tim= e point each time the stream is started using a clock with a well defined e= poch, so that we might be able to find the length of time that the stream h= as been active and have meaningful measurements of time within the stream.<= /div>

On Jun 10, 2016, at 7:24 AM, alexander.zywicki@gmail.com wrote:

I lie your thought on the clock idea a= nd +1 for the example. A few thoughts though, I would like to explain the d= istinction that I draw between an "arbitrary epoch" and a "dynamic epoch" a= s 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 term= s of the current instance of the program... It would be reset to the time w= hen 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 need to be a run= time parameter and cannot be a template parameter because of such( unless w= e 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 s= ampling rates at compile time

On Jun 10, 2016, at 5:34 AM, An= drey Semashev <andrey.semas= hev@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/31D8D875-9842-4CC4-98C6-F75FD20155DE%= 40gmail.com.
--Apple-Mail-86D056F0-B3B8-4F9C-9D24-B9CDB86B9045-- .