From kde-core-devel Tue Sep 07 16:13:48 1999 From: Martin Vogt Date: Tue, 07 Sep 1999 16:13:48 +0000 To: kde-core-devel Subject: Re: aRts as KDE2.0 audio server X-MARC-Message: https://marc.info/?l=kde-core-devel&m=93672003931491 Hi, here are the tests. They are done with the old "example_mixer_simple.arts" I will send the new examples after I found a working floppy disk. :) ESD: PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 1223 m_vogt 12 0 1888 1888 1676 R 0 16.3 2.9 0:13 mpg123 1218 m_vogt 4 0 416 416 324 R 0 5.0 0.6 0:03 esd ^^^^!! Now arts. First I must say, even if it does not play anything (!) it already uses 54% of my cpu? What the hell this artsserver is doing? polling? Nothing runs except arts:(P166 MMX) PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 1239 m_vogt 13 0 6636 6636 3464 R 0 54.0 10.5 0:41 artsserver.b ^^^^???? 1229 m_vogt 5 0 1028 1028 824 R 0 2.7 1.6 0:05 top Ok, now start a mp3 with artsmp3: 1239 m_vogt 14 0 6932 6932 3468 R 0 59.1 10.9 1:28 artsserver.b 1253 m_vogt 7 0 908 908 696 S 0 14.2 1.4 0:02 mpg123 1254 m_vogt 1 0 3816 3816 2904 S 0 4.0 6.0 0:01 artscat It clicks horrible. Then: It seems to me arts statically use eight audio channels even if I only use one. The mixer should be able to dynamically insert new stream. What if I want to mix more than 8 channels? To the suid problem: On Sun, Sep 05, 1999 at 05:40:41PM +0200, Stephan Kulow wrote: >>> 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. ... >I don't want to have such problems with KDE2.0. Thus, for serious multimedia >you'll need realtime scheduler priority. I refuse to start the server under root. If it is not possible to mix things together under a normal user id, then the concept is broken. (Esd _can_ actually mix thing together under a normal user id without clicks) Why is this not possible with arts? The assumption to do audio things always in realtime is not right: What if I want to convert mp3s into pcm samples and record them (as .wav) to harddisk? This is normally a background process which does not need realtime priority. I can understand that the CORBA approach may have an overhead. But this should not be _that_ high. And why should it be done with CORBA anyway if the user only want to mix audio streams? The concept to dynamically route streams through filter graphs is very fexible, but why should it be in the KDE _audioserver_? As I understand the concept of an audioserver it should do these things: * offer a well known (easy) interface * mix streams and send them to /dev/dsp There is no need in the _audioserver_ to route the streams. The upcoming multimedia framework should be a seperate library (seperated from the /dev/dsp wrapper) The audioserver is then a part of the framework and not the framework itsselft. I still vote for esd because it does exactly what an audioserver should do: Offer a (multi-write) wrapper for /dev/dsp (and not more) Btw: where are the other multimedia writer? Why I´m the only one on this thread? regards, Martin