[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic