220 26177 <134e61f0-6011-47e6-a09f-c03bfecf7303@isocpp.org> 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: Sat, 4 Jun 2016 07:38:53 -0700 (PDT) Lines: 313 Approved: news@gmane.org Message-ID: <134e61f0-6011-47e6-a09f-c03bfecf7303@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> <239cb9ab-c5d5-4ce5-b876-b5220cc1e116@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2907_1713158781.1465051133879" X-Trace: ger.gmane.org 1465051139 28951 80.91.229.3 (4 Jun 2016 14:38:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Jun 2016 14:38:59 +0000 (UTC) Cc: alexander.zywicki@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCS7TY6DTQOBB76PZO5AKGQESZVZZFQ@isocpp.org Sat Jun 04 16:38:59 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f197.google.com ([209.85.161.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1b9Cj2-0006pC-RC for gclcip-std-proposals@m.gmane.org; Sat, 04 Jun 2016 16:38:57 +0200 Original-Received: by mail-yw0-f197.google.com with SMTP id c127sf290385298ywb.1 for ; Sat, 04 Jun 2016 07:38:56 -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=hoHbFieMZzLGBd2kEgJkuIIReGjbSNYmyuUBGpQpOiU=; b=OrpBXsh4l6bjc97W6Re5wEDcAFyz3kEMo0zRPeo2NZGmcPkyIwNBNXamhth2QSKQu/ MWOz3SH5TCDSaQRGl/ztymPsTq+vltvdyxXRmVl9WolESSOhT47ic2PhacqyXREXuUaq DEiDx8zw6sqV8kN767/b2rZPCqW43tj4UiQXZ2rISarEnIiqsAC5qJjgMsrIyMf0A1vD zS8xw5JodeojMrkS0KHe4cOmh84sdelJx3kMk7RWUk63pp4fQ8PPA7Z6q1jJ9Uge5rnC Xk1W0ca8HKR0mYDVOFOAEU3FahOAT55oRjtRt75KyN/OP+VbXE+lhibvOLHBzIGiXoIl YRsQ== 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=hoHbFieMZzLGBd2kEgJkuIIReGjbSNYmyuUBGpQpOiU=; b=jOrpVx96YGh8LIjcRcJnd7/26JAW+lEX4AmwAZPxJyphwXW2x4M22y4lf14xywNd95 MmxCJzpxM6GF4+tSCDcB6cL5dC7XHDVY0RpF0kw4D6hstND77WPjfXRDF82GR6Iaz5Vt pgtCZCS2VzeupdFVgtX3NoiJienue5d6Qe83ySPZyDolwGTaEh7d4k7fbZEfUM7a6IWm upUvaWMcR6xl7cvtMg8OCJb7y8rdlSsrmKiks0L3dqFPpbu/70h2Y+nE904RaKTwtbi6 fYaaU9OwGnJgGhbZAVniiKt8aLpS4XFI6HROMDY780gkmR5xzzrJ1PPtWlAW7/IpqPvT 1Uiw== 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=hoHbFieMZzLGBd2kEgJkuIIReGjbSNYmyuUBGpQpOiU=; b=A30XeMBwjSyGD359CJrVKDbziopPHwGvLo+H7KN4Nl9MYbcGFnN9gpb9btTZeF2qNm DLX58TIYo4+jvTuj9KIjmok7jJEM1ZP7tYY/Lz32mVEohw4Of6R+yde1Z3StkGgfoMfR JzyO/RNooiDySvzr0p88hxDYKHlthMSQiDW79N+XeIG5KcAkOGsAg91hxp/UVJgqd8zy LP6mRk/vMnDnC3hGDkMO2ijl8LRVGRM4xWsfigz1/I8xfRMMtyCqRGwsOFlQ1LuvfMSN /fmeMYmXrdjoLtiGqj8IDuPAgCJ51+bnuCcfdH0mfEpMn/qsuQW4b0vxZk2TKRWsb6G3 oIZg== X-Gm-Message-State: ALyK8tIvXQHjZPxZOlI/6MS3rfbaCzEVPqBGrRlfwc2iVy4bnZRYYzyDxsGMJAEorB4X5w== X-Received: by 10.140.88.230 with SMTP id t93mr6502341qgd.22.1465051135830; Sat, 04 Jun 2016 07:38:55 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.199.67 with SMTP id x64ls371267iof.90.gmail; Sat, 04 Jun 2016 07:38:54 -0700 (PDT) X-Received: by 10.36.196.5 with SMTP id v5mr127211itf.4.1465051134784; Sat, 04 Jun 2016 07:38:54 -0700 (PDT) In-Reply-To: <239cb9ab-c5d5-4ce5-b876-b5220cc1e116@isocpp.org> X-Original-Sender: alexander.zywicki@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:26177 Archived-At: ------=_Part_2907_1713158781.1465051133879 Content-Type: multipart/alternative; boundary="----=_Part_2908_1987009820.1465051133880" ------=_Part_2908_1987009820.1465051133880 Content-Type: text/plain; charset=UTF-8 Is this example more agreeable? //std::audio example 1 "single process" void example_1(){ double sample_rate = 44100; std::size_t frame_size =2; std::size_t buffer_size=128; std::audio_context ctx{sample_rate,buffer_size,frame_size};//contruct from values std::astream_process proc(ctx,[](std::frame_buffer const& input, std::frame_buffer& output){ for(std::size_t i =0; i > 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/134e61f0-6011-47e6-a09f-c03bfecf7303%40isocpp.org. ------=_Part_2908_1987009820.1465051133880 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is this example more agreeable?

//std::audio example 1 "si= ngle process"
void exa= mple_1(){<= /span>
=C2=A0 = =C2=A0 dou= ble sample= _rate =3D<= /span> 44100;
=C2=A0 =C2=A0 std::size_t frame_size =3D2;
=C2=A0 =C2=A0 std::size_t buffer_size=3D128;

=C2=A0 =C2=A0 std::audio_context<float> ctx{sample_rate,buffer_size,f= rame_size}= ;//contruc= t from values

=C2=A0 =C2=A0 std::astream_process<float> proc(ctx,[]= (std::frame_buffer<float> const& input, std::frame_buffer<float>& output){<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 for(std::= size_t i <= /span>=3D<= span style=3D"color: #066;" class=3D"styled-by-prettify">0; i <input.size();++i){
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 output[i] =3D input[i] * 1.0;
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 }<= br>=C2=A0 =C2=A0 });=

=C2=A0 =C2=A0 proc.start();
= =C2=A0 =C2=A0 //do other stuff
=C2=A0 =C2=A0 proc.stop();
}



On Saturday, June 4, 2016 at 1:28:01 AM = UTC-5, Ron wrote:
Some thoughts...

'N' should be ru= ntime for channels in a frame and for a frame buffer. =C2=A0The 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. =C2=A0Its really the '>>' operator that I don'= t like. =C2=A0When you copy into your frame buffer, an '=3D' operat= or should be used since anyone that sees an '=3D' operator knows it= s a copy. =C2=A0But really, you shouldn't need to move data around so m= uch. =C2=A0If you stream from input to 'buff', then process and the= n move from 'buff' to output then you are moving a lot of data unne= cessarily.

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. =C2=A0Starting at the output, each proce= ss kernel calls the previous until it reaches the input where the input dev= ice/file/etc copies the data to the chains frame buffer. =C2=A0Each 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 plac= e. =C2=A0I like to think of the processing chain as starting from the outpu= t or destination. =C2=A0When the output is ready for data it calls to a lin= ked process for information, it calls to the next link and so on until data= begins to get processed. =C2=A0So a bottom up approach, where the input do= esn't officially start until the output is ready. =C2=A0I know it is op= posite of the way audio really flows through a system but it makes things e= asier then moving data like a bucket brigade. =C2=A0It can also allow easie= r 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 ou= tput, the output calls to many channels/nodes at once so they can all be pr= ocessed 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. =C2=A0I know people like to say "fi= le format" but then, what format is the audio data in that is in the f= ile format? =C2=A0Its just confusing, so I think 'container' is a b= etter word for files. =C2=A0Then that leaves the word format open for use a= s a way of describing the data format of an audio frame buffer. =C2=A0So an= audio_format class would contain information on sample rate, channels, int= erleaving, channel routing and other information and a container class woul= d 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 channel= s 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..


<= /div>

On Friday, June 3, 2016 at 9:08:45 PM UTC-7, alexande...@g= mail.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 cho= ose to use them as is or manually select a different device?

On Frid= ay, June 3, 2016 at 10:51:12 PM UTC-5, Ron wrote:
Well, it needs to start somewhere.=C2=A0 I t= hink 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 sho= uld be as simple as possible to get to the interfaces on the machine and ma= ke 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 someth= ing semi-usable with code we have today while the rest of the building bloc= ks are being worked on.=C2=A0 Just a thought though.



--
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/134e61f0-6011-47e6-a09f-c03bfecf7303= %40isocpp.org.
------=_Part_2908_1987009820.1465051133880-- ------=_Part_2907_1713158781.1465051133879-- .