summaryrefslogtreecommitdiffstats
path: root/tde-i18n-pt/docs/tdemultimedia/artsbuilder/apis.docbook
blob: 4249299b7cdec9a50361073a839ccc1be8240a3d (plain)
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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
<!-- <?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="arts-apis">
<title>Interfaces de Programação de Aplicações do &arts;</title>

<sect1 id="api-overview">
<title>Introdução</title>
<para>O aRts não é apenas um pedaço de 'software', também fornece uma variedade de APIs para uma variedade de fins. Nesta secção, será dada uma "ideia geral", uma breve apresentação do que essas APIs supostamente deverão fazer e como interagem. </para>

<para>Existe uma distinção importante a fazer: a maioria das APIs são <emphasis>independentes da linguagem e da localização</emphasis> dado que são especificadas no <emphasis>mcopidl</emphasis>. Isto é, você pode basicamente usar os serviços que elas oferecem a partir de qualquer linguagem, implementá-las em qualquer linguagem e não terá de se preocupar se está a falar com objectos locais ou remotos. Aqui está uma lista destes, em primeiro lugar: </para>


<variablelist>
<varlistentry>
<term>core.idl</term>
  <listitem><para>As definições básicas que formam o núcleo da funcionalidade do MCOP, como por exemplo o próprio protocolo, as definições do objecto, o mediador, o sistema de fluxo e assim por diante. </para></listitem>

</varlistentry>

<varlistentry>
<term>artsflow.idl</term>

  <listitem><para>Estes contêm o sistema de fluxo que você irá usar para se ligar às sequências de áudio, a definição do <emphasis>Arts::SynthModule</emphasis> que é a base de qualquer interface que emita sequências multimédia e, finalmente, alguns objectos de áudio úteis </para></listitem>

</varlistentry>

<varlistentry>
<term>kmedia2.idl</term>


  <listitem><para>Aqui está definido um objecto que poderá reproduzir conteúdos multimédia, o <emphasis>Arts::PlayObject</emphasis>. Os leitores multimédia como o 'noatun', o reprodutor multimédia serão capazes de reproduzir qualquer conteúdo multimédia para o qual exista um PlayObject. Por isso, faz sentido implementar os PlayObjects para os vários formatos (como o MP3, o vídeo MPEG, MIDI, WAV, ...) nessa base, e já existem alguns de facto. </para></listitem>

</varlistentry>

<varlistentry>
<term>soundserver.idl</term>

  <listitem><para>Aqui está definida uma interface para o servidor de som do sistema, o 'artsd'. A interface chama-se <emphasis>Arts::SoundServer</emphasis>, e implementa alguma funcionalidade como a aceitação de sequências multimédia da rede, a reprodução de amostras, a criação de outros objectos personalizados do aRts, e assim por diante. A transparência da rede está implícita devido à utilização do MCOP (como em tudo o resto, de facto). </para></listitem>

</varlistentry>

<varlistentry>
<term>artsbuilder.idl</term>
  <listitem><para>Este módulo define a funcionalidade básica do grafo de fluxo, isto é, a combinação de objectos mais simples de modo a criar objectos mais complexos, definindo para tal um grafo com eles. Ele define a interface básica <emphasis>Arts::StructureDesc</emphasis>, a <emphasis>Arts::ModuleDesc</emphasis> e a <emphasis>Arts::PortDesc</emphasis>, as quais contêm uma descrição de uma estrutura, um módulo e um porto. Existe também uma forma de obter uma "rede viva de objectos" com essas descrições de ligações e valores, usando uma 'factory' (fábrica). </para></listitem>

</varlistentry>

<varlistentry>
<term>artsmidi.idl</term>

  <listitem><para>Este módulo define a funcionalidade básica de MIDI, com os objectos que produzem os eventos do MIDI, o que é um evento do MIDI, um <emphasis>Arts::MidiManager</emphasis> para se ligar aos produtores e aos consumidores de eventos MIDI, e assim por diante. Como sempre, está implícita a transparência da rede. </para></listitem>

</varlistentry>

<varlistentry>
<term>artsmodules.idl</term>
  <listitem><para>Aqui existem vários filtros, osciladores, efeitos, atrasos adicionais, entre outros objectos, sendo tudo necessário para o processamento útil de sinal, e para criar instrumentos e efeitos complexos a partir destes blocos de construção básicos. </para></listitem>

</varlistentry>

<varlistentry>
<term>artsgui.idl</term>

  <listitem><para>Este preocupa-se com os objectos visuais. Ele define o tipo básico <emphasis> Arts::Widget</emphasis> a partir do qual todos os módulos gráficos derivam. Isto irá produzir uma independência da plataforma e .... edição gráfica visual, assim como a noção de GUIs com capacidades de serialização. Do mesmo modo, dado que os elementos gráficos têm atributos normais, os seus valores poderão ser ligados com facilidade a alguns módulos de processamento de sinal (isto é, o valor de uma barra deslizante à frequência de corte de um filtro). Como sempre: transparência de rede. </para></listitem>

</varlistentry>

</variablelist>
<para>Sempre que possível, o próprio aRts está implementado usando a IDL. Por outro lado, existem algumas APIs <emphasis>específicas da linguagem</emphasis>, usando tanto C++ ou C normal. É normalmente aconselhado usar as interfaces IDL sempre que possível, usando as outras APIs quando for mesmo necessário. Aqui está uma lista das APIs específicas da linguagem: </para>

<variablelist>

<varlistentry>
<term>KNotify, KAudioPlayer (incluídos na 'libtdecore')</term>

  <listitem><para>Estas são APIs do KDE de conveniência para os casos simples e comuns, onde você apenas deseja tocar uma amostra. As APIs são em C++ normal, optimizado para o Qt/KDE, e o mais simples possíveis. </para></listitem>

</varlistentry>

<varlistentry>
<term>libartsc</term>
  <listitem><para>Uma interface em C simples para o servidor de som. Muito útil ao transformar aplicações legadas. </para></listitem>

</varlistentry>

<varlistentry>
<term>libmcop</term>

  <listitem><para>Aqui é onde acontece toda a mágica do MCOP. A biblioteca contém as noções básicas que precisa de saber para criar uma aplicação de MCOP simples, o 'dispatcher', os temporizadores, a gestão de E/S e os pormenores internos que fazem o protocolo do MCOP funcionar em si. </para></listitem>

</varlistentry>

<varlistentry>
<term>libartsflow</term>
  <listitem><para>Para além da implementação do 'artsflow.idl', contém alguns utilitários como a conversão da taxa de amostragem. </para></listitem>

</varlistentry>

<varlistentry>
<term>libqiomanager</term>

  <listitem><para>A integração do MCOP no ciclo de eventos do Qt, quando você cria aplicações do Qt com o MCOP. </para></listitem>

</varlistentry>

</variablelist>



</sect1>
<sect1 id="knotify">
<title>knotify</title>
<para>Ainda não escrito </para>
</sect1>

<sect1 id="kaudioplayer">
<title>kaudioplayer</title>
<para>Ainda não escrito </para>
</sect1>

<sect1 id="libkmid">
<title>libkmid</title>
<para>Ainda não escrito </para>
</sect1>

<sect1 id="kmedia2">
<title>kmedia2</title>
<para>Ainda não escrito </para>
</sect1>

<sect1 id="soundserver">
<title>servidor de som</title>
<para>Ainda não escrito </para>
</sect1>

<sect1 id="artsflow">
<title>artsflow</title>
<para>Ainda não escrito </para>
</sect1>

<sect1 id="capi">
<title><acronym>API</acronym> do C</title>

<sect2 id="capiintro">
<title>Introdução</title>

<para>A <acronym>API</acronym> de C do &arts; foi desenhada para tornar simples a criação e a transformação de aplicações simples de C para tirarem partido do servidor de som &arts;. Ele contém algumas funcionalidades de difusão (o envio de sequências de amostras para o <application>artsd</application>), quer bloqueantes quer não-bloqueantes). Para a maioria das aplicações, você simplesmente irá retirar as poucas chamadas de sistema que lidam com o seu dispositivo de áudio e substitui-las com as chamadas de &arts; apropriadas.</para>

<para>Foram feitas duas passagens como prova da teoria: o <application>mpg123</application> e o <application>quake</application>. Você poderá obter as correcções <ulink url="http://space.twc.de/~stefan/kde/download/artsc-patches.tar.gz">aqui</ulink>. Sinta-se à vontade para enviar as suas próprias alterações para os responsáveis pelo &arts; ou pelos pacotes de 'software' multimédia, de modo a que possam integrar o suporte do &arts; no seu código.</para>

</sect2>

<sect2 id="capiwalkthru">
<title>Percurso Rápido</title>

<para>O envio de áudio para o servidor de som com a <acronym>API</acronym> é bastante simples:</para>
<procedure>
<step><para>incluir o ficheiro da API usando o <userinput>#include &lt;artsc.h&gt;</userinput></para></step>
<step><para>inicializar a <acronym>API</acronym> com o <function>arts_init()</function></para></step>
<step><para>criar um canal com o <function>arts_play_stream()</function></para></step>
<step><para>configurar os parâmetros específicos com o <function>arts_stream_set()</function></para></step>
<step><para>escrever os dados das amostras para o canal com o <function>arts_write()</function></para></step>
<step><para>fechar o canal com o <function>arts_close_stream()</function></para></step>
<step><para>libertar a <acronym>API</acronym> com o <function>arts_free()</function></para></step>
</procedure>

<para>Aqui está um pequeno programa de exemplo que ilustra isto:</para>

<programlisting>#include &lt;stdio.h&gt;
#include &lt;artsc.h&gt;
int main()
{
    arts_stream_t canal;
    char dados[8192];
    int bytes;
    int erro;

    erro = arts_init();
    if (erro &lt; 0)
    {
        fprintf(stderr, "erro do arts_init: %s\n", arts_error_text(erro));
        return 1;
    }

    canal = arts_play_stream(44100, 16, 2, "testeartsc");

    while((bytes = fread(dados, 1, 8192, stdin)) &gt; 0)
    {
        erro = arts_write(canal, dados, bytes);
        if(erro &lt; 0)
        {
            fprintf(stderr, "erro do arts_write: %s\n", arts_error_text(erro));
            return 1;
        }
    }

    arts_close_stream(canal);
    arts_free();

    return 0;
}
</programlisting>
</sect2>

<sect2 id="capiartscconfig">
<title>Compilar e Gerar o Executável: <application>artsc-config</application></title>

<para>Para compilar e gerar os binários com facilidade, usando a <acronym>API</acronym> de C do &arts;, o utilitário <application>artsc-config</application> é fornecido e indica quais as bibliotecas que você precisa para compilar e onde se encontram os ficheiros de inclusão. É invocado com o comando</para>

<screen><userinput><command>artsc-config</command> <option>--libs</option></userinput>
</screen>

<para>para saber quais as bibliotecas e </para>

<screen><userinput><command>artsc-config</command> <option>--cflags</option></userinput>
</screen>

<para>para saber quais as opções adicionais do compilador de C. O exemplo acima poderia ter sido compilado com a linha de comandos:</para>

<screen><userinput><command>cc</command> <option>-o testeartsc testeartsc.c `artsc-config --cflags` `artsc-config --libs`</option></userinput>

<userinput><command>cc</command> <option>-o testeartsc</option> <option>testeartsc.c</option> <option>`artsc-config --cflags`</option> <option>`artsc-config --libs`</option></userinput>
</screen>

</sect2>

<sect2 id="c-api-reference">
<title>Referência das Bibliotecas</title>

<para>[TODO: gerar a documentação do artsc.h com o 'kdoc'] </para>

</sect2>

</sect1>
</chapter>