[alsa-devel] [RFC] ALSA: add new alsa control byte extended

[Takashi Iwai]

At Fri, 29 Nov 2013 10:40:51 +0100,
Jaroslav Kysela wrote:
> 
> Date 29.11.2013 10:08, Takashi Iwai wrote:
> > At Fri, 29 Nov 2013 13:14:59 +0530,
> > Vinod Koul wrote:
> >>
> >> On Fri, Nov 29, 2013 at 08:46:03AM +0100, Takashi Iwai wrote:
> >>> At Fri, 29 Nov 2013 09:59:57 +0530,
> >>> Vinod Koul wrote:
> >>>>
> >>>> As discussed in the last Audio uConf we need to improve byte controls to allow
> >>>> larger size data to be sent to DSPs  The modern DSPs require alsa byte controls
> >>>> size which far exceeds the today 512bytes limit. In order for usermode to send
> >>>> larger sizes (few 100s of KBs) along with size information we add extended byte
> >>>> control interface which sends any size bytes parameter buffer for DSPs to use
> >>>> Obviosly the size must be supported by the device and would be required to
> >>>> inform the max size allowed for the control.
> >>>
> >>> My primary question is -- must this be a control element?
> >> I think yes. With controls we have an easy way to send parameter bytes and a
> >> good support from both kernel and usermode, so leveraging that would make sense.
> > 
> > But it means that we have to extend / fix allover places using the
> > control elements.  And the variable size isn't handled there, so far.
> > It's the biggest concern.
> > 
> > For example, how would you read such a control element?  Currently,
> > all the control element values have the same static size, so the data
> > is just there to read.  OTOH, if you read data with an unknown size,
> > you have to query the size at first, allocate the buffer, then read
> > the data.  It's a completely different flow.
> > 
> >> Mostly here the limit of 512 is hitting folks and IMO arbitrarily increasing
> >> size doesn't help. For DSPs the algorithm coefficients can be larger 
> > 
> > Well, it's basically a kind of abuse of control elements, IMO...
> 
> I basically agree, but... I believe that these chunks can be divided to
> the 512 limit using continuous indexes (kcontrol->count) and a simple
> rule in the driver "write all to a DSP when the last control (index) is
> touched" may be enough. No API extensions are required. The question is:
> Do you rellay need 100+KB for coefficients? Do you expect to handle
> these data in standard tools like alsactl?

Yeah, I suggested a similar workaround when the issue came up ago
(IIRC, it was about WM codecs).  But it's certainly ugly, indeed.


Takashi