220 26242 <0F247BF9-8538-4D08-8975-386F059F9662@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:46:00 -0500 Lines: 95 Approved: news@gmane.org Message-ID: <0F247BF9-8538-4D08-8975-386F059F9662@gmail.com> References: <5751B06A.4080501@mail1.stofanet.dk> <5290948.va25uYNizX@tjmaciei-mobl1> <1580229.cHEgQxCuA1@tjmaciei-mobl1> <62b7649a-5de5-4330-9bac-708375d36e2c@isocpp.org> <3c0fde91-671d-4751-955d-7b04cfa120bc@isocpp.org> <4922d8b8-7909-44a2-a24f-8dcf4090911f@isocpp.org> <83016a47-e902-4292-b109-652e811d17fb@isocpp.org> <53eaa67d-eec5-4ee1-bea2-848394b4f069@isocpp.org> 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-6E78E1F5-1293-4B8B-B9FA-C792DDBEC784 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1465562863 3138 80.91.229.3 (10 Jun 2016 12:47:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jun 2016 12:47:43 +0000 (UTC) Cc: ISO C++ Standard - Future Proposals To: ross.bencina@gmail.com Original-X-From: std-proposals+bncBCS7TY6DTQOBBDHN5K5AKGQECX7VYLA@isocpp.org Fri Jun 10 14:47:39 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt0-f200.google.com ([209.85.216.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bBLp7-0006wv-IO for gclcip-std-proposals@m.gmane.org; Fri, 10 Jun 2016 14:46:05 +0200 Original-Received: by mail-qt0-f200.google.com with SMTP id i44sf50642285qte.3 for ; Fri, 10 Jun 2016 05:46:05 -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:cc :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=L/tLZQ1wxqloZgIuxtkrGCPXz5cGvRi7+d7GGU6MMAk=; b=z/mVp/sf0bDWg6yQ4VzokrDuFRc7fJ/NoIsBnt1RWvqjZ9e7Ggv/eU8tDUwiPOkkn/ BVhaxrNMICXE8D05Kk9RkIknfJNiosmOy74dVUok3M1KNDRSVh09EYXOuZkjaW21+xUD MpSEzEimuYbaVmKVk6dEQcW1kmepR4u+G6rJFmVwDuDjzjTzFMScgVUHJsPFLstsdo9z d2dVLpWf37DchdxI2d290vfp06OMZXE0ZU32OY1mWJIux5oB5IwWc1W42s0kB8kDgtp4 gLZmEulNBWonxxLfo8X1/PbISQE6pCWa3ENLdiSfgBSWFTNf/d6dPvzRBlkT77hnZJ/V Rw1g 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:cc :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=L/tLZQ1wxqloZgIuxtkrGCPXz5cGvRi7+d7GGU6MMAk=; b=mZXA1JECn4v9lXIDRn2MLdPYXhtKpzXR+w5GKD7tqT+f/wvDUAw80EQGUTJWblsgyu Uu/fmHYnN+gRRzFieuD1V1FLrKplrkp9eheSXgrFC2P6OHuww5cAiYlHcXtHJGbqYkFH JqUgCa8JjP3cGyCN0p3ZxI+UfwPgvhvrX5eaLQArdTdse32JE8nxKGDNTovAMhr1FJS8 XudeYp61jgZfnpOZYvTN5DGn05Qnv+yAaXLtf5fXX2KnnLrqWnvjlVudJErOXi4CUKDd RtMIRgFl3zwLpvuDGQtO0Oj7o4DcZbivVprBarjTXRVctlPQaGbPks3eTSzBJZkW9J7w X-Gm-Message-State: ALyK8tLg+dB6QfRw1RnPTdbMyf5OuBLNlacBgbHquSx+NP9bClObp5J7wmlDQEN2oxc/lA== X-Received: by 10.176.1.73 with SMTP id 67mr1153636uak.8.1465562764760; Fri, 10 Jun 2016 05:46:04 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.159.83 with SMTP id i80ls580220ioe.75.gmail; Fri, 10 Jun 2016 05:46:03 -0700 (PDT) X-Received: by 10.107.8.220 with SMTP id h89mr3594229ioi.95.1465562763840; Fri, 10 Jun 2016 05:46:03 -0700 (PDT) Original-Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com. [2607:f8b0:4001:c06::22a]) by mx.google.com with ESMTPS id m138si12353221ioe.8.2016.06.10.05.46.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jun 2016 05:46:03 -0700 (PDT) Received-SPF: pass (google.com: domain of alexander.zywicki@gmail.com designates 2607:f8b0:4001:c06::22a as permitted sender) client-ip=2607:f8b0:4001:c06::22a; Original-Received: by mail-io0-x22a.google.com with SMTP id 5so64427688ioy.1 for ; Fri, 10 Jun 2016 05:46:03 -0700 (PDT) X-Received: by 10.107.132.144 with SMTP id o16mr3513487ioi.37.1465562763660; Fri, 10 Jun 2016 05:46:03 -0700 (PDT) Original-Received: from [10.194.86.160] ([166.170.220.135]) by smtp.gmail.com with ESMTPSA id j37sm5483943iod.4.2016.06.10.05.46.02 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 05:46:02 -0700 (PDT) X-Mailer: iPhone Mail (13F69) In-Reply-To: <53eaa67d-eec5-4ee1-bea2-848394b4f069@isocpp.org> 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::22a 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:26242 Archived-At: --Apple-Mail-6E78E1F5-1293-4B8B-B9FA-C792DDBEC784 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I see know what you mean. Do the IO "driver" would take time stamps at the start and finish of each b= uffer and calculate the actual operating sample rate of each clock domain? = That information would also be of use for latency calculation because we c= ould predict when the next buffer should come and then determine when it do= es and note the difference? > On Jun 10, 2016, at 3:06 AM, ross.bencina@gmail.com wrote: >=20 > > Do you have any suggestions as far as an explicit notion of time should= be in this context? >=20 > It needs to be a monotonic system clock. >=20 > And you need to be able to correlate it with your i/o buffers. >=20 > But you can not assume (as I think you have) that i/o buffers represent a= contiguous stream of samples, because there can be dropped buffers, and yo= u need to represent this. (btw. this is another example of how real-time au= dio is not like an iostream). >=20 > Something I forgot earlier: each DAC or ADC may be running in a different= clock domain. The CPU time is usually another clock domain. So you have mu= ltiple drifting clocks. One consequence of this is that you can't make simp= lifying assumptions that e.g. 44100 samples elapsed is exactly 1 second of = system monotonic time. That's why you need timestamps associated with the b= uffers, so that the client can estimate the actual sample rate. >=20 >=20 --=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/0F247BF9-8538-4D08-8975-386F059F9662%40gmail.com= .. --Apple-Mail-6E78E1F5-1293-4B8B-B9FA-C792DDBEC784 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see know what you mea= n.

Do the IO "driver" would take time stamps at th= e start and finish of each buffer and calculate the actual operating sample= rate of each clock domain? That information would also be of use for  = ;latency calculation because we could predict when the next buffer should c= ome and then determine when it does and note the difference?

= On Jun 10, 2016, at 3:06 AM, ross= ..bencina@gmail.com wrote:

<= div dir=3D"ltr">> Do you= have any suggestions as far as an explicit notion of time should be in thi= s context?

It needs to be a mon= otonic system clock.

And you need to be abl= e to correlate it with your i/o buffers.

But you c= an not assume (as I think you have) that i/o buffers represent a contiguous= stream of samples, because there can be dropped buffers, and you need to r= epresent this. (btw. this is another example of how real-time audio is not = like an iostream).

Something I forgot earlier: eac= h DAC or ADC may be running in a different clock domain. The CPU time is us= ually another clock domain. So you have multiple drifting clocks. One conse= quence of this is that you can't make simplifying assumptions that e.g. 441= 00 samples elapsed is exactly 1 second of system monotonic time. That's why= you need timestamps associated with the buffers, so that the client can es= timate the actual sample rate.


--
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/0F247BF9-8538-4D08-8975-386F059F9662%= 40gmail.com.
--Apple-Mail-6E78E1F5-1293-4B8B-B9FA-C792DDBEC784-- .