On Sun, 17 Oct 2021 03:22:31 +0200, Takashi Sakamoto wrote:
Hi,
On Fri, Oct 15, 2021 at 05:54:13PM +0200, Takashi Iwai wrote:
On Fri, 15 Oct 2021 10:08:15 +0200, Takashi Sakamoto wrote:
Hi,
The purpose of this patchset is to add message parser to ALSA firewire-motu driver so that userspace applications can read information in message delivered by isochronous packet as well as PCM frames. The message includes information about hardware meter and user action over hardware component such as knob, and MIDI message bytes.
Models in MOTU FireWire series can be categorized to 4 groups in regard of message mechanism:
Group 1. 828 and 896
- quadlet message to registered destination address
Group 2. 828mk2, 896hd, Traveler, 8 pre, Ultralite, 4 pre, and Audio Express
- quadlet message to registered destination address
- message delivered by isochronous packet
Group 3. 828mk3, 896mk3, Ultralite mk3, Traveler mk3, and Track 16
- quadlet message to registered destination address
- message delivered by isochronous packet
- block message to registered destination address, including command
Group 4. V3HD/V4HD
- quadlet message to registered destination address
- block message to registered destination address
The patchset is for message delivered by isochronous packet in group 2 and 3. In Group 2, the message includes information of hardware meter, information of user action over hardware component. The model in Group 2 is called as 'register DSP' in the patchset since parameters of DSP can be configured by asynchronous transaction for register access. In Group 3, the message includes information of hardware meter only. The model in Group 3 is called as 'command DSP' since software and device communicate with commands transferred by asynchronous transaction in regard of DSP parameters. Two types of message parser is going to be added so that the driver caches images for the information. The cache is available for userspace application by ioctl commands newly introduced.
I note that no control element is added for the hardware meters and user actions. It's expected for userspace application to retrieve and parse the information of image then operate for user-defined control element set.
Takashi Sakamoto (11): ALSA: firewire-motu: add message parser to gather meter information in register DSP model ALSA: firewire-motu: add message parser for meter information in command DSP model ALSA: firewire-motu: add ioctl command to read cached hardware meter ALSA: firewire-motu: parse messages for mixer source parameters in register-DSP model ALSA: firewire-motu: parse messages for mixer output parameters in register DSP model ALSA: firewire-motu: parse messages for output parameters in register DSP model ALSA: firewire-motu: parse messages for line input parameters in register DSP model ALSA: firewire-motu: parse messages for input parameters in register DSP model ALSA: firewire-motu: add ioctl command to read cached DSP parameters ALSA: firewire-motu: queue event for parameter change in register DSP model ALSA: firewire-motu: notify event for parameter change in register DSP model
Applied all patches now. Thanks.
Thanks for your applying the above patches into your tree. I have some slight concerns about them. I'd like to ask your opinion.
The snd_firewire_motu_command_dsp_meter structure includes array of 32 bit storage elements. As I added its documentation, the storage includes IEEE 764 binary32 values between 0.0 and +1.0. In the patchset I use __u32 type since I can find just a few usage of float type in UAPI header. In driver side, no floating point arithmetic is used since the float value is just constructed by gathering messages from target device. In the case, is it adequate to expose the value as float type in UAPI?
Additionally, current ALSA control interface have no support for control element with float value, like SNDRV_CTL_ELEM_TYPE_IEEE764_BINARY32. As long as I know, no discussion about it in the list for recent decades. Have you ever seen such discussion in the list? (Here I intensionally ignore that we have several binary expressions for floating point since I'm just interested in the existence of discussion.)
It's not been proposed, AFAIK.
The biggest concern is that, *if* any reference or calculation of the float type is required, what to do. e.g. the kernel has a validation code for each values (min/max check), and how could it be implemented for the float type?
thanks,
Takashi