[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: aRts as KDE2.0 audio server
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       1999-09-06 17:52:31
[Download RAW message or body]

   Hi!

On Sun, Sep 05, 1999 at 05:40:41PM +0200, Stephan Kulow wrote:
> > - it does require root rights for realtime operation
> >   => Currently, you are supposed to run aRts with realtime priority. There
> >   is a system call (sched_setscheduler) that ensures it gets the right
> >   priority (to avoid your mp3 to stop if you start netscape for instance),
> >   but it requires root rights. Arts can be installed suid root for that,
> >   and there may be a way to redesign some of its routines to run in non-
> >   realtimed mode as well. However, you'll get latency problems them, so
> >   installing suid root would be the best solution.
> Installing suid root is no solution at all! We want to get rid of them,
> not
> adding even more. And not even some that are meant to be an essential
> part
> of the desktop.
> I mean, who needs realtime priority for playing "you've got new mail"?
> Noone.

Today, I installed a fresh RedHat-6.0. I wanted to see if arts compiles
with that without problems. While compiling mico I wanted to play a little.
I started esd, and x11amp, and played a nice mp3 through esd. There were
ugly breaks, klicks, noise and whatever.

I don't want to have such problems with KDE2.0. Thus, for serious multimedia
you'll need realtime scheduler priority.

For your mail, it's no problem: that may arrive now, or later or never from
internet, so it makes no difference if you get the sound now or after ten
seconds.

But if I for instance close a window, I expect the sound to be there when
I click. No excuse that I am playing an mp3 right now.
Or gaming sounds or the sound of a video or of my TV card or whatever. It
has to be there when it's needed. Exactly then. While for one app, using
big buffers may work, for many apps it won't.

I agree with you fully, that an audio server, especially when it's network
transparent, should by no means be exploitable. Thus, the SUID root solution
(with dropping privileges after ten lines) seems far better to me than for
instance running the thing always as root.

> To admit it, I would rather go with esd than with this big app, that is
> more
> meant for real multimedia than for an audio server ;(
> If you can get together with the GNOMies and find a common standard that
> may
> be bigger and flexible - that's fine with me. But not for a KDE only
> version.
> 
> Another idea: Perhaps we can define a layer app that redirects
> application
> requests to whatever sound daemon runs? If a user wants your app (sorry,
> your typing is confusing) - he should be able to do so. If he runs GNOME
> and only some KDE apps - GNOME's sound server should be fine too. OK, if
> you say it's impossible - it is. But if it's reachable, I would see this
> as ideal goal.

Cooperation is good, when it's realistic. Well - I'll talk to Elliot about
the status of GMF, another option would be making aRts protocol compatible
to esd.

However, if you want an interface that uses all possibilities of aRts, it
can mainly be a wrapper around the existing aRts interface. But the GNOMies
probably don't want an interface as standardinterface to their soundserver
that they can't use fully because there is no aRts for Gnome currently.

Porting is a little difficult, mainly because they will want to compile it
against ORBit, and the ORBit-C++-Bindings are (as far as I know) not
complete. (And of course one would need to rewrite the Gui code in a 
toolkit independant manner).

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-

[prev in list] [next in list] [prev in thread] [next in thread]