1 files changed, 52 insertions, 0 deletions
diff --git a/tde-i18n-es/docs/tdemultimedia/artsbuilder/porting.docbook b/tde-i18n-es/docs/tdemultimedia/artsbuilder/porting.docbook
new file mode 100644
index 00000000000..0ecbc29d67b
--- /dev/null
+++ b/tde-i18n-es/docs/tdemultimedia/artsbuilder/porting.docbook
@@ -0,0 +1,52 @@
+<!-- <?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
+>Portando aplicaciones a &arts;</title>
+
+<sect1 id="using-artsdsp">
+<title
+>Utilizando &artsdsp;</title>
+
+<para
+>La utilidad &artsdsp;, <link linkend="artsdsp"
+>descrita con anterioridad</link
+>, permite que la mayoría de aplicaciones antiguas que trabajan directamente sobre los dispositivos de audio, funcionen correctamente con &arts;. Las aplicaciones escritas para utilizar el Enlightenment Sound Daemon (<application
+>esd</application
+>) también funcionarán en la mayoría de casos ejecutando <application
+>esd</application
+> sobre &artsdsp;. </para>
+
+<para
+>Esto ofrece una buena solución a corto plazo para portar aplicaciones existentes a &kde;. Sin embargo, no permite que la aplicación utilice todas las posibilidades de &arts;, tales como el uso de módulos y transmisiones multimedia que no sean de audio digital. Si la aplicación va más allá de ejecutar archivos de audio, es lógico añadir soporte nativo para &arts; a la aplicación. </para>
+
+<para
+>Utilizar &arts; también significa que la aplicación no tiene mucho trabajo que hacer, ya que puede utilizar las funciones de &arts; para manejar codecs y diferentes tipos de medios, así como tener control sobre el hardware de sonido. </para>
+
+</sect1>
+
+<sect1 id="adding-native-arts-support">
+<title
+>Añadiendo soporte nativo para &arts;</title>
+
+<para
+>Al utilizar &arts; se encontrará con diferentes <link linkend="arts-apis"
+><acronym
+>API</acronym
+>s</link
+> para escoger. La decisión sobre cual utilizar depende de una serie de factores, incluyendo el tipo de medio que se utilizará (sonido, &MIDI;, &CD; audio, &etc;), las características requeridas a la <acronym
+>API</acronym
+>, y si se está programando en C++. En la mayoría de los casos la elección debería ser relativamente obvia en base a las necesidades. </para>
+
+<para
+>En los casos de portabilidad entre plataformas, las aplicaciones que deban poderse ejecutar en plataformas diferentes al &kde;, no pueden depender de que &arts; esté presente. Un buen método para adaptarse a diferentes ambientes multimedia es el uso de conectores. Si además la <acronym
+>API</acronym
+> de los conectores es abierta y está bien documentada permitiremos que otras personas diferentes al desarrollador de la aplicación puedan implementar un conector para &arts;. </para>
+
+</sect1>
+
+</chapter>
+