From mboxrd@z Thu Jan 1 00:00:00 1970 From: Qais Yousef Subject: Re: [ALSA-UTILS][PATCH] Add support for cplay and crecord Date: Thu, 5 Mar 2015 12:37:33 +0000 Message-ID: <54F84E0D.1070907@imgtec.com> References: <1425483360-1806-1-git-send-email-qais.yousef@imgtec.com> <20150304161013.GU2613@intel.com> <54F73421.3000108@imgtec.com> <20150305070018.GW2613@intel.com> <54F80916.50703@perex.cz> <20150305083054.GY2613@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mailapp01.imgtec.com (mailapp01.imgtec.com [195.59.15.196]) by alsa0.perex.cz (Postfix) with ESMTP id 4A6D9260439 for ; Thu, 5 Mar 2015 13:37:35 +0100 (CET) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Takashi Iwai , Vinod Koul Cc: alsa-devel@alsa-project.org, Mark Brown , Pierre-Louis Bossart List-Id: alsa-devel@alsa-project.org On 03/05/2015 08:52 AM, Takashi Iwai wrote: > At Thu, 5 Mar 2015 14:00:54 +0530, > Vinod Koul wrote: >> On Thu, Mar 05, 2015 at 08:43:18AM +0100, Jaroslav Kysela wrote: >>> Dne 5.3.2015 v 08:00 Vinod Koul napsal(a): >>>> On Wed, Mar 04, 2015 at 04:34:41PM +0000, Qais Yousef wrote: >>>>> On 03/04/2015 04:10 PM, Vinod Koul wrote: >>>>>> On Wed, Mar 04, 2015 at 03:36:00PM +0000, Qais Yousef wrote: >>>>>>> cplay and crecord use compress offload API to play and record compressed audio. >>>>>>> >>>>>>> They're based on cplay and crec from tinycompress library using LGPL license. >>>>>>> >>>>>>> For now cplay only supports playing mp3 files. >>>>>>> >>>>>>> Signed-off-by: Qais Yousef >>>>>>> Cc: Takashi Iwai >>>>>>> Cc: Vinod Koul >>>>>>> Cc: Mark Brown >>>>>>> --- >>>>>>> I renamed crec to crecord also to match aplay and arecord, hopefully >>>>>>> you don't mind Vinod. >>>>>> No thats fine.. >>>>>> >>>>>>> This patch is dependent on my other patch that adds support for compress offload >>>>>>> to alsa-lib. >>>>>> And where is that, should have preceded this >>>>> Hmm not sure what went wrong. I resent it. Seems I have some emailer >>>>> issues as I had this problem before. >>>>> Hopefully you received it now. >>>>> >>>>>>> I needed to include in cplay.c and crec.c >>>>>>> but I couldn't find an example of any C file which directly includes >>>>>>> The norm seems to be to just include . Do I need to >>>>>>> redefine structs from to newly added ? >>>>>>> seems to redefine structs from . >>>>>> These are kernel headers and should be in your include path if you have >>>>>> those installed >>>>>>> I could only test cplay but have no means to test crecord at the moment. >>>>>>> >>>>>>> Makefile.am | 3 + >>>>>>> configure.ac | 6 +- >>>>>>> cplay/Makefile.am | 14 ++ >>>>>>> cplay/cplay.c | 294 +++++++++++++++++++++++++++++++++++ >>>>>>> cplay/crec.c | 449 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>>> cplay/tinymp3.h | 72 +++++++++ >>>>>>> 6 files changed, 837 insertions(+), 1 deletion(-) >>>>>>> create mode 100644 cplay/Makefile.am >>>>>>> create mode 100644 cplay/cplay.c >>>>>>> create mode 100644 cplay/crec.c >>>>>>> create mode 100644 cplay/tinymp3.h >>>>>> Okay here is where we need discussion on the future course. If we do this >>>>>> then we end up in two code bases, something I would not encourage! >>>>>> >>>>>> On the other hand if we add the make file changes to tinycompress or if >>>>>> required split this into two, lib and tools and then package lib part into >>>>>> alsa-lib and players into tools, that way we can have single code base. That >>>>>> was my intent behind ensuring that this is dual licensed. >>>>> I'm not sure I follow you completely here. You mean keep cplay and >>>>> crec in tinycompress with the dual licensing but only merge the lib >>>>> part (which my other patch does) into alsa-lib? For me having this >>>>> lib part into alsa-lib is the important bit. Moving crec and cplay >>>>> to alsa-utils was something I thought would be useful but maybe not. >>>> Not that >>>> >>>> Since alsa splits lib and tools, in order to take this into alsa-libs we >>>> need to split tinycompress, to something like lib and tool part. >>>> >>>> Then alsa-lib can import the lib part of tinycompress. Please note I am not >>>> saying we should copy or move code into alsa-lib. >>>> The reason for that is >>>> 1. copying code will cause more maintaince of same code in two places :( >>>> 2. moving into alsa-lib is not an option as existing users like android will >>>> suffer as they dont use alsa-lib >>>> >>>> So I think, while building and packaging alsa-library and tools we can >>>> import the tinycompress using LGPL license and use that to give complete >>>> library on Linux to users >>>> >>>> Takashi, can we get you blessing for this approach before we embark on this, >>>> or any other better ideas? >>> The problem is if the code is not duplicated, then the parts of the >>> alsa-lib binary will be dual-licenced. I don't think that it's the right >>> way. >>> >>> And if the code is duplicated, then patch authors for all next updates >>> in both libraries (alsa-lib, tinycompress) must be asked for permissions >>> to change code licence for the merge to the second library. >>> >>> I think that a plugin-style extension should be created here (so >>> tinycompress will be used at runtime as the dynamic library). >>> >>> compress API -> tinycompress plugin -> tinycompress .so functions >>> >>> This will allow us also to create another plugins in future. >> That does solve the issue for me as well. The intent is to provide >> compressed functionality within alsa-libs so asa plugin that can work very >> well... >> >> Any other thoughts... ? > Well, tinycompress itself is merely a thin layer covering the kernel > ABI. So, writing a plugin infrastructure itself already achieves the > whole rewrite of tinycompress library. What else remains as a plugin > content? > > > Takashi OK reading a bit more about dual license what I understood is that it's ok for alsa-lib to choose redistribute tinycompress as LGPL only. To cope with code duplication we could create tinycompress as a git submodule and educate alsa-lib build system to pull a tag and use that to compile the support for compress api. Makes sense? Alternatively, can't the android use case really use alsa-lib? I don't quite understand the problem except I'm guessing that it wants to statically link against tinycompress so it wants the dual license to avoid releasing the source code.