Some ideas for the aRts-replacement

[Alexander Neundorf]

On Thursday 19 February 2004 23:00, you wrote:
> On Thursday 19 February 2004 21:00, Alexander Neundorf wrote:
> > I am arguing against putting everything (OSS handling, ALSA handling ->
> > hardware access, stream mixing, decoding, plugins) into one item.
>
> That's reasonable and I agree.  But this started off more like "let's have
> the application do everything themselves" or something like that -- at
> least I think that if that wasn't the intention it wasn't clear.

Ah, ok :-)

...
> meaningful.  Let's say:
> "sound server" -- a hardware abstraction, i.e. Jack or ESD
> "media framework" -- a library or set of libraries that may or may not
> specifically work with a "sound server" to decode and generally handle
> *audio and video* media.

ok :-)

...

> This is something similar to what we're talking about, but I really don't
> think the scope is well understood in this discussion.  I don't think this

Yes, maybe.

> is something that will be scraped together in a couple of months.  Just the
> core of GStreamer is about 75,000 lines of code -- the plugins are another
> 200,000.
> I don't know anyone in KDE that really wants to work on such a framework or
> deal with writing all of plugins for input and output.  Not to mention that

Yes, we don't want to.
IMO we need something usable without fancy stuff. No multi-channel mixing, no 
effect plugins, no network transparency, no equalizers, no video, ...
Still it should be able to play the most common file types (wav, mp3, ogg, 
maybe flac) and support OSS and ALSA (and other platforms). 
I really think this can't be that hard (don't we have all the code inside  
arts ?). For simple tasks this should be enough. For more advanced things it 
should be possible to use 3rd party projects. Maybe provide a KDE-ified 
interface to use them.

> we need a video solution and we haven't even scratched the surface of the
> issues that arise with that.  

I really don't think we can successfully do this or should even try it. This 
should be left to the video app/lib, i.e. xine and mplayer. These both are 
big projects with enough people. Let's just use what they produce.

> Basically I don't want to see another aRts --
> something that starts with good intentions but kind of bombs due to lack of
> contributors and a mis-understood scope at the time of design.

Yes.

> Really what you're saying is that *you* don't normally need more than two,
> and *your* soundcard supports two and that *you* would understand what's
> going on if you had three opens on /dev/dsp and one of them didn't work on
> your *Linux* system.  I don't think it's fair to assume that all of those
> hold true for "normal" users.

Maybe, but actually I think I'm right.
I mean, what do users do with sound ?
Listen to music, notifications, watching movies, watching/listening short 
audio/video clips.
Anything else which isn't special purpose ? 

Now, what of these things do they usually at the same time ?
Watching movies and listening to music usually not. Music is running all the 
time, when they decide to watch a video they will turn the music off. 
Notifications happen only from time to time. If they can't happen while a 
short clip is played, no big problem.

If the user considers it to be a big problem, he should use another sound 
server, e.g. arts or MAS. 

This can even be the default. I'd vote for MAS, at least it's maintained and 
developped by shiman inc. for by X.org http://www.mediaapplicationserver.net

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