From kde-multimedia  Thu Sep 09 20:08:21 2004
From: Lennart Poettering <mzxqr () 0pointer ! de>
Date: Thu, 09 Sep 2004 20:08:21 +0000
To: kde-multimedia
Subject: Re: Proposal: libunixmm.so (about the Comparison: MAS, GStreamer,
Message-Id: <20040909200821.GB12655 () seth2 ! intheinter ! net>
X-MARC-Message: https://marc.info/?l=kde-multimedia&m=109476053529717

On Thu, 09.09.04 01:14, Christian Esken (c.esken@cityweb.de) wrote:

> 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
> 

Another idea:

Instead of having such a complicated API, why not use a simple DBUS
interface for synchronizing access to the sound devices? i.e. before
accessing the audio device an application issues a special DBUS
command 'request_device("oss", "/dev/dsp")'. If nobody responds, the
device should be free. The application that currently has access to
the device could either respond with "DENIED" if it has a good reason
for not giving up access to the audio device, or respond with "AGREED"
in which case it releases the audio device. The latter would be
implemented for sound servers. After using the devices the application
issues 'release_device("oss", "/dev/dsp")' which is a hint for sound
server to reopen th eaudio device.

This would require minimal DBUS bindings for every client application
and sound server that wants to make use of this. artsd and esd don't
need to be patched for this. An external DBUS aware python script
could just issue somethin like a "killall esd".

A minimal client library could be written which supports just the two
calls.

Lennart

-- 
name { Lennart Poettering } loc { Hamburg - Germany }
mail { mzft (at) 0pointer (dot) de } gpg { 1A015CC4 }  
www { http://0pointer.de/lennart/ } icq# { 11060553 }
_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia