[PATCH 00/11] ALSA: firewire-motu: add ioctl commands to retrieve information in messages delivered by isoc packet

[Takashi Iwai]

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