220 26236 <2271827.u9FbM9WbyY@lastique-pc> article Path: news.gmane.org!not-for-mail From: Andrey Semashev Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Any interest to adding audio support to the std library? Date: Fri, 10 Jun 2016 13:34:47 +0300 Lines: 276 Approved: news@gmane.org Message-ID: <2271827.u9FbM9WbyY@lastique-pc> References: <5751B06A.4080501@mail1.stofanet.dk> <83016a47-e902-4292-b109-652e811d17fb@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart1550987.RFIYz09MSS" Content-Transfer-Encoding: 7Bit X-Trace: ger.gmane.org 1465554899 5721 80.91.229.3 (10 Jun 2016 10:34:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jun 2016 10:34:59 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCXY5TXHWYJRBS5P5K5AKGQEKUMFYVQ@isocpp.org Fri Jun 10 12:34:52 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f69.google.com ([209.85.215.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bBJm8-0002oq-Mk for gclcip-std-proposals@m.gmane.org; Fri, 10 Jun 2016 12:34:52 +0200 Original-Received: by mail-lf0-f69.google.com with SMTP id k192sf28832623lfb.1 for ; Fri, 10 Jun 2016 03:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:user-agent:in-reply-to:references :mime-version:content-transfer-encoding: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=VYv6QnodDuIA2atZB+S/j113B1bMz6oriYizvPdQq9o=; b=eOg3oD2pOnOgwtuGS4KCqtbR8/YRJgeKNJoavqk6Me5o1uz43LrM8J1OLKoLmzLPXx mQwHARN65TKJj4VN34PiY5r9UbHY4JEu7lOENaZagFDThtSRqUZjv8XaX4PfIpwiKmHr joJNxox58ClMNpPraNqVk48yqmZEzI7y8gGAwcxCf+IffQ+srk2Q+0nDn+hjVVGuQ6a1 PG2U1lvuop2XjTHZ9RyE/RPeGdoFxE5qthWr4wkwgL7VIGn05KvKwMQfotvJNfFjG7qS SNRthv8CXMUY5VQ5eXx7Hgrm6iZhLmLyykainFyAOYaitQxNbomHI15WxJaOk7sFgc+I X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :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=VYv6QnodDuIA2atZB+S/j113B1bMz6oriYizvPdQq9o=; b=KirsHPkTpVRdHa57c3GmV7rZLBooWAGRM4WHJPa6y73yXByvASj8vXq0Wpiz5MPYY5 HC7oWd69AcEv4lXdCh+Pn2GlOjPqN54tm70oA0rzkbozMw5V1riDAnuGysajLCXT/bsL DsqnzFU+HPk32UguNsfMnormZkuT+w3hXXhj8eHn9zxGiBVfIZy4QIOGEE6jbz46u4gT aXWxIKgDB8hDrWS1BCgXPclxAUMFXp8O/YxlMBem6BpLdzBe7Kycq2M/+ez1UxUmTl+9 KwX5zwPPJcgKSNJ4pK39JGs0bjubsqkBTX0Dmza+lVGx3a69sjcHMUt1ogPw7D8Ss9vQ X-Gm-Message-State: ALyK8tK1SVgmZ3JdHBHhyclPP6JBZX+ryEYyhDfEZT624X6bFDqFgcIteBsHUMS6t8Uu5Q== X-Received: by 10.28.96.7 with SMTP id u7mr2946176wmb.6.1465554892116; Fri, 10 Jun 2016 03:34:52 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.46.1.83 with SMTP id 80ls111546ljb.21.gmail; Fri, 10 Jun 2016 03:34:50 -0700 (PDT) X-Received: by 10.25.38.73 with SMTP id m70mr431645lfm.107.1465554890651; Fri, 10 Jun 2016 03:34:50 -0700 (PDT) Original-Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com. [2a00:1450:4010:c07::22b]) by mx.google.com with ESMTPS id a80si6572141lfb.89.2016.06.10.03.34.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jun 2016 03:34:50 -0700 (PDT) Received-SPF: pass (google.com: domain of andrey.semashev@gmail.com designates 2a00:1450:4010:c07::22b as permitted sender) client-ip=2a00:1450:4010:c07::22b; Original-Received: by mail-lf0-x22b.google.com with SMTP id j7so19596785lfg.1 for ; Fri, 10 Jun 2016 03:34:50 -0700 (PDT) X-Received: by 10.25.32.2 with SMTP id g2mr450277lfg.188.1465554890143; Fri, 10 Jun 2016 03:34:50 -0700 (PDT) Original-Received: from lastique-pc.localnet (broadband-90-154-68-136.nationalcablenetworks.ru. [90.154.68.136]) by smtp.googlemail.com with ESMTPSA id g16sm879373lji.44.2016.06.10.03.34.48 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 10 Jun 2016 03:34:48 -0700 (PDT) User-Agent: KMail/5.1.3 (Linux/4.4.0-24-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <83016a47-e902-4292-b109-652e811d17fb@isocpp.org> X-Original-Sender: andrey.semashev@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of andrey.semashev@gmail.com designates 2a00:1450:4010:c07::22b as permitted sender) smtp.mailfrom=andrey.semashev@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:26236 Archived-At: This is a multi-part message in MIME format. --nextPart1550987.RFIYz09MSS Content-Type: text/plain; charset=UTF-8 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-point > 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 samples) > /* > -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 time > since epoch in seconds +1 for using chrono. +1 for monotonic clock (as Ross suggested). At least, by default. -1 for using an arbitrary epoch clock. In my practice 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. 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 processing 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 custom clock to the audio processing framework as well. One use case I have in mind is providing a custom clock which is guaranteed to be equivalent to CLOCK_MONOTONIC on POSIX systems. Unlike std::chrono::steady_clock, this custom clock would be useful in interfacing with OS primitives like condition variables or events. Having such clock time points in audio frames would be useful. 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. Something like this: template< typename BaseClock, unsigned int SampleRate > class sample_rate_clock { public: typedef BaseClock base_clock; static constexpr unsigned int sample_rate = 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 static time_point now() { return time_point(duration_cast< duration >( base_clock::now().time_since_epoch())); } }; Or, on the second thought, this might be a generic tool, not related to audio processing at all... -- 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/2271827.u9FbM9WbyY%40lastique-pc. --nextPart1550987.RFIYz09MSS Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

On Friday, = 10 June 2016 13:11:14 MSK alexander.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 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/2271827.u9FbM9WbyY%40lastique-pc.
--nextPart1550987.RFIYz09MSS-- .