[alsa-devel] [PATCH 2/2] ALSA: oxfw: discontinue MIDI substream for scs1x at transaction failure

[Takashi Iwai]

On Fri, 19 Feb 2016 10:23:36 +0100,
Takashi Sakamoto wrote:
> 
> Hi,
> 
> On Feb 19 2016 17:19, Takashi Iwai wrote:
> > On Fri, 19 Feb 2016 01:55:50 +0100,
> > Takashi Sakamoto wrote:
> >>
> >> With a previous commit, ALSA oxfw driver retries transferring MIDI
> >> messages at transaction failure for scs1x. On the other hand, there're
> >> fatal transaction error. Then, MIDI messages never reach to the unit
> >> anymore. In this case, MIDI substream should be discontinued.
> >>
> >> This commit stops MIDI transferring after the fatal error occurs.
> >> Unfortunately, unlike ALSA PCM functionality, ALSA rawmidi core has no
> >> feature to discontinue MIDI substream in kernel side, thus this commit
> >> just stops MIDI transferring without notifying it to userspace.
> >
> > It's fine to take this, and I would take it as is for now.
> 
> OK.
> 
> > But we can extend the rawmidi somehow to deal with such an error, too.
> > Maybe just having "error" flag in the rawmidi runtime and adding a
> > helper function to set the error and stop the stream should work
> > easily.
> 
> You forgot ALSA sequencer.

This is a different layer.  The sequencer stuff may check the error
and handle more gracefully than as of now, but it's a different story
from the extension of rawmidi itself.

What you're working on is the rawmidi, and what it can give is just
returning an error at the right moment.

> I had considered about it when working for snd-firewire-digi00x (Mar 
> 2015), and realised that it may take much time. At least, we work for:
>   - ALSA rawmidi core
>   - ALSA rawmidi interface for userspace

We don't need to extend rawmidi user-space API so much.  Again, what
needed is to return an error at read/write, probably -EPIPE, right
after the driver got a hardware error.  For that, just adding
runtime->error flag and checking it appropriate should suffice (in
theory).  The read/write in rawmidi is pretty simple.  And we don't
have to reset the flag until the stream is reopened.  There is no
setup/preparation phase for rawmidi unlike PCM.

> Additionally, users mostly use rawmidi devices via ALSA sequencer:
>   - ALSA sequencer core
>   - ALSA sequencer interface for userspace
> 
> Furthermore, regression test is required for:
>   - ALSA drivers with MIDI functionality
>   - ALSA rawmidi/sequencer applications in userspace
> 
> It's not 2000s. I guess that little developers are attracted for this 
> work. In my option, the work is really cost-expensive than actual merit. 
> So currently I'm negative for the idea.

A regression test is needed of course, but a simple error check
can't regress except for the driver that really supports it.


Takashi