From kde-core-devel Sat Sep 11 20:19:10 1999 From: Stefan Westerfeld Date: Sat, 11 Sep 1999 20:19:10 +0000 To: kde-core-devel Subject: Re: aRts as KDE2.0 audio server X-MARC-Message: https://marc.info/?l=kde-core-devel&m=93708118808420 Hi! On Wed, Sep 08, 1999 at 06:32:26PM +0200, Martin Vogt wrote: > On Wed, Sep 08, 1999 at 12:59:13AM +0200, Stefan Westerfeld wrote: > > On Tue, Sep 07, 1999 at 10:26:38PM +0200, Martin Vogt wrote: > > > ok here the new results, with the "example_mixer_nosat.arts" > > > This looks better :) > > > But still it uses : > > > > > > 19288 m_vogt 15 0 6512 6512 3464 R 0 21.4 10.3 0:10 artsserver.b > > > 19297 m_vogt 8 0 1044 1044 824 R 0 3.6 1.6 0:00 top > > > > > > 20 % of my cpu, when nothing is played (!). > > > > Well, yes - I think I need to implement a "power saving" function or > > something like that, which does disable unused components of a flow > > graph. I will probably work on a special low CPU usage only audio > > server set of structures/modules, which should bring down the CPU load > > quite a bit further. > > > This is a must. > Its inaccepible to use 20 % of cpu if nothing is done. It's due to the mixer stuff - which was rather thought for real audio mixers with millions of buttons (like the ones in studios), which shall be always running - however if ESD has no means to set the volume of an incoming stream anyways, we should probably do the benchmarking without any kind of "processing", besides simple 1:1 mixing of all channels to be fair. > > By the way: standard mixing behaviour... what would be good here? I know > > that you would feel better if calling artsmp3 just started playing, > > without any further user interaction. I also know you want dynamically > > added mixer channels (instead of statically configured ones). > > > This is a must as well. > You don't need a mixer for one channel at all. > (I think this is the case for 99% of the time) > > But you need one if you have more then one channel. Well - yes - busses do just that - you don't need the mixer at all - you simply can assign everything to the same channel and it will get mixed anyways. > > So the question arises: how loud shall the first mp3 be played? 100%? > > 50%? What should happen if 16 bit are not enough to do all the output? > > Clipping? Saturation filter? > > For one channel the setVolume call goes directly to the mixer. > For more, it must be done in software. I won't implement that in aRts - you can't mix signal processing with a mixer and whatever and integrate it. If somebody wants to use his hardware mixer to achieve a task (he might for instance be able to replay two streams with his soundcard, and have to output stereo channels for that), he should use kmix. If he wants to have it handled by software, he should use some controls in aRts - if he doesn't need a "nice" software mixer emulation, there is no need to do one, aRts can do 1:1 mixing just as esd does. > Btw: ESD cant do this. You have no setVolume call to give > the daemon the hint how loud this sample should be. > > ESD has a few other shortcomings as well (cannot re init streams, > because the setting of framesize,channels and rate is tightly bound > to the open socket call) > > > The problem to have different sample sizes (eg mono 8 bit and stero 16 > bit) with different frequencies, well. > BeOs can't handle this. ESD can't handle this. > Does any one know what Windows does in this case (crash?) > > I still think: > > audioserver != multimedia framework. > > Why is it not possible to use esd _and_ the CORBA interface together? > > I would prefer a small, tested audioserver which does not more > than take stream mix them and pass them to /dev/dsp. My opinion is: IF you have an audio server (or dsp wrapper), it should be possible to achieve all tasks with that. After all, if you have only one application which isn't able to use it, you'll always need to start and stop it, and while that one application is running, you won't have an audio server at all. So an audio server is only a good audio server, if you can achieve every task with it you could achieve without audio server as well. Of course, the audio server may require you to do the task differently (e.g. use a special API). The problem is that esd excludes the whole range of realtime applications. Arts is in its current form can synthesize just in time what I play on the keyboard. It couldn't when sending its output to esd. KHdRec can do harddisk recording. It couldn't when sending its output to esd. Sure - there are not many "real" audio applications for linux yet, only some mp3 player and some trackers. But I want them to be there for linux in the future, and so I can't accept esd as audio server. Of course this argumentation only works if all people adapt their application to work with a complete framework solution like an aRts based KDE multimedia framework. You gain nothing from not using esd if nobody uses the better alternative instead. > The multimedia framework (with the whole CORBA overhead) is seperated. > The framework should support "remote decodeing of eg. mp3" maybe have > this saturation filters (what does this actually do?) and maybe The saturation filter tries to avoid clipping by rather distorting the signal if it is too loud (softening out the peaks). While I think it is useful for music applications where you never can know how many voices you'll have and how loud they might be, you probably don't need to do that kind of effort when you are just replaying one mp3 for instance (you know how high the maximum peaks can get anyway). > have some other filters as well (eg fft for these nice winamp analysis) > But then the framework sends the data (finally) to the audioserver. Well I can't see how this seperation could be done while still allowing all multimedia apps. If you have a better solution than mine, please tell me. > I don't like the idea to use CORBA only to play a simple wav file. Other people might not like the idea to use CORBA just to open a jpg file with Konqueror - but as far as I know, it will be done. Now to the rational reasons, why not using CORBA: - you may think it is slower (in CPU sense) as it is NOT used for signal transmission, there is no reason while a CORBA based audio server should be slower than a non CORBA based - you may think its more complicated as you can write wrapper libs for CORBA just as for esd internals, I see no reason why this should be the case - you may think it uses more memory I agree here - there have been no benchmarkings on that yet, but before you start doing them, I'd like to have aRts running with tinymico (that is with ministl) So I personally can't recognize any valid reasons why you wouldn't want to use CORBA. Sure - aRts is a lot more complex than esd - but thats not due to CORBA, but since a multimedia framework *IS* more compilcated to achieve than a simple program which mixes some data in a fixed manner - in fact, I think I could write the latter in a week and it wouldn't be worse than esd, while the former took me two years (well, not uninterrupted work, to be fair) and isn't finished yet. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *-