'Re: Multimedia Planning for KDE3'

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

List:       kde-multimedia
Subject:    Re: Multimedia Planning for KDE3
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2001-09-03 12:43:47
[Download RAW message or body]

   Hi!

On Sat, Aug 25, 2001 at 08:16:27PM +0200, Stefan Westerfeld wrote:
>  * everybody who feels like implementing something for KDE3 posts a mail
>    to the kde-multimedia list describing what it is

So here is my list of changes for aRts. I marked items that I think that
should absolutely be done before KDE3 with an arrow. However, I hope that
most if not all can be done, but maybe I am just optimistic. ;)

 * Compatibility with legacy/broken OSS drivers

   can be achieved by integrating the threaded OSS patch into KDE3 - currently
   there are still issues being sorted out with that

   a possibility to further improve the quality would be writing/shipping an
   OSS compliance tester

 * I18N

-> all strings emitted by aRts should be internationalizable

 * Recording

-> the aRts C API should finally provide an API for recording

-> Arts::SoundServer(V?) should provide an interface for recording and
   streaming away

   it might be good finally following the KDE2 plan to provide a KAudioStream
   class in libartskde, to provide recording/playing streams in a nice, canned,
   easy-to-use way

-> there should be an end user application to record wav files from microphone
   in kdemultimedia using the new recording stuff

 * Video Embedding/Streaming

-> now that there are these new interfaces, they should be put-to-use in a
   satisfying way for end users in noatun/kaboodle (there might be issues
   to adress left)

 * Midi issues

-> the midi interfaces should finally support accessing sound card hardware of
   all fashions (ALSA, OSS-hw-synth) - that will mean a rewrite of some stuff,
   but is necessary for making the midi interfaces reasonable complete

   precise synchronization between midi/audio should be adressed

   libkmid could finally be moved upon the new midi interfaces

   the midi libs should be mainstream (i.e. kdelibs) and stable after KDE3

 * GSL Engine

-> thats probably the biggest change - aRts currently has an engine that
   decides which modules are to be calculated when, given a certain flow
   graph - this is called scheduling (and implemented in kdelibs/arts/flow/
   synthschedule.cc)

   the GSL engine is a complete replacement of the algorithm with the
   following characteristics:

    - it should be quite a bit more efficient in the common case

    - it supports dispatching calculations in multiple threads, which for
      instance allows to fully exploit multi processor systems

    - it allows putting module calculations in a seperate thread from the
      aRts main thread, thereby avoiding dropouts from lengthy aRts operations,
      such as for instance calling open() on an NFS drive

    - it is designed in a way to support advanced scheduling features that
      aRts currently does not support, that is
        * feedback loops (circles)
        * sample precise timing

    - it should allow achieving very very low latencies reliable (where very
      very low is something like 3ms) - aRts currently can't do this

    - it is implemented in plain C, using some glibisms, however it can be
      integrated into aRts with a glib-compat source in a way that it does
      not bring additional dependancies (no glib required)

   the GSL engine should first act as a drop-in replacement - however to take
   advantage of its capabilities, it will be necessary to make sure that the
   modules are implemented in a way that they can run in a seperate thread
   without interfering with anything else

   that means, that there will two types of modules: the old modules (which
   will still be running in the aRts main thread), and the hard-rt-modules
   (which will be able to run in the engine threaded)

   you will get the very very low latency benefit only if you use only hard-
   rt-modules, but everything should work with any mix of modules

   where is GSL from?

   GSL is designed by Tim Janik and me, and contains a lot of know how about
   music apps (Tim Janik has been working for years on Beast - best.gtk.org,
   and I have been working for years on aRts)

   can I look at it?

   yes (and it's a good idea to read gsl-mplan.txt):
   http://space.twc.de/~stefan/kde/download/gsl-2001-08-27.tar.gz

 * Other code in GSL

   GSL provides a sample cache which supports partial caching and preloading,
   the integration of that will get rid of the long outstanding issue that
   aRts always needs to load whole WAV files (or other formats), and support
   GigaSampler like "read-from-HD-and-play" style sample sets of huge size

   GSL should provide filter design code for butterworth, tschebyscheff-1/2
   and soon elliptic low/high and soon bandpass/stop filters, which can be
   wrapped in new aRts modules

 * Samples

   I have a prototype of a .PAT loader - you can import a whole timidity style
   patchset with that, which means that we have a useful GM-sample-set for
   aRts

   there is also AKAI loading code in kmusic/ksynth

   GSL provides another native format

   all of these might want to use the sample cache for efficient, preloaded,
   replaying

 * Mixer/Environments

   the work started with mixers/environments should be completed - for instance
   it would be very useful if the mixer could save/restore itself properly, and
   if it could also contain insert-stereoeffects and a master volume

   visualizations (led-bars) would be nice, but currently have the technical
   problem that they overload the MCOP layer easily, this can probably only
   be fixed by changing MCOP to deal more intelligently with change
   notifications

 * Making the MCOP component model more open to the world

   wildfox told me he is working on a DCOP/MCOP bridge

   a friend of mine is working on Java MCOP support

   another option would be UCOM gating, to support the standard QCom operations
   on aRts components - this might make it possible to use further standard
   KDE3 scripting facilities (based on Qt's dispatcher interface)

Decisions to make:

 * should the V2 interfaces be merged?
 * should aRts be moved to a seperate CVS module?
 * should aRts be binary incompatible, and if yes, which parts?

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-multimedia

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