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.
65 lines
2.4 KiB
65 lines
2.4 KiB
<!-- <?xml version="1.0" ?>
|
|
<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd">
|
|
To validate or process this file as a standalone document, uncomment
|
|
this prolog. Be sure to comment it out again when you are done -->
|
|
|
|
<chapter id="porting">
|
|
<title>Porting Applications to &arts;</title>
|
|
|
|
<sect1 id="using-artsdsp">
|
|
<title>Using &artsdsp;</title>
|
|
|
|
<para>
|
|
The &artsdsp; utility, <link linkend="artsdsp">described
|
|
previously</link>, 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
|
|
(<application>esd</application>) will also work in most cases by running
|
|
<application>esd</application> under &artsdsp;.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="adding-native-arts-support">
|
|
<title>Adding Native &arts; support</title>
|
|
|
|
<para>
|
|
When using &arts;, you have a number of different <link
|
|
linkend="arts-apis"><acronym>API</acronym>s</link> 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
|
|
<acronym>API</acronym> features required, and whether it is written in
|
|
C++. In most cases the choice should be relatively obvious based on the
|
|
required features.
|
|
</para>
|
|
|
|
<para>
|
|
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 <acronym>API</acronym> 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.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
</chapter>
|
|
|