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

[Vinod Koul]

On Wed, Jan 21, 2015 at 12:59:49PM +0100, 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.
Can we actually support compress with current alsa APIs? If yes then we can
do rework and keep current tinycompress APIs for Andporid and let core lib
be reused, if not then we can go with these new APIs

> > 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...)
The Makefiles were added just to check sanity and do quick compilation.
Patches to fix this are welcome :)

-- 
~Vinod