From kde-core-devel Mon Sep 06 17:52:31 1999 From: Stefan Westerfeld Date: Mon, 06 Sep 1999 17:52:31 +0000 To: kde-core-devel Subject: Re: aRts as KDE2.0 audio server X-MARC-Message: https://marc.info/?l=kde-core-devel&m=93663971826494 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 *-