Re: GNOME 2 Sound Architecture and APIs?

[John Heard <John Heard Sun COM>]

Elliot Lee wrote:

>
> It confuses "sound server" with "media framework", and has a lot of
> complex stuff that has no place in a sound server, e.g. MIDI sequencing,
> special effects filters, and sound synthesizers. For crying out loud, it
> has its own RPC system (MCOP), complete with IDL compiler...
>
> This will make life less than optimal for GStreamer, Bonobo-Media, GMF, or
> whatever else catches people's fancy, since they seem the right place to
> put the fancy features and would have to fight with their aRts overlap. It
> will also annoy people who want to have a simple sound server for use in
> games or embedded platforms.
>
> The only real reason people are agreeable to aRts is because KDE uses it,
> and the god of desktop unification must be appeased. It does not sound to
> me like most people have made coordinated efforts to determine what the
> sound server requirements are, and whether aRts meets those requirements.
> Take the time to convince yourselves that aRts is sound technically, as
> well as politically, before jumping on the bandwagon.

Total agreement from me on this so far.

>
>
> asd purports solves the esound problems I know of in a more lightweight
> manner, but does not appear to be completely finished yet. Correspondence
> with the author may be wise.
>
> Of the possible solutions...
>
> esound risks to manage:
>         . That it might detract from the attractiveness of the
>         GNOME 2 platform.
>         . That sticking it would waste a chance to find a superior
>         solution.
>
> asd risks to manage:
>         . That it might not meet GNOME requirements for a sound server.
>         . That it might not be finished/stable in time for the GNOME 2
>         release.
>
> aRts risks to manage:
>         . That it might not meet GNOME requirements for a sound server.
>         . That its requirements (resource-wise and dependancy-wise)
>           are excessive (even if the C API is used, the server is still
>           in C++, which so far has not been a requirement for GNOME).
>         . That it may be selected as an acceptable sound server solution,
>         but may wind up providing a media framework solution without
>         being evaluated for this role.

Lets please not go down the C++ track nor MCOP routes please. These will both
come back to bite in nasty places.

John