[alsa-devel] alsa-lib support for compress offload
Qais Yousef
qais.yousef at imgtec.com
Tue Jan 20 10:53:59 CET 2015
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.
More information about the Alsa-devel
mailing list