aRts maintenance

[Michael Pyne]

On Tuesday 07 December 2004 04:59 pm, Stefan Gehn wrote:
> Am Dienstag, 7. Dezember 2004 16:27 schrieb Scott Wheeler:
> > On Friday 03 December 2004 10:25, mETz wrote:
> > > Everything more
> > > sophisticated will have to either choose a backend or make the
> > > audio-backend pluggable (as Amarok, JuK and soon Noatun do/will do).
> >
> > This has been said several times already, but since it seems to have not
> > sunk in:
> >
> > JuK will drop configurable backends.  They're not there because I love
> > configuration, but just because I wanted to offer an alternative to aRts
> > in the KDE 3 timeframe.
>
> And then JuK will depend on what? Why do you want to decrease features?
> It's not like everybody wants arts or gstreamer or whatever (no backend
> works on every hardware-configuration so people need a choice).

JuK is a music manager/tagger that happens to have a play button.  I won't 
shed a tear when configurable backends are dropped, because JuK doesn't need 
it.

The easiest thing IMHO would be to simply use the kdemm framework, and the 
framework chooses the right backend.  We don't need any advanced playback 
functionality with JuK, we just need some interface where we can do:

create a player
destroy a player
player->play(); // Resumes playback
player->play(KURL &file); // Plays file, stream, whatever
player->pause();
player->stop();
player->seek(unsigned long millisecond);

Now if this interface happens to map to gstreamer, fine.  Same thing for aRts, 
NMM, KDE::GST, native aKode, etc.  But JuK doesn't need multiple playback 
interfaces, it only needs one, the one used by KDE.  But it makes no sense 
for every KDE multimedia program to offer a choice of multiple player 
backends, because this is one of those situations where the user would 
honestly rather not even have to choose.

Regards,
 - Michael Pyne