1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
|
<!-- <?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>
|
