[alsa-devel] alsa-lib support for compress offload

[Vinod Koul]

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?

I would hate if we had to rewrite the simple wrappers over IOCTLs to support
compress in alsa-lib!

Thanks

-- 
~Vinod