Proposal: libunixmm.so (about the Comparison: MAS, GStreamer, NMM)

[Christian Esken]

Hi everybody,

during and since Akademy I have thought a lot about all the approaches discussed there.
The most fundamental question that I have asked me since then was: 

What do we actually gain by changing the MM backend from ARTS to "The-not-yet-known-system"?
The only real answer I found was: Hopefully stability, support and more future-safety.

But now lets take the users perspective:
Even with (e.g.) gstreamer, KDE and Gnome will still block playing MP3 with xmms or Videos with xine. And this is what really matters to the Users:
- You play a "mail notification" and break xmms MP3 playback - thats horrible.
- You start KDE (and artsd with it, locking /dev/dsp even if unsused) and xmms does not work at all
- If xmms uses arts, xmms uses gstreamer, and you-name-it uses esd as default, it will terribly annoy the user

As we still have those basic problems, we must work on that. And this is actually NOT a KDE issue, not a Gnome issue,
not even a Desktop issue. It is a general Linux/*NIX issue.

------------------------------------------------------------------------
Proposal:
------------------------------------------------------------------------
My opinion is, that we need NOW a "central instance" that knows about the MM system state and can
distribute information about the MM system. For example:

- Which MM backend (gstreamer, arts, MAS, NMM, ...) is the user at the machine using?
     So xmms, mplayer, you-name-it could ask and auto-configure itself
- What capabilities has the soundcard / the MM backend
     e.g. "can record", "has 30ms latency" "has unknown latency" "has 20 channels", "has unlimited channels (software mixing)", ...
- It can be asked whether certain access is possible
      e.g.: Can i currently record PCM on device#1 ?
- It can be asked to grant those accesses
      e.g.: Grant me the possibilitly to record PCM. (This call could return with "granted" or "not granted - full-duplex cannot be set" ).
- Allows notifications to be sent to all MM applications
       e.g. "sample rate change"  (like palette-change and resolution-change for GUI's)
- Is hardware video overly supported
     just as an example for a non-audio property
------------------------------------------------------------------------

As far as I am have thought about this, many things could be implemented in a dynamic C library, e.g. libunixmm.so. The point is, it
must be more than trivial to use - anybody implementing a MM application must be able to adapt to it in a couple of lines of code.
The most important things would be IMO the "which backend to use"-query and the "access/grant"-stuff.

I believe, it can be as easy as:
-----------------------------------------------------------------------------------------------
int num_backends = unixmm_get_audio_backend_count();
if ( num_backends > 0 )
   char* backend = unixmm_get_audio_backend(1);     // 1 = Users' preferred backend
   // if backend == "GStreamer" ... else ....
[...]
-----------------------------------------------------------------------------------------------

This is my proposal. So I do ask for feedback:
Does anything I said make any sense?
Is it worth evaluating?
Should I immediately try a prototype implementation?

Any comment is appreciated. 

Thanks  for reading,
         Christian