220 26182 <20160604161527.4915281.1654.11659@gmail.com> article Path: news.gmane.org!not-for-mail From: Tony V E Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Any interest to adding audio support to the std library? Date: Sat, 04 Jun 2016 12:15:27 -0400 Lines: 303 Approved: news@gmane.org Message-ID: <20160604161527.4915281.1654.11659@gmail.com> References: <5751B06A.4080501@mail1.stofanet.dk> <62b7649a-5de5-4330-9bac-708375d36e2c@isocpp.org> <4cfc7939-1ebf-415f-8ef4-d51e7cdadef5@isocpp.org> <239cb9ab-c5d5-4ce5-b876-b5220cc1e116@isocpp.org> <134e61f0-6011-47e6-a09f-c03bfecf7303@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1465057106 18481 80.91.229.3 (4 Jun 2016 16:18:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Jun 2016 16:18:26 +0000 (UTC) Cc: alexander.zywicki@gmail.com To: "alexander.zywicki@gmail.com" , ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUZ5QWKNQIKF7OLXICRUBCY6QXVW@isocpp.org Sat Jun 04 18:18:19 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f198.google.com ([209.85.214.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1b9EEa-0003SG-QU for gclcip-std-proposals@m.gmane.org; Sat, 04 Jun 2016 18:15:37 +0200 Original-Received: by mail-ob0-f198.google.com with SMTP id y7sf10102000obt.0 for ; Sat, 04 Jun 2016 09:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to:cc: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=Xz4VF9jvI8P33Zo9S7Rd4X+X/DG3aBzXMafpH+IzKpw=; b=NLO8z2x9vmmGvREsBB8uuDjMPjf6ruhrPk6ELRcAUVEo4a3rGQTuScDDaabi0JGVgn yfaQ3FcBCidDC9p8NAPTGq0tCzNk4ratdGHhqvfsz4liCFsPEhAmtZXnA642UCMJvIrA MVDWXdS/qDjTvAoHiq3sGUnUGmw7ZTbbVQ4iAInTo9lBrIVBX0Q8BB9GBiCA/6452jVQ X1Tnypd3a18aPDQecwYzABUzD3+SlImRetvbaRutnMKMTWnjpCE6EV+ruDZB7iVNgryZ ddmpDJ2E1tfgPImPgBZH06XXBECFNvbrialS9T2EWaJLngq4wRWDkr9bsxmA9eQTrFdb qFrw X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to:cc :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=Xz4VF9jvI8P33Zo9S7Rd4X+X/DG3aBzXMafpH+IzKpw=; b=fv2UNV+Is+jTivizzkRWsbnNJYtkoYG2XE0N9i2W1G4/1cI8Kg0oPp8jZvW191LGG4 3lTn3kNuHgwtsZcdYOIiEjynMMeUXp6HX6BjDoHAzeKCY3PlV/f4ovktFqrkPr1cgrsw XAJqw5+CYy6U7iDIzEdtnSl/PQCNb1gOTXWALodyAgSVtnwfIJ8F0FtwCD5pw9NpXvIJ +EDdabi1o99xtjh87hoxEftvzbdiVgQ8QYWTF2KN4fr7v+pVlDyF8JI2zj686GwxoEBv ptoNLSZatQbuIN5rLmYfOp5CmbhOEK/vQ9kbOMXw3tC3yvBpT8nd4R8uEyR8Z1wKr0qI X-Gm-Message-State: ALyK8tKQ83+676Egt60c0NABr9HvC+GJTqgxzAbTP1WvxDj315+N1xargRuiqtM86lg/Tw== X-Received: by 10.157.43.17 with SMTP id o17mr1962810otb.36.1465056930853; Sat, 04 Jun 2016 09:15:30 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.139.6 with SMTP id n6ls632518iod.63.gmail; Sat, 04 Jun 2016 09:15:30 -0700 (PDT) X-Received: by 10.36.65.138 with SMTP id b10mr6648991itd.77.1465056929985; Sat, 04 Jun 2016 09:15:29 -0700 (PDT) Original-Received: from mail-io0-x236.google.com (mail-io0-x236.google.com. [2607:f8b0:4001:c06::236]) by mx.google.com with ESMTPS id d190si1996289iof.165.2016.06.04.09.15.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Jun 2016 09:15:29 -0700 (PDT) Received-SPF: pass (google.com: domain of tvaneerd@gmail.com designates 2607:f8b0:4001:c06::236 as permitted sender) client-ip=2607:f8b0:4001:c06::236; Original-Received: by mail-io0-x236.google.com with SMTP id o189so96943987ioe.2 for ; Sat, 04 Jun 2016 09:15:29 -0700 (PDT) X-Received: by 10.107.165.12 with SMTP id o12mr13748328ioe.56.1465056929746; Sat, 04 Jun 2016 09:15:29 -0700 (PDT) Original-Received: from [127.0.0.1] (GLPHON2233W-LP130-06-3096532220.dsl.bell.ca. [184.145.84.252]) by smtp.gmail.com with ESMTPSA id u27sm5100133iou.38.2016.06.04.09.15.27 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Jun 2016 09:15:28 -0700 (PDT) X-Mailer: BlackBerry Email (10.3.2.2876) In-Reply-To: X-Original-Sender: tvaneerd@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of tvaneerd@gmail.com designates 2607:f8b0:4001:c06::236 as permitted sender) smtp.mailfrom=tvaneerd@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:26182 Archived-At: =
But most of the time you don't want to copy the data. 

Whenever possible you want to process in place.
= =

= = =
Sent from = ;my BlackBerry portable Babbage Device
= = =
=
From:= alexander.zywicki@gmail.com
Sent: Saturday, June 4, 2= 016 10:41 AM
To: ISO C++ Standard - Future Proposals
=
Reply To: std-proposals@isocpp.org
Cc: alexand= er.zywicki@gmail.com
Subject: Re: [std-proposals] Any inte= rest to adding audio support to the std library?

Note that the input must be a const&= amp; because in  aparalell context it would allow multiple processes t= o read safely, this has the side effect of disabling the range for syntax u= nless you do this:

//std::audio example 1 "single process"
void example_1(){
    double sample_rate =3D 44100;
    std::size_t frame_size =3D2;
  &n= bsp; std::= size_t buf= fer_size= =3D128;

    s= td::audio_context<float>= ctx{sample_rate,buffer_size,frame_size};//contruct from values

    std::astream_process<float> proc(ctx,[](std::frame_buffer<float> const& = input, std::frame_buffer<float>& output){
        output<= /span>=3D<= span style=3D"color: #000;" class=3D"styled-by-prettify">intput;//note the copy required=
   =     for(<= /span>auto= &&= i: output){
           = i*=3D1.0;
      &nb= sp; }
  &nbs= p; });

 =   proc.start();
    <= /span>//do other = stuff
&= nbsp;   proc.st= op();
}
=



On Saturday, June 4, 2016 at 9:38:54 AM UTC-5, alexande..= ..@gmail.com wrote:
Is this example more agreeable?

//std::= audio example 1 "single process"
void example= _1(){    double sample_rate =3D 44100;
   = ; std::= size_t frame_size =3D2;
    std::= size_t buffer_size=3D128;

    std::audio_context<float> ctx{= sample_rate,buffer_size,frame_size};//contruct from values

    std::astream_process<f= loat> proc(ctx,[](std::frame_buffer<float> const& input, std::frame_buffer<f= loat>& output){
        f= or(std<= /span>::size_t= i =3D0= ; i <input<= /span>.size();++i){
 = ;           output[i] =3D input[i] * 1.0;
     =   }
    });

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


On Saturday, June 4, 2016 at 1:28:01 AM UTC-5, Ron wrote:
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 = '=3D' operator should be used since anyone that sees an '=3D' operator know= s its a copy.  But really, you shouldn't need to move data around so m= uch.  If you stream from input to 'buff', then process and then move f= rom 'buff' to output then you are moving a lot of data unnecessarily.
=

I think what should happen is this; The process chain i= s triggered when the output signals it is ready for data by calling the fir= st linked process.  Starting at the output, each process kernel calls = the previous until it reaches the input where the input device/file/etc cop= ies the data to the chains frame buffer.  Each process then operates o= n that single buffer in turn until finally returning to the output, thus al= tering 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 p= rocessed.  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 au= dio really flows through a system but it makes things easier then moving da= ta like a bucket brigade.  It can also allow easier parallel processin= g when there are multiple branches on a node.  So if you think of an a= udio mixer, where there are many inputs and a single output, the output cal= ls 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 file= s.  I know people like to say "file format" but then, what format is t= he 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 w= ord 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 s= ample rate, channels, interleaving, channel routing and other information a= nd 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 h= ow 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 UT= C-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::fstre= am. The std::astream/iastream/oastream would represent the default audio de= vice 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 d= evice?

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 ol= d arrays might do for now and get some basic audio recording and playback i= nto 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 the= re 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 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.goo= gle.com/a/isocpp.org/d/msgid/std-proposals/d6c30daa-bab3-454d-899d-2ad906fc= 55df%40isocpp.org.

--
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/20160604161527.4915281.1654.11659%40gmai= l.com.
.