Hi Takashi et al
Just thought I'd let you know that I found the bug that was causing the softvol plug-in to fail. As usual my suspicions were about as far from the cause as it is possible to get; it was neither a bug in the user mode code, nor was it an endian issue.
I found the culprit in the core module in the kernel code. As I said in earlier mails the kernel version I'm using (2.6.10) is not the latest and contains the 1.0.6 version of the ALSA drivers.
The latest driver code I've looked at (1.0.15) already has fixes applied and is not vulnerable to the same bug so I'm not reporting anything new.
I'll put a brief synopsis of the bug at the end of this email if anyone's interested, otherwise you can stop reading now.
Takashi, thanks for your input.
Best regards Simon
Description -----------
I found the bug in the kernel core module in sound/core/control.c. It was a 2 fold issue;
1) The elem_data pointer member of the user_element struct was being assigned an address 4 bytes into the user_element struct instead of at the end of it.
Change the statement .. ue->elem_data = (char *)ue + sizeof(ue) + dimen_size; to .. ue->elem_data = (char *)ue + sizeof(*ue) + dimen_size;
fixes that one.
2) The softvol control is now enumerated correctly but still does not work; amixer and alsamixer both report the volume as zero and neither can modify it. The reason for this is that the user_element struct is not holding information pertaining to the min and max volumes levels permitted by the control. This information is passed into the driver via the _info parameter of snd_ctl_elem_add but was not being retained.
To fix it is a simple matter of retaining all the information provided by snd_ctl_elem_add and returning it appropriately.
As I said both of these issues are accounted for in latter versions of the driver code so this description of them is for information only, should someone else trip over the same bug when using older versions of the architecture.
~Simon