[alsa-devel] alsa-lib support for compress offload
Hi,
As far as I understand I need to use something similar to tinycompress to use alsa devices that supports compress offload. When I asked on gstreamer list [1] about alsasink support for compress offload they said yes. But I can see that gstalsasink.c [2] only uses the standard alsa-lib api which AFAICT doesn't support compress offload.
Did I misread the code and alsa-lib actually works with compress offload? Gstreamer refers to the feature "passthrough" and associate it with SPDIF[3], are they taking advantage of some other alsa feature that looks like compress offload?
Thanks, Qais
[1] http://gstreamer-devel.966125.n4.nabble.com/ALSA-Compress-Offload-support-td... [2] http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/ext/alsa/gstalsa... [3] http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/ext/alsa/gstalsa...
At Fri, 16 Jan 2015 09:52:58 +0000, Qais Yousef wrote:
Hi,
As far as I understand I need to use something similar to tinycompress to use alsa devices that supports compress offload. When I asked on gstreamer list [1] about alsasink support for compress offload they said yes. But I can see that gstalsasink.c [2] only uses the standard alsa-lib api which AFAICT doesn't support compress offload.
Did I misread the code and alsa-lib actually works with compress offload? Gstreamer refers to the feature "passthrough" and associate it with SPDIF[3], are they taking advantage of some other alsa feature that looks like compress offload?
It's a normal IEC958 passthrough, nothing to do with the compress offload. And, no, we have no support for compress API in alsa-lib yet. Just because no one submitted the patches.
Takashi
On 01/16/2015 10:34 AM, Takashi Iwai wrote:
At Fri, 16 Jan 2015 09:52:58 +0000, Qais Yousef wrote:
Hi,
As far as I understand I need to use something similar to tinycompress to use alsa devices that supports compress offload. When I asked on gstreamer list [1] about alsasink support for compress offload they said yes. But I can see that gstalsasink.c [2] only uses the standard alsa-lib api which AFAICT doesn't support compress offload.
Did I misread the code and alsa-lib actually works with compress offload? Gstreamer refers to the feature "passthrough" and associate it with SPDIF[3], are they taking advantage of some other alsa feature that looks like compress offload?
It's a normal IEC958 passthrough, nothing to do with the compress offload. And, no, we have no support for compress API in alsa-lib yet. Just because no one submitted the patches.
Takashi
Thanks. I haven't used alsa-lib before but I might be able to send the patches if I get guidance of what needs doing. Is the expected API similar/same to what provided by tinycompress[1]?
[1] http://git.alsa-project.org/?p=tinycompress.git;a=blob;f=include/tinycompres...
It's a normal IEC958 passthrough, nothing to do with the compress offload. And, no, we have no support for compress API in alsa-lib yet. Just because no one submitted the patches.
Thanks. I haven't used alsa-lib before but I might be able to send the patches if I get guidance of what needs doing. Is the expected API similar/same to what provided by tinycompress[1]?
[1] http://git.alsa-project.org/?p=tinycompress.git;a=blob;f=include/tinycompres...
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
On Fri, Jan 16, 2015 at 10:50:07AM -0600, 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.
Well, it'd be nice to be able to support plugins for userspace output devices like networked audio sinks or for talking to an audio server to at least allow it to manage resource contention, or for providing soft decode for that matter. Currently the media frameworks do the job just fine so it's not really a big deal though.
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?
Thanks, Qais
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
On 20 January 2015 at 03:37, Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com 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?
If the same API can be reused/extended, it'd mean allowing code reuse and not having to write entirely separate support for compressed devices in projects that use alsa-lib already. I don't know if that's actually feasible with the way the ALSA API works, though.
-- Arun
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.
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
On 01/21/2015 07:10 AM, Vinod Koul wrote:
Sorry for delayed reply, I am travelling.
Thanks for taking the time to answer.
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
Unless Takashi comes up with an objection, I'll work just on that.
Thanks, Qais
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.
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...)
thanks,
Takashi
On 01/21/2015 11:59 AM, 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.
IMHO for a newcomer to alsa like me I expect to find all alsa features supported by the kernel supported in alsa-lib too. It's confusing when I need to use different libraries for different alsa features. Especially in this case I don't see the necessity for a different package - except you need non LGPL license. I *think* having the API in alsa-lib will ensure the documentation is consistent and can be found in one place.
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...)
thanks,
Takashi
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 :)
On 1/22/15 3:56 PM, Vinod Koul wrote:
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
No. We need to be able to pass decoder/encoder parameters, and we need the ability to deal with bytes, without any fixed mapping between bytes and time. If we want any convergence we'd need ALSA to deal with bytes only and not frames, in addition to the extra configuration steps, which would be a complete API change. -Pierre
At Thu, 22 Jan 2015 16:03:16 -0600, Pierre-Louis Bossart wrote:
On 1/22/15 3:56 PM, Vinod Koul wrote:
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
No. We need to be able to pass decoder/encoder parameters, and we need the ability to deal with bytes, without any fixed mapping between bytes and time. If we want any convergence we'd need ALSA to deal with bytes only and not frames, in addition to the extra configuration steps, which would be a complete API change.
I don't think of merging the compress offload into PCM alsa-lib API. My point is only that the API function forms in tinycompress should be aligned with the existing alsa-lib API functions, e.g. open should take the name string, etc. Managing the compress offload into the PCM API would need redesigns, and I don't think it's worth.
Takashi
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.
The problem when you use a gstreamer->tinycompress path is that you have no hooks for volume control and audio policy/routing. It'll remain a test toy. If you want integration with a better user-friendly support, the right answer is to go through PulseAudio and write a compressed sink within pulseaudio. See the LPC slides from 2010 or 2011 that describe the solution. And Arun can help you with that, he wrote the gstreamer/pulseaudio interface :-)
participants (6)
-
Arun Raghavan -
Mark Brown -
Pierre-Louis Bossart -
Qais Yousef -
Takashi Iwai -
Vinod Koul