Re: alsa-lib support for compress offload

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

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.