The &artsdsp; utility, described previously, allows most legacy sound applications that talk to the audio devices directly, to work properly under &arts;. Applications written to use the Enlightenment Sound Daemon (esd) will also work in most cases by running esd under &artsdsp;. This makes a good short term solution to porting existing applications to &kde;. However, it does not allow the application to directly take advantage of all of the power of &arts;, such as using modules and multimedia streams other than digital audio. If the application goes beyond simple playing of sound files, it usually makes sense to add native support for &arts; to the application. Using &arts; also means that application does not have to do as much work -- it can leverage the functions in &arts; to handle issues like codecs for different media formats and control of the sound hardware. When using &arts;, you have a number of different APIs to choose from. The decision of which to use depends on a number of factors, including what type of streaming media is used (sound, &MIDI;, &CD; audio, &etc;), the API features required, and whether it is written in C++. In most cases the choice should be relatively obvious based on the required features. For cross-platform portability, applications that need to run on environments other than &kde; cannot rely on &arts; being present. Using the plug-ins paradigm is a good way to support different multimedia environments. Making the plug-in API open and documented (especially for closed source applications) also has the advantage of allowing someone other than the application developer to implement an &arts; plug-in.