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.