On Fri, Nov 29, 2013 at 03:59:37PM +0530, Vinod Koul wrote:
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!
We certainly have stuff that transfers in the region of 30kB to the DSPs for configuration data for some algorithms, and I certainly wouldn't rule out larger cases in the future. At the moment this is handled by splitting this into 512 chunks, but the numbers of controls involved does start to feel like you are fighting the system a little.
We haven't done a lot of investigation into the latency of this at this time but it is certainly something that is coming up in discussions and I would expect we will be starting to worry more about it in the near future. I will endeavour to share what results I can as we get into this more.
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
It does feel a little odd to have this data set through a different interface to other existing control data, but I guess anything we do does have to be very careful around upsetting existing user-space code.
Thanks, Charles