alsa-lib support for compress offload

alsa-lib support for compress offload

[Qais Yousef]

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-td4670153.html
[2] 
http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/ext/alsa/gstalsasink.c#n836
[3] 
http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/ext/alsa/gstalsa.c#n437

Re: alsa-lib support for compress offload

[Takashi Iwai]

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

Re: alsa-lib support for compress offload

[Qais Yousef]

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/tinycompress/tinycompress.h;h=03c396fccea5f2a176d24fd580ee6a447da657ec;hb=HEAD

Re: alsa-lib support for compress offload

[Pierre-Louis Bossart]

>> 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/tinycompress/tinycompress.h;h=03c396fccea5f2a176d24fd580ee6a447da657ec;hb=HEAD

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

Re: alsa-lib support for compress offload

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 823 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: alsa-lib support for compress offload

[Qais Yousef]

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

Re: alsa-lib support for compress offload

[Pierre-Louis Bossart]

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

Re: alsa-lib support for compress offload

[Arun Raghavan]

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

Re: alsa-lib support for compress offload

[Qais Yousef]

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.

Re: 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

Re: alsa-lib support for compress offload

[Qais Yousef]

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

Re: alsa-lib support for compress offload

[Takashi Iwai]

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

Re: alsa-lib support for compress offload

[Qais Yousef]

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

Re: alsa-lib support for compress offload

[Pierre-Louis Bossart]

> 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 :-)

Re: 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

Re: alsa-lib support for compress offload

[Pierre-Louis Bossart]

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

Re: alsa-lib support for compress offload

[Takashi Iwai]

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