[alsa-devel] [PATCH 24/44] fireworks: Add MIDI interface

Takashi Sakamoto o-takashi at sakamocchi.jp
Mon Apr 7 14:59:35 CEST 2014

Hi Clemens,

(Apr 6 2014 23:52), Clemens Ladisch wrote:
> The fast path of mutex_(un)lock already is quite heavily optimized.
> Optimizations should not be added unless they are actually needed; in
> this case, the difference would not be noticeable, especially because
> none of these functions are called frequently.  (But if the code using
> atomic_t ends up being simpler, there's no reason not to use it.)

OK. I should not have mentioned about optimization.

My intent to add stream.c is to make it simple for PCM/MIDI 
functionalities to handle streams.

When needing to start streams, PCM/MIDI functionalities increment 
reference counter and call stream_start_duplex(). Then needed streams 
are started.

When needing to stop streams, PCM/MIDI functionalities decrement 
reference counter and call stream_stop_duplex(). Then needless streams 
are stopped.

In both cases, function call following to changing reference counter. 
But for PCM functionality, these must be separated because of .prepare() 
call at XRUN. When XRUN occurs, application may call snd_pcm_prepare(). 
Then reference counter should not be incremented.

I use this way for fireworks/bebob drivers. So I hope to keep the codes 
simple and safe to avoid large mistakes.

In this reason, I prefer to use mutex for function itself and atomic_t 
for reference counter. If both of them must protected with mutex, it 
brings more codes for PCM/MIDI functionalities. I want to avoid this.


Takashi Sakamoto
o-takashi at sakamocchi.jp

More information about the Alsa-devel mailing list