Re: alsa-lib support for compress offload

[Qais Yousef <qais.yousef@imgtec.com>]

On 01/21/2015 11:59 AM, Takashi Iwai wrote:
> At Tue, 20 Jan 2015 23:10:53 -0800,
> Vinod Koul wrote:
>> On Tue, Jan 20, 2015 at 09:53:59AM +0000, Qais Yousef wrote:
>>> On 01/19/2015 10:07 PM, Pierre-Louis Bossart wrote:
>>>> On 1/19/15 11:23 AM, Qais Yousef wrote:
>>>>> On 01/16/2015 04:50 PM, Pierre-Louis Bossart wrote:
>>>>>> Since there is no allowed processing/reformatting/reshuffling of
>>>>>> compressed data, all the plugin system needs to be bypassed and you'd
>>>>>> be looking at an alsa-lib API that interfaces directly with the
>>>>>> ioctls, essentially replicating what tinycompress does. I agree it's
>>>>>> not great to have independent packages, the decision to maintain
>>>>>> tinycompress separately was driven by licensing concerns, not
>>>>>> technical ones.
>>>>>> -Pierre
>>>>>>
>>>>> I'm not sure how dual licensing work. Is it ok to base alsa-lib support
>>>>> for compress API on tinycompress then?
>>>> no idea, and what is the objective really? it's not clear what you
>>>> are trying to achieve and what would be the merits of enhancing
>>>> alsa-lib with compressed audio support?
>>>> -Pierre
>>>>
>>> Long story short, I am writing a new ALSA driver that supports
>>> compress offload. The only user land support I could find is in
>>> tinycompress. I was looking at adding gstreamer support to
>>> facilitate my testing and hopefully make the driver more useful.
>>>
>>> I am happy to use tinycompress if that's the official way alsa wants
>>> to support userland applications. When Takashi suggested that he
>>> didn't get patches for compress API support in alsa-lib I thought it
>>> was a hint it's a better idea to have it there. I think it makes
>>> sense to merge tinycompress into alsa-lib as this will make the
>>> functionality more readily available - if license is not an issue.
>> Sorry for delayed reply, I am travelling.
>>
>> tinycompress comes with dual license LGPL and BSD. Currently the main user of
>> this is Android which picks up the BSD license.
>>
>> Though I am not a lawyer, but I don't see a reason if alsa-lib uses LGPL
>> license to take this lib and include compress support in alsa-lib. This
>> way we have code reuse and take advantage of alsa-lib to support compress
>> formats too. Takashi is that fine with you?
> Well, I see no big merit to merge into alsa-lib if API isn't
> compatible with others.  At least the open function doesn't align with
> other functions taking the device name string.

IMHO for a newcomer to alsa like me I expect to find all alsa features 
supported by the kernel supported in alsa-lib too. It's confusing when I 
need to use different libraries for different alsa features. Especially 
in this case I don't see the necessity for a different package - except 
you need non LGPL license. I *think* having the API in alsa-lib will 
ensure the documentation is consistent and can be found in one place.

>
>> I would hate if we had to rewrite the simple wrappers over IOCTLs to support
>> compress in alsa-lib!
> True.
>
> The compress-offload support in alsa-lib is a "nice to have" one.
> But I guess the more interesting question right now is whether
> applications can use tinycompress as an "official" component.
> My (personal) answer is "yes".  It doesn't conflict even if start
> implementing in alsa-lib, at least.
>
> (BTW, from the packaging POV, tinycompress lacks a few proper things
>   in Makefile...)
>
>
> thanks,
>
> Takashi