220 26146 article Path: news.gmane.org!not-for-mail From: ron novy Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Any interest to adding audio support to the std library? Date: Fri, 3 Jun 2016 15:32:49 -0700 Lines: 118 Approved: news@gmane.org Message-ID: References: <5751B06A.4080501@mail1.stofanet.dk> <4539123.eWIb3U4yhc@lastique-pc> <20160603211341.4915281.1974.11611@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c0770e88091e30534674d8e X-Trace: ger.gmane.org 1464993173 20844 80.91.229.3 (3 Jun 2016 22:32:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Jun 2016 22:32:53 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDO2TPGE4QNBBEULZC5AKGQEWRPUFOI@isocpp.org Sat Jun 04 00:32:53 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 1b8xe8-0006mk-Gt for gclcip-std-proposals@m.gmane.org; Sat, 04 Jun 2016 00:32:52 +0200 Original-Received: by mail-ob0-f198.google.com with SMTP id yu3sf1558733obb.3 for ; Fri, 03 Jun 2016 15:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject: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=khf2a2LDUK2YZTSZsGHCQSfX6dguvGwefOZQobcWjEs=; b=T0XMcO9YQ/xGBM1ysDWQSd+AVCyfzpfCeffkQoP4gSIgXmgYYrojOYVVY1H0vwhykd SR+g200MQNB5vcy3M8n7XmP5+Wep89AFkafK1zPzkYl2bNe59jDHKHf8ekN4Ih67O27F EOegr06+Os4mTv/bYZ85Emu0ya/IZv9t4MX5WiJp9QtWi8Z2rzFyjtmVmtyZ0VxpHksa 5gS31SyNxjasvLIM+Q9ij+9T/N/wpikT3LAV9TD8REKU/vRX7TGjJX5/QwaJO8AlOsBX wAT5P0/nXsiKoiDmMfgn3z2JfJzYf/ugO8IhKlt9G7BWojKP2YN69tNzpWyiErW/iB33 8uRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject: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=khf2a2LDUK2YZTSZsGHCQSfX6dguvGwefOZQobcWjEs=; b=bK9srS1qjrgXu3+EZyzHTT+trGeeWApVO9kMYUSbXxwxADIBVX9WbA9ejieQ/Ap33u qztjRAaNkQS504eLCVIVx4CzfQ1a3IclugFuCvv5MJEWbb6IzIkRufhp7xJMGDcd8GWO 3+CJ4y0Ku7FDhZIF/0bdKypHR0uXkR9FEeGHnFN11UKGrPH9I5Q4qGJ8SPXrh1s7BrUf sKHnuGj2U7LekO4X7/s1qTL4K8qAobq3/urjBsT2RhGk1w5fJ1vzfIgQybfstwlfAuuO nqxPSaq+DYtA8vQEB3SKV9Km2j/bcQKMvXxYIzoAhrRfu6aG/IfWg4BqxMkOdsWx5Upi t2aQ== X-Gm-Message-State: ALyK8tKwbGsjaFZnC0Oc6POsGWfU5qXdmGX01JP8hZc/LNifOyS5ilIib648k8d2pNrQPA== X-Received: by 10.157.55.183 with SMTP id x52mr4458667otb.38.1464993171507; Fri, 03 Jun 2016 15:32:51 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.63.72 with SMTP id m66ls428401otc.17.gmail; Fri, 03 Jun 2016 15:32:50 -0700 (PDT) X-Received: by 10.202.90.212 with SMTP id o203mr3292999oib.117.1464993170433; Fri, 03 Jun 2016 15:32:50 -0700 (PDT) Original-Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com. [2607:f8b0:4001:c06::22c]) by mx.google.com with ESMTPS id p204si3686946oib.146.2016.06.03.15.32.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Jun 2016 15:32:50 -0700 (PDT) Received-SPF: pass (google.com: domain of rsn10100@gmail.com designates 2607:f8b0:4001:c06::22c as permitted sender) client-ip=2607:f8b0:4001:c06::22c; Original-Received: by mail-io0-x22c.google.com with SMTP id t40so92875151ioi.0 for ; Fri, 03 Jun 2016 15:32:50 -0700 (PDT) X-Received: by 10.107.184.214 with SMTP id i205mr8287292iof.26.1464993170097; Fri, 03 Jun 2016 15:32:50 -0700 (PDT) Original-Received: by 10.64.142.113 with HTTP; Fri, 3 Jun 2016 15:32:49 -0700 (PDT) In-Reply-To: X-Original-Sender: rsn10100@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of rsn10100@gmail.com designates 2607:f8b0:4001:c06::22c as permitted sender) smtp.mailfrom=rsn10100@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:26146 Archived-At: --94eb2c0770e88091e30534674d8e Content-Type: text/plain; charset=UTF-8 >Considering the domain of media codecs is a patent minefield, the API should be designed around never having access to the actual contents of the frames, only that they exist. I disagree with this concept. Frames contain information to be processed. If someone wants/needs to create a closed system then they can do that on their own in their own proprietary system. And its not just about playing or recording audio, there is mixing, transcoding, interleaving, deinterleaving etc. The system driver should be capable of giving you access to a buffer with properties that you choose and the driver itself should then handle getting it to the speakers, but these processing features should still be accessible to C++ in a standard way. I honestly don't think reading specific types of files should be a part of the standard, but as someone who develops audio applications, there could be a better standard for getting the data to or from an audio file or device. And like actual hardware, an audio file or codec could be just another device that you open. If the system supports it and its driver is installed properly then you can enumerate codecs like devices and use them to open file streams. On Fri, Jun 3, 2016 at 3:32 PM, wrote: > That was the basis of my original idea for the library but I found it to > bee too broad and constrained the idea to an audio context for the mean > time, I am planning on working up an alternative version that does what you > are suggesting. The same concepts that I use in my library can be applied > to any type of signal so long as the program can receive that data from the > OS > > -- > 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/d9ecb64d-87e6-492c-9d87-0636aed66d9e%40isocpp.org > . > -- 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/CAOcFa%3DcqxCGYV0iQuEuLcMPhnxFvUVb-X4bcNwxGmtwg5XKxfQ%40mail.gmail.com. --94eb2c0770e88091e30534674d8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>Considering the domain of media codecs is a paten= t minefield, the API should be
designed around never having acces= s to the actual contents of the frames, only
that they exist.

I disagree with this concept.=C2=A0 Frames contain in= formation to be processed.=C2=A0 If someone wants/needs to create a closed = system then they can do that on their own in their own proprietary system.= =C2=A0 And its not just about playing or recording audio, there is mixing, = transcoding, interleaving, deinterleaving etc.=C2=A0 The system driver shou= ld be capable of giving you access to a buffer with properties that you cho= ose and the driver itself should then handle getting it to the speakers, bu= t these processing features should still be accessible to C++ in a standard= way. =C2=A0

I honestly don't think reading sp= ecific types of files should be a part of the standard, but as someone who = develops audio applications, there could be a better standard for getting t= he data to or from an audio file or device.=C2=A0 And like actual hardware,= an audio file or codec could be just another device that you open.=C2=A0 I= f the system supports it and its driver is installed properly then you can = enumerate codecs like devices and use them to open file streams.

On Fri, Jun 3, 2= 016 at 3:32 PM, <alexander.zywicki@gmail.com> wro= te:
That was the basis of my original ide= a for the library but I found it to bee too broad and constrained the idea = to an audio context for the mean time, I am planning on working up an alter= native version that does what you are suggesting. The same concepts that I = use in my library can be applied to any type of signal so long as the progr= am can receive that data from the OS

--
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-propo= sals+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.go= ogle.com/a/isocpp.org/d/msgid/std-proposals/d9ecb64d-87e6-492c-9d87-0636aed= 66d9e%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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOcFa%3DcqxCGY= V0iQuEuLcMPhnxFvUVb-X4bcNwxGmtwg5XKxfQ%40mail.gmail.com.
--94eb2c0770e88091e30534674d8e-- .