MAS in KDE

[Stefan Westerfeld]

   Hi!

On Wed, Mar 05, 2003 at 09:11:59AM +0100, Roger Larsson wrote:
> On Wednesday 05 March 2003 09:00, Roger Larsson wrote:
> > On Wednesday 05 March 2003 08:49, Stefan Westerfeld wrote:
> > I have been thinking about a really simple system where the client sends
> > either:
> > a) The filename (url?), preferred for local files - cacheable
> > b) The file contents in any format but raw, formats contains decoding info
> > using a pipe/socket to the server.
> > c) Program generated audio with a header, followed by data, pauses OK.
> > using a socket/pipe/...  to the server.
> > [The server needs to decode the header, load the decoder pluggin, and go]
> > 
> 
> Forgot the point of it (arts is close/there today...)
>  - the server could be replaced, keeping the interface
>  - really little code needed on the client for the simplest case
>    (playing a local file)
>  - all media file types can be supported (video, mp3, ogg, MIDI...)
>  [for video the destination window have to be transfered to the server]

Well, first of all, you need not implement a new protocol to be able to do
this. We already have MCOP for this. Thus, you can simply implement an MCOP
service.

Then: we do already have such an MCOP service. You might want to read all
the IDL files in arts/soundserver, to see what we currently do.

Finally: yes, I think if we were to seperate the wave cache from the sound
server, we would have achieved another piece of improving the architecture.

That way, we could work on a broken sound server (like ESound), and still
use our current PlayObject infrastructure to output wave files when needed.

It also has the additional benefit that this wave cache process could really
close its output if it has nothing to do. Currently, aRts always runs, and
records silence, scales silence and plays silence. This has two undesirable
effects:

(1) the time until the sound of knotify is played depends on a configurable
  overall system latency, because there will always be zero padding in the
  output buffer of aRts

(2) there is unnecessary CPU usage caused by unnecessary calculations, and
  unnecessary memory usage, and unnecessary context switches, and a lot of
  other things

Thus, yes, this would be more useful the way you suggest it. At least for
those users that do not want to run aRts all the time, this would improve
the situation a lot. You could for instance simply use OSS or ALSA for the
wave cache, without the need to start artsd, if you're just running kmail
under GNOME.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan at space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-