Re: [PATCH v4] ALSA: compress_offload: introduce passthrough operation mode

[Vinod Koul <vkoul@xxxxxxxxxx>]

Hi Jaroslav,

On 24-06-24, 17:31, Jaroslav Kysela wrote:
> On 24. 06. 24 16:47, Vinod Koul wrote:
> > On 24-06-24, 15:58, Jaroslav Kysela wrote:
> > > There is a requirement to expose the audio hardware that accelerates various
> > > tasks for user space such as sample rate converters, compressed
> > > stream decoders, etc.
> > 
> > Can you please tell me more about this requirement. The initial view of
> > compressed API was data only and use alsa kcontrols to handle the DSP
> > functions? I would like to understand why we need a new API.
> 
> There are very long threads for v4l audio support - last v15 thread:
> 
> https://lore.kernel.org/linux-media/1710834674-3285-1-git-send-email-shengjiu.wang@xxxxxxx/

Very long indeed but very interesting. I think going compressed audio
way seems reasonable choice to me

> 
> So the goal is to create something more efficient for the offload work, when
> the data (decoded/converted) should be returned back to the user space.

Not rendered? so we are using it as an accelerator...?

> 
> > What about the user of this API, i would like to see that as well
> 
> Any audio streaming framework like gstreamer or ffmpeg who can accelerate
> stream conversions in hardware for capable devices.

I meant to see driver users along with this patch :-)

That also reminds me to ask about usermode support for this, are you
planning to support it in tinycompress?

> 
> > > +A new direction SND_COMPRESS_PASSTHROUGH is introduced to identify
> > > +the passthrough API.
> > 
> > Is passthrough really a new good new name, this suggests data being
> > passed thru but that is not the case...
> 
> It's something like "PASS data THROUGH kernel/driver". So it makes sense. My
> alternate name may be ACCEL (like acceleration).

I like that.. Also do we change the device name if the passthru is
enabled? it should not be called a playback or capture compressed device

-- 
~Vinod