Re: [FFADO-devel] [RME] Questions about packet structure and processing

[Jonathan W. <jw...@ju...>]

Hi Clemens

On Sun, Sep 07, 2014 at 03:18:31PM +0200, Clemens Ladisch wrote:
> Jonathan Woithe wrote:
> > On Sun, Sep 07, 2014 at 01:58:15PM +0900, Takashi Sakamoto wrote:
> >> - The way to transfer MIDI messages.
> >
> > It's done via ARM.  To date I haven't gotten around to implementing this
> > because getting this to work within the confines of the FFADO infrastructure
> > wasn't obvious to me at the time.
> 
> In an ALSA driver, doing MIDI with asynchronous transfers is easier than
> with isochronous ones.

Sounds promising.

> Furthermore, it would be possible to create an independent RME MIDI
> driver that could be used together with FFADO.

This is the approach I have been basing my thoughts on.

> Does there exist any information about the RME MIDI protocol?

Although I haven't looked at it in detail for the reasons given earlier, I
think I have all the information required to make it happen.  It's just that
I haven't had the time to run with it yet and for me MIDI via the RME was a
lower priority than all the other device functions.

> > I had no immediate need to do MIDI I/O with the RME boxes.
> 
> Would you be able to do at least loopback testing?

It has always been my intention to include MIDI in the RME firewire driver,
although given the gradual move of the FFADO streaming code into the kernel
I was more or less working toward doing this only for the kernel driver.  I
certainly have the ability to do testing with MIDI and do in fact use MIDI
myself - just not through the RME at this time.

Since this whole subject has been brought up now I might as well raise some
points which I was going to ping you about at some point.  In light of
Takashi's message though I guess I first need to know what the intent
appears to be from your end.  Is Takashi going to take over the writing of
the RME streaming engine for ALSA as far as you are aware?  If he wants to
do it then that's fine by me - I'll just abandon the informal development
I've been pondering to date.  At the same time I am more than happy to
proceed as I have always planned to do, with the caveat that with a family
and an unrelated day job I can't be sure how long it might take.

If I was to start working on this, could you give me a brief outline on how
I would need to use the ALSA git infrastructure or point me to some
documentation on the web which would explain this?  I am more or less a
complete git novice and am still to get my head around how it's all meant to
work.

A more technical question regards the need in the RME case for the kernel to
make available to userspace some device-specific configuration details (eg:
phantom power switch status, clock settings, etc).  The reason why this is
required is a consequence of the device's protocol.  There are a number of
different ways this could be provided and I was wondering what the current
preferred way might be.  Of course this question is only relevant if I
continue pursing the RME streaming driver myself.

 1) Provide the details via a structure obtained from an ioctl.

 2) Create a directory in either procfs or sysfs, with one file per
    parameter.  I believe sysfs is preferred for this sort of thing these
    days.

 3) Make the information available via a special device in /dev/.

Personally I prefer options 2 or 3 since it is my understanding that they
are more easily extendable as the need arises.  There is also a reluctance
to create new ioctls when some other mechanism exists.  I would appreciate
any thoughts you might have on this subject.  Note that this issue only
affects the RME protocol: no other devices currently supported by FFADO will
have this issue.

Regards
  jonathan