Some ideas for the aRts-replacement

Alexander Neundorf neundorf at kde.org
Thu Feb 19 20:00:15 GMT 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> On Thursday 19 February 2004 18:42, Arnold Krille wrote:
> 
> > - A simple sound-interface apps can use for notifications/simple_playback 
> > like "Soundserver play this file" and some checking wether it succeded or 
> > not...
> 
> Again, going on this nomenclature -- to my knowledge aRts is the only sound 
> server that does decoding.  MAS may do that too, not really sure.  But most 
> "sound servers" are basically just a system for mixing stuff and forwarding 
> it to the hardware.  I think that's what Guillaume and Alex are arguing 
> against -- when that's all the soundserver does there are cases where you 
> don't need one.

I am arguing against putting everything (OSS handling, ALSA handling -> 
hardware access, stream mixing, decoding, plugins) into one item.

I am for an easy to use API where I can say "play this file now" or "start/
pause/stop playing this file" with some progress signals etc.

This implementation should not depend on the implementation of the hardware 
access, or better the way the decoded samples are transferred to the sound 
card (over a network or not). It should be possible to choose the "backend" 
which should always have the same interface.

> - Some kind of "Sound System" which is the layer between apps wanting sounds 
> played back or data streamed to whatever sound-server or hardware the user 
> is using. This one should check/know wether the sound-server is able to 
> decode and if not decode inprogress. Perhaps some kind of mixing can also be 
> done for raw-streams.

Again, sound servers don't usually decode stuff, and what the guys on 
core-devel were suggesting was something that handles the decoding...

> > Just for a little bit of background -- at least for GNOME GStreamer will 
> > be that layer (and I'm interested in other similar frameworks as well...).  
> > It handles encoding, decoding and effects (which to an extent are needed 
Sorry, I don't understand completely, can you please explain a bit more ?
Is gstreamer simply a decoding software ? Does it also handle OSS/ALSA ? 

> > -- think volume, video brightness, etc.)  If we decide to add something
> > KDE specific to do that I just feel like we're getting back into something
> > that will be both incomplete and likely poorly maintained.  But hopefully 

Yes, and that's why we should have something not too complex as a basic 
solution, but also support other advanced solutions like gstreamer or MAS 
(...but which we don't develop ourselves). I'd even go that far if somebody 
wants to have the full power of some special sound server, like maybe 
gstreamer, he might use its native API.

Most people only want to hear music and from time to time maybe some 
notifications. For a soundcard with two channels this is no problem, he can 
even adjust the level for each channel individually :-)

Bye
Alex
-- 
Work: alexander.neundorf at jenoptik.com - http://www.jenoptik-los.de
Home: neundorf at kde.org                - http://www.kde.org
      alex at neundorf.net               - http://www.neundorf.net



More information about the kde-multimedia mailing list