Some ideas for the aRts-replacement

[Scott Wheeler]

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

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

Also reasonable.  But let's define some precise terms -- "backend" isn't 
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.

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

GStreamer is a plugin based media framework.  The core handles moving stuff 
around between the input and output plugins and provides a framework for 
stuff like meta data and of course the plugin APIs.

Input plugins would be things like Ogg Vorbis, MPEG Video, MP3 or FLAC.  
Output plugins are i.e. OSS, Xv (video), EST, aRts, Jack and so on.  Then 
there are effects plugins that would implement anything to make changes along 
the "pipeline".

It's a "framework" or a "library" or whatever you want to call it.  There's no 
server or hard coded output method.

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 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 
we need a video solution and we haven't even scratched the surface of the 
issues that arise with that.  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.

> if somebody wants to have the full power of some special sound server, like 
> maybe gstreamer, he might use its native API.

Sorry to be pedantic here, but I think semantics have made discussion more 
confusing than it needs to be.  GStreamer isn't a sound server.  aRts is not 
just a (or even a normal) sound server, etc...

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

There are a few fundamental flaws with that logic though.

First, not all soundcards support multiple opens on /dev/dsp.

Second, given that the number two is arbitrary (i.e. mine support 16) -- but 
let's play with that number a little bit -- it's not difficult to imagine a 
situation where a "normal" user would want more than two and would be pretty 
confused in the case where sound didn't play because two things were already 
using /dev/dsp.  Just imagine having notifications with one open, a music 
player paused and trying to watch a video.  There's three right there.  I 
don't think that's such an off the wall situation that "normal" users would 
never have that happen.

Third, while my sound card supports 16 opens, the mixer interface doesn't 
support changing the levels of all of those -- in fact there's just one "PCM" 
mixer element.

Fourth, the situation is different on non-Linux platforms -- different drivers 
with different capabilities.  Almost everything we've said has assumed that 
the users are on Linux.

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.

- -Scott

- -- 
The world is full of magical things patiently waiting for our wits to grow 
sharper. 
- --Bertrand Russell
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFANTHsQu0ByfY5QTkRApU0AJ4p/UuABbHjzTNziG9YyMjgUvAppgCgh8ir
A6QG8Gi9zpH/3zKVPUylTpY=
=kmjX
-----END PGP SIGNATURE-----