[alsa-devel] [RFC] AXD Audio Processing IP ALSA support - Questions

[Qais Yousef]

On 11/04/2014 04:14 PM, Pierre-Louis Bossart wrote:
> On 11/4/14, 6:04 AM, Qais Yousef wrote:
>> On 11/04/2014 10:40 AM, Vinod Koul wrote:
>>> On Tue, Nov 04, 2014 at 09:48:18AM +0000, Qais Yousef wrote:
>>>> Hi,
>>>>
>>>> I have several questions on the best way to add AXD support in ALSA.
>>> 1st rule pls CC maintainers, so that it gets rights attention.
>>>
>>
>> OK sorry about that.
>>
>>>> The discussion of the previous patch can be found here:
>>>>
>>>> https://lkml.org/lkml/2014/10/28/465
>>>>
>>>> Questions:
>>>>
>>>> 1- What is the best example to follow to add a simple mp3 support
>>>> for AXD? The only one I find is in sst-mfld-platform-compress.c in
>>>> sound/soc/intel directory but it's a bit confusing. I think because
>>>> it's sharing code with several other sst drivers/platforms.
>>> There are two ways
>>> 1. If you are a ASoC driver which is most likely the case, then add a
>>> compress dai and then a compress dai-link. The device with compress
>>> device
>>> will be created.
>>> 2. Directly call compress_register the way asoc does
>>>
>>> For both you need to implement the compressed ops
>>
>> Thanks for the pointers :)
>>
>>>> I find the documentation for compress_offload generally lacking. Is
>>>> there a plan to improve on that? Being a new comer to ALSA framework
>>>> api, I'm confused what is the correct way to do things :-/
>>> Are you talking about kernel API or driver API? Can you please 
>>> elaborate
>>
>> Driver API. A new section in 'Writing an ALSA Driver' for compress
>> offload would be helpful for example.
>>
>> snd_compress_register() for example is not clear in what context it
>> needs to be called. I failed to find any reference to a user. In your
>> pointers above I was trying to do 1 and 2 simultaneously - I didn't
>> realise that 1 makes 2 unnecessary.
>>
>> It might be that I just need to spend more time on it to get it.
>>
>>>> So far I know I need to call snd_soc_register_card(). I thought
>>>> snd_compress_register() (from compress_driver.h) is how you add
>>>> compressed nodes to the card but apparently not. It looks like I
>>>> need to define a compress_dai? Hmmm.
>>> You need to define a compress_dai if you are a asoc device just like
>>> the pcm
>>> dai's, it is similar to what you would need to do for PCM
>>>
>>>> 2- Is tinycompress the only userland support for compress_offload?
>>>> Is there anyone working on gstreamer and omx plugins to support
>>>> that?
>>> Yes, I don't know of anyone working on omx support.
>>>> Would tinycompress be part of alsa-utils and alsa-libs in the
>>>> future? I know it needs more work at the moment but it'd be nice if
>>>> compress_offload support is part of the standard alsa-utils and
>>>> alsa-libs.
>>> It is alsa-lib, for packaging we can make it part of alsa packages. 
>>> Most
>>> users are right now in Android so no one asked yet
>>
>> I'm using buildroot for my testing. So if it's included part of alsa
>> packages that would be helpful.
>
> tinycompress (just like tinyalsa) have a different license and 
> different maintainers.
>
>> Also it'll help with getting gstreamer support.
>
> in a gstreamer/pulseaudio setting, the plan was to pass all the data 
> through pulseaudio using IEC packets (to allow for byte-ms 
> conversions) and have a sink that would perform the needed conversion 
> using tinycompress (totally hardware specific). Direct access from 
> gstreamer to tinycompress gets in the way of audio routing/volume 
> control handled in pulseaudio. I think this was presented at Plumbers 
> 3-4 years ago.

Useful. Hopefully I can find online references to this discussion.

> But as Vinod said, we've only heard of Android usages so far.
>
>>
>>>> 3- Can we get an example of how transcoding (back to disk) is
>>>> supposed to be working?
>>> As I have replied to you last week, it would be done using two FEs and
>>> these
>>> FEs should be "routed"
>>
>> OK. I need to read more to completely understand this to be honest. I
>> don't know what's an FE and I don't know how they can be 'routed'.
>> That's why I was hoping to get an example or a pointer to anything that
>> does a similar thing.
>> Just to clarify, all the necessary bits are there and I just need to use
>> them?
>
> Front-ends are typically 'logical' streams visible to the host.
> Back-ends are typically physical links.
> FEs and BEs are usually linked through a mixing/routing structure 
> where ALS controls define what gets played where and where you record 
> from.
> As Vinod mentioned, you can define a mixing/routing structure where 
> the decoded data is fed back to an encoder for record applications. 
> Note that if your goal is to transcode faster than real-time you will 
> need a dedicated routing structure that isn't linked to any BE timing 
> - otherwise the transcoding will be throttled by link timings.
>
>>>> 4- How can we reconfigure complex audio effect components (like
>>>> shelving filters) which need filter co-effecient changes to be
>>>> applied all at once atomically to avoid instability?
>>> Add an ALSA control which models sync, then in driver apply once you
>>> get sync control
>>>
>>
>> OK. It's good to know the support for this type of operations is already
>> available.
>
> Such effects typically rely on a 'commit' operation to apply all 
> parameters at once (avalaible in OpenSL ES). You'd need to link your 
> user-space commit operation with low-level procedure that lets your 
> DSP apply everything in one shot. The infrastructure exists but how 
> you implement the commit part is not generic at all. It could be a 
> dedicated alsa control or a bitfield in a 512-byte binary control - 
> your choice really.
>

Many thanks for all the clarifications. I think I better understand how 
it should work now and what to search/look for.

Cheers,
Qais

>>
>> Thanks,
>> Qais
>> _______________________________________________
>> Alsa-devel mailing list
>> Alsa-devel at alsa-project.org
>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel