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

[Jaroslav Kysela <perex@xxxxxxxx>]

On 02. 07. 24 15:51, Vinod Koul wrote:
> 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...?

Yes, it's just to accelerate decoding/encoding in the user space chain.

> > > 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?

Yes, I do, but my time is limited in the next weeks, but it's on my to-do list.

> > > > +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..

To clarify, are you speaking about "passthrough" or "accel" here?

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

I tried to follow playback/capture scheme - O_ACCMODE for open determines the 
direction - in the passthrough mode the matched value is O_RDWR. Also, the 
range for static minor numbers is shared so different device name may be 
problematic.

					Jaroslav

--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.