220 26171 <239cb9ab-c5d5-4ce5-b876-b5220cc1e116@isocpp.org> article Path: news.gmane.org!not-for-mail From: Ron Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Any interest to adding audio support to the std library? Date: Fri, 3 Jun 2016 23:28:01 -0700 (PDT) Lines: 174 Approved: news@gmane.org Message-ID: <239cb9ab-c5d5-4ce5-b876-b5220cc1e116@isocpp.org> References: <5751B06A.4080501@mail1.stofanet.dk> <5290948.va25uYNizX@tjmaciei-mobl1> <1580229.cHEgQxCuA1@tjmaciei-mobl1> <62b7649a-5de5-4330-9bac-708375d36e2c@isocpp.org> <4cfc7939-1ebf-415f-8ef4-d51e7cdadef5@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1117_268347005.1465021681318" X-Trace: ger.gmane.org 1465021685 7702 80.91.229.3 (4 Jun 2016 06:28:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Jun 2016 06:28:05 +0000 (UTC) Cc: alexander.zywicki@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDO2TPGE4QNBB4XJZG5AKGQETD2MVNY@isocpp.org Sat Jun 04 08:28:05 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f71.google.com ([209.85.214.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1b9540-0003jX-6a for gclcip-std-proposals@m.gmane.org; Sat, 04 Jun 2016 08:28:04 +0200 Original-Received: by mail-it0-f71.google.com with SMTP id f67sf480912ith.2 for ; Fri, 03 Jun 2016 23:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=oydZDWQOpUN29ti3jn83Q/fWJCnA2WBmZG/HVAsSee8=; b=d7TLoydBrxRd09yDR8mmpewg0RedKOucOu4yZJkOsiuYDzYILlcsLRlC67XogSAoFx qd4ni32SgF9jlFKWqoBEkWgyvzqBDpdnzz8S+CCOCsmv5Kzl5eqEy3axLlwYpQet0VYe XUZwCIFL5Ys/fBeke4aNxZtCNazeSTzBtFthqAp4UYmCTuWwaotQo1iG5esoodVCl+NM Jjm1bJS8MGM1G2FGoXYUJn+jKUTxhPJcvN412yw2y8+bfiX+RjmZxGVFHzXVazXnH27B PQsPNed9qGPFhiwksIT/IRRu6Gt+3WNWLNmEPuEt8qT0q8luU/NmpyyYxyzHmsam590c XbNg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=oydZDWQOpUN29ti3jn83Q/fWJCnA2WBmZG/HVAsSee8=; b=ZvLI2M4vtpxdxTAnrl7YCny29FacfVMtXS5Eoa4V9RcFQfIaUErZHbKLvw4Aac8GZQ aY4OMdv5mUJ4NmlsSlG56im5j96CtFOkB0P3EJ9NSYEiAhr9ao0czr2fgQKg71i8w+MT mt3WdLIjY1WxMlcxgatLFfhgvsm2DhHiF/HPpoCaKxfTusf7nlh/gQjnXJ/pf1goG8Xa ExPzJfxCxZRPl1kvFxSuGA9E0/jUsq4VaBf65DrYXmEW1NzEU0yxjAGP9xlZ6kn8cCKv MfcsN3PsM8bxBwUXRWjXAPemjSlxpflMdb1XnQ0TOLuZb6lddmyjyH92EJujTW6S2Jlz 9sjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=oydZDWQOpUN29ti3jn83Q/fWJCnA2WBmZG/HVAsSee8=; b=D4ooh4pPDBzZrLNvgUYwgt4EEkvgA3P5+YepKPU+THorRl/SHtO7yhJQ3nImqGvkk6 fHBgXayt46Tmo62hwJHINlCTiqvkxhC/OIXwMCbv7cxPhpEt7k9VwC77+WA0j5Gg4k3m iGm6ynEWO6NidQTWrTKxoSW+Oo+TnXIz5W+KhqYHY9OMoEmVTeKeEf6i06hwUF7qNWCr cPo0sUff1jrB4bDXxavLA9/NNeoLu4gtnV4uvGYHrGMawPWx6ioFbfCgzEo+EcItbZW5 22/o6XTMf+eUHFkjPWYaF+eq3Z/0/aRI2XwXfkCZY/eKIopjFDUA7CZYAg1WP1jnjD0Z b1gg== X-Gm-Message-State: ALyK8tJuo73IEN0Y8NUT8Fqwi/ihIB//TW5DVD5B75n+DgxQ6GUfm+bzAmn3FDFXpNhs1g== X-Received: by 10.157.33.27 with SMTP id i27mr5413500otb.11.1465021683050; Fri, 03 Jun 2016 23:28:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.22.70 with SMTP id 67ls571225iow.5.gmail; Fri, 03 Jun 2016 23:28:02 -0700 (PDT) X-Received: by 10.36.36.205 with SMTP id f196mr98220ita.2.1465021682152; Fri, 03 Jun 2016 23:28:02 -0700 (PDT) In-Reply-To: <4cfc7939-1ebf-415f-8ef4-d51e7cdadef5@isocpp.org> X-Original-Sender: rsn10100@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:26171 Archived-At: ------=_Part_1117_268347005.1465021681318 Content-Type: multipart/alternative; boundary="----=_Part_1118_423277400.1465021681318" ------=_Part_1118_423277400.1465021681318 Content-Type: text/plain; charset=UTF-8 Some thoughts... 'N' should be runtime for channels in a frame and for a frame buffer. The buffer size might be negotiable with the device. I like a lot of that code in the original post, but I don't like the comparison to iostreams. Its really the '>>' operator that I don't like. When you copy into your frame buffer, an '=' operator should be used since anyone that sees an '=' operator knows its a copy. But really, you shouldn't need to move data around so much. If you stream from input to 'buff', then process and then move from 'buff' to output then you are moving a lot of data unnecessarily. I think what should happen is this; The process chain is triggered when the output signals it is ready for data by calling the first linked process. Starting at the output, each process kernel calls the previous until it reaches the input where the input device/file/etc copies the data to the chains frame buffer. Each process then operates on that single buffer in turn until finally returning to the output, thus altering the buffer instead of moving data from place to place. I like to think of the processing chain as starting from the output or destination. When the output is ready for data it calls to a linked process for information, it calls to the next link and so on until data begins to get processed. So a bottom up approach, where the input doesn't officially start until the output is ready. I know it is opposite of the way audio really flows through a system but it makes things easier then moving data like a bucket brigade. It can also allow easier parallel processing when there are multiple branches on a node. So if you think of an audio mixer, where there are many inputs and a single output, the output calls to many channels/nodes at once so they can all be processed in parallel and mixed together after each of the processes end. Also, I'm not sure the word 'format' should be used to refer to files. I know people like to say "file format" but then, what format is the audio data in that is in the file format? Its just confusing, so I think 'container' is a better word for files. Then that leaves the word format open for use as a way of describing the data format of an audio frame buffer. So an audio_format class would contain information on sample rate, channels, interleaving, channel routing and other information and a container class would deal with files. I personally would rather have all audio with greater than 2 or 3 channels processed in Ambisonic-B format and then have the audio driver figure out how to extract the channels for each speaker, but I know this won't fly with everyone so we would need a class for channel routing information as well. All I can think of at the moment.. On Friday, June 3, 2016 at 9:08:45 PM UTC-7, alexande...@gmail.com wrote: > > I agree, how do you feel about the concept i proposed in my original about > having std audio stream classes similar to std::fstream. The > std::astream/iastream/oastream would represent the default audio device on > the system as determined by some method of polling the system. The user > could either choose to use them as is or manually select a different device? > > On Friday, June 3, 2016 at 10:51:12 PM UTC-5, Ron wrote: >> >> Well, it needs to start somewhere. I think having basic buffers using >> std::array or plain old arrays might do for now and get some basic audio >> recording and playback into C++. It should be as simple as possible to get >> to the interfaces on the machine and make them work. The data processing >> can build onto it with more complex primitives, templates and classes. >> This way there is at least something semi-usable with code we have today >> while the rest of the building blocks are being worked on. Just a thought >> though. >> >> >> >> -- 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/239cb9ab-c5d5-4ce5-b876-b5220cc1e116%40isocpp.org. ------=_Part_1118_423277400.1465021681318 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some thoughts...

'N'= should be runtime for channels in a frame and for a frame buffer. =C2=A0Th= e buffer size might be negotiable with the device.

I like a lot of that code in the original post, but I don't like the c= omparison to iostreams. =C2=A0Its really the '>>' operator th= at I don't like. =C2=A0When you copy into your frame buffer, an '= =3D' operator should be used since anyone that sees an '=3D' op= erator knows its a copy. =C2=A0But really, you shouldn't need to move d= ata around so much. =C2=A0If you stream from input to 'buff', then = process and then move from 'buff' to output then you are moving a l= ot of data unnecessarily.

I think what should happ= en is this; The process chain is triggered when the output signals it is re= ady for data by calling the first linked process. =C2=A0Starting at the out= put, each process kernel calls the previous until it reaches the input wher= e the input device/file/etc copies the data to the chains frame buffer. =C2= =A0Each process then operates on that single buffer in turn until finally r= eturning to the output, thus altering the buffer instead of moving data fro= m place to place. =C2=A0I like to think of the processing chain as starting= from the output or destination. =C2=A0When the output is ready for data it= calls to a linked process for information, it calls to the next link and s= o on until data begins to get processed. =C2=A0So a bottom up approach, whe= re the input doesn't officially start until the output is ready. =C2=A0= I know it is opposite of the way audio really flows through a system but it= makes things easier then moving data like a bucket brigade. =C2=A0It can a= lso allow easier parallel processing when there are multiple branches on a = node. =C2=A0So if you think of an audio mixer, where there are many inputs = and a single output, the output calls to many channels/nodes at once so the= y can all be processed in parallel and mixed together after each of the pro= cesses end.

Also, I'm not sure the word &= #39;format' should be used to refer to files. =C2=A0I know people like = to say "file format" but then, what format is the audio data in t= hat is in the file format? =C2=A0Its just confusing, so I think 'contai= ner' is a better word for files. =C2=A0Then that leaves the word format= open for use as a way of describing the data format of an audio frame buff= er. =C2=A0So an audio_format class would contain information on sample rate= , channels, interleaving, channel routing and other information and a conta= iner class would deal with files.

I personal= ly would rather have all audio with greater than 2 or 3 channels processed = in Ambisonic-B format and then have the audio driver figure out how to extr= act the channels for each speaker, but I know this won't fly with every= one so we would need a class for channel routing information as well.
=

All I can think of at the moment..

=


On Friday, June 3, 2016 at 9:08:45 PM UTC-7, a= lexande...@gmail.com wrote:
I agree, how do you feel about the concept i proposed in my o= riginal about having std audio stream classes similar to std::fstream. The = std::astream/iastream/oastream would represent the default audio device on = the system as determined by some method of polling the system. The user cou= ld either choose to use them as is or manually select a different device?
On Friday, June 3, 2016 at 10:51:12 PM UTC-5, Ron wrote:
Well, it needs to start somewhe= re.=C2=A0 I think having basic buffers using std::array or plain old arrays= might do for now and get some basic audio recording and playback into C++.= =C2=A0 It should be as simple as possible to get to the interfaces on the m= achine and make them work.=C2=A0 The data processing can build onto it with= more complex primitives, templates and classes.=C2=A0 This way there is at= least something semi-usable with code we have today while the rest of the = building blocks are being worked on.=C2=A0 Just a thought though.

<= /div>


--
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/239cb9ab-c5d5-4ce5-b876-b5220cc1e116= %40isocpp.org.
------=_Part_1118_423277400.1465021681318-- ------=_Part_1117_268347005.1465021681318-- .