Re: [RFC] ALSA: add new alsa control byte extended

[Vinod Koul <vinod.koul@intel.com>]

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

On Fri, Nov 29, 2013 at 11:05:49AM +0000, Mark Brown wrote:
> On Fri, Nov 29, 2013 at 10:48:29AM +0100, Takashi Iwai wrote:
> > Jaroslav Kysela wrote:
> 
> > > 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?
> 
> It's certianly possible to do something like that while maintianing the
> ABI, however if we were going to do that we'd probably want to extend
> alsa-lib and tinyalsa to do this transparently and devise a naming
> scheme for the controls to trigger that behaviour.  The main thing is
> the API offered to users.
I think this would a bit problematic for DSPs with large controls. We are
looking at 3 digit number already and splitting to multiple calls is going to be
bad from a already constrained latency problem.

Most of the controls will be few KBs at most with few special cases which can be
in MBs. I think Wolfson is also headed this way!

I am leading more towards adding new ioctl for this along with new ones for
enumerating controls. Then additional support for alsa-lib and tinyalsa.
That way existing tinymix, amxier can see these as controls while not disturbing
existing apps. I dont think we need save and restor, then alsactl need not be
modified.

--
~Vinod

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

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