[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Proposal: libunixmm.so (about the Comparison: MAS, GStreamer, NMM)
From:       Christian Esken <c.esken () cityweb ! de>
Date:       2004-09-08 23:14:33
Message-ID: 200409090114.33948.c.esken () cityweb ! de
[Download RAW message or body]

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
 
_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia


[prev in list] [next in list] [prev in thread] [next in thread]