aRts audio server
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

216 lines
9.3 KiB

  1. - fix problems with REGISTER_IMPLEMENTATION:
  2. => sometimes, global constructors don't work, so we'd better get rid
  3. of them entierly ; instead, an init function needs to be added to
  4. dynamically loaded modules
  5. - get rid of all error handling done by assert ; thus, one by one review
  6. each assert if it can happen under any circumstances if yes, it needs
  7. to be replaced by some other mechanism
  8. - report errors properly if some component could not be loaded ; right
  9. now, it fails within assert(skel) in generated code, which doesn't
  10. help users much to debug the problem
  11. - VERSION-INFO for modules?
  12. - md5auth isn't initialized properly in conjunction with ARTS_SERVER
  13. - make it possible to use C API and C++ API together
  14. - FIXME: what to do about apps which are not threaded but nevertheless
  15. want to use the engine?
  16. - gsl: rounding should be used even for unsigned conversions
  17. ## MCOP Core Infrastructure
  18. - offer sampleprecise timing
  19. - resource management (i.e. locate resources like "samples" or "structures"
  20. in a similar uniform way KDE does with TDEStandardDirs)
  21. - check why adding thousand non-running objects degrades scheduling
  22. performance quite a lot
  23. - recursive scheduling again (with loops & cycles)
  24. - obsoleting: use V2 implementations even if user requests a normal
  25. implementation, since they have a newer version
  26. - error notification for connection breaks - this would enable intelligent
  27. clients to immediately know when something goes wrong, so they can terminate
  28. sanely instead of crashing
  29. - mcopidl: use unsigned char arrays instead of strings for inline marshalled
  30. data in idl files - this will fix the "maximum string length" warnings and
  31. while doing this improve space and speed
  32. - try to clean up notification manager, code generation and _copy() _release()
  33. style referencing across functions in notification and Dispatcher - the
  34. alternatives seem to be even more automatic referencing magic, or freeing
  35. objects only if the stack is empty (idle freeing)
  36. - fix generated code for struct Foo { object bar; }
  37. - fix fallback into higher namespaces, the following idl file should be accepted
  38. module A { interface Z; module B { interface Y : Z { }; }; };
  39. - debugging: if two alternating messages are emitted, the message compression
  40. doesn't work, and the user will be flooded with debugging message, the X
  41. server will crash, and so on - a possible strategy would be:
  42. * make an always present MCOP object which can receive confirmations from
  43. artsmessage
  44. * start artsmessage as usual, but tell it about the MCOP object, so that
  45. artsmessage can
  46. - tell the MCOP object if it is done
  47. - query the MCOP object for the repetition count of the message
  48. * queue repeated messages as long as they are still visible on screen
  49. ## aRts SoundServer
  50. - export configuration interfaces from the soundserver (so that
  51. you can see and change the autosuspend timeout for instance)
  52. - support multiple artsd instances on one computer (like multiple displays),
  53. and think of a clever way to register them
  54. - more support for different audio input/output methods (i.e. SDL)
  55. - support channels != 2
  56. - expand capabilities of shell utils (making them eventually as powerful as
  57. artscontrol, or better ;)
  58. - make it possible to share a cookie between multiple hosts (like storing it
  59. in nfs mounted home directory)
  60. - make it possible for artsd to cascade audio input/output to another artsd
  62. ## C API / artsdsp
  63. - implement an arts_stream_flush for writing half-written data packets
  64. (useful for implementing SNDCTL_DSP_POST in artsdsp)
  65. - move to CSL (CSL a new common sound layer, especially intended to be
  66. compatible between Gnome and KDE)
  67. - pkgconfig file
  68. - it might be useful to allow clients on big endian systems to pass their
  69. 16bit data with their native byte order - for compatibility with older API
  70. versions, its required to make this an extra parameter
  71. as an efficiency bonus, one could also make the wire representation then
  72. 16bit big endian, which requires support from the sound server though; its
  73. not required to implement the feature, though (which is probably useful
  74. for application writers on 16bit big endian machines)
  75. ## GUI Support
  76. - port visual objects (beginnings are in tdemultimedia/arts/gui)
  77. - hbox, vbox
  78. - gui generation
  79. - hints via mcopidl
  80. ## aRts Modules / Signal processing
  81. - midi recording for Brahms
  82. - StereoEffectStack should support reordering (and probably listing) effects
  83. (maybe backport noatuns version)
  84. - hard disc recording
  85. - allow progressive loading for wave files
  86. - write blockwise caching (not requiring whole samples to be held in memory)
  87. - akai support
  88. - better interpolation / resampling
  89. - the Resampler class should do big endian and float as inputs
  90. - LADSPA support
  91. - provide a GUI for stereo_pitch_shift
  92. ## kcmarts
  93. - add restart option to the control panel, so that you can restart artsd easier
  94. if it crashed (it never crashes, does it ;) - close #38417 when done
  95. ## artsbuilder (and runtime)
  96. - allow to give additional parameters (like names for sample files to play)
  97. through .arts-map files
  98. - more examples (instruments, songs and such)
  99. - gui editing (or should is it better to write a new editor for that)
  100. - live editing of running structures
  101. - component bar where you can choose components without going through all
  102. these submenus
  103. - property editor (like in delphi)
  104. - support pressing "return" in the various dialogs and close them on doing
  105. that (rather than always having to click "ok" with the mouse)
  106. - i18n fixes
  107. ## artscontrol
  108. - be able to remove midi ports *KDE2.2*
  109. - add a mixer
  110. - persistent state (Arts::Environment), so that the environment
  111. can be restored on next login (or per song or something like that)
  112. - edit .arts-map files visually
  113. ## Optimization (this section contains various optimization ideas)
  114. - use no floats for adressing the fractional part in resampling but integers
  115. (that will be MUCH faster)
  116. - use short int for i16le resampling, instead of using a long and adding
  117. sign manually (faster at least on athlon)
  118. - tune the MCOP transfer protocol
  119. * rewrite Buffer not to use vector<char> to store data, but malloc'd blocks
  120. * try to write "zero allocation" invocations, that means, try not to allocate
  121. memory on performing an invocation. For instance Buffers could be kept in
  122. pools, and be reused for further invocations, without the need to realloc
  123. another memory block
  124. * try to minimize the amount of copies of data, possibly even using something
  125. like sharedmem to share data between the sending and receiving buffer
  126. * hardcode frequently used calls in the Arts::Object interface
  127. ## Documentation / Web
  128. - improve kdoc comments everywhere
  129. - write incomplete sections in The aRts Handbook; improve formatting
  130. ## Misc
  131. - put streamwise blocking into MCOP, see to read really ugly
  132. source which lives without that feature
  133. - implement plugins that transfer non-standard datatypes such as midi events,
  134. video frames, fft packets, oscilloscope views, ... (which was impossible
  135. with aRts on CORBA)
  136. - make aRts run inside Brahms, KWave or your-favorite-other-app, to do
  137. signal processing where it is needed (similar to AudioLogic Environment,
  138. for instance)
  139. - convince other people to use aRts, so that the usefulness of universal
  140. plugins written for the API increases
  141. - when being crazy, implement gatewaying from MCOP to DCOP, CORBA, XMLRPC
  142. or whatever else might be useful
  143. ## Interoperability (GNOME/C)
  144. - write a gartscontrol (in C) as native Gnome/Gtk app
  145. - further work on CSL
  146. - C language binding, based on glib
  147. - mcopidl code generation for C
  148. ## FlowSystem changes:
  149. It would be nice if the flowsystem became more "detached" from the normal
  150. operation, making it ideally runnable in one or more thread dedicated for
  151. audio processing.
  152. Flowsystem transactions:
  153. these group operation like: starting, stopping, connecting, disconnecting,
  154. ... to transactions which will later (asynchronously) executed by the
  155. flowsystem
  156. Example: problematic assertion
  157. assert(done[i] <= samples); /* */
  158. the problem with the assertion here is this - suppose some object reacts
  159. in a way on some signal that will lead to the creation of new objects,
  160. then those will get into the flowsystem, and we can't ultimately say
  161. anything about how far these have been calculated so far
  162. extremely problematic in this context are so-called call-ins, that is
  163. you do calculateBlock, and during this, the dispatcher mainloop gets
  164. called for some reason (I hope that this does not happen currently) -
  165. if that would hypothetically happen, then there the whole flowsystem
  166. could get restructured (because i.e. ordinary midi events could be
  167. processed)
  168. ## libartskde
  169. * ensure that there is a pair of classes, like KAudioPlayStream and
  170. KAudioRecordStream (or whatever they should be called) that can do
  171. approximately what the C API can do
  172. * don't export implementation details in the API - for instance
  173. KAudio(Play|Record)Stream should probably only inherit from QObject, and
  174. only "use" some aRts objects to do the actual work - that way, they can
  175. be changed/modified more easily afterwards
  176. * use Qt signals/slots as callbacks (at least as one possibility) for
  177. "please produce new audio data" / "here is new audio data" - that way,
  178. polling isn't necessary any longer