aRts-håndbogen

Start aRts-builder.

Du behøver et Synth_AMAN_PLAY-modul for at høre uddata som du laver. Så opret et Synth_AMAN_PLAY-modul ved at vælge Moduler->Syntese->Lyd-IO->Synth_AMAN_PLAY og klikke på den tomme modulplads. Placér den cirka nedenfor den femte linje, eftersom vi vil tilføje en del ting ovenfor.

Modulet vil have en parameter title (porten længst til venstre), og autoRestoreID (ved siden af porten længst til venstre) for at den skal kunne findes. For at udfylde disse her, dobbeltklikkes på portene, der vælges en konstant værdi og skrives gennemgang i redigeringsfeltet. Klik på O.k. for at anvende.

Vælg Fil->Kør struktur. Du hører absolut ingenting. Afspilningsmodulet har også brug for noget inddata... ;) Hvis du har lyttet til tavsheden et stykke tyd, klik så på Afslut og gå til trin 2.

Opret en Synth_WAVE_SIN-modul (fra Moduler->Syntese->Bølgeformer) og placér den over Synth_AMAN_PLAY-modulet (lad en linjes mellemrum være mellem dem).

Som du ser, så producerer den noget uddata, men kræver pos som inddata. Lad os først sende uddata til højtalerne. Klik på porten out på Synth_WAVE_SIN og derefter på porten left på Synth_AMAN_PLAY. Voila, du har sammenkoblet to moduler.

Oscillatorer i aRts kræver ikke en frekvens som inddata, men i stedet en position på bølgeform. Positionen skal være mellem 0 og 1, som i et standardobjekt Synth_WAVE_SIN oversættes til området 0 .. 2*Pi. For at oprette oscillerende værdier fra en frekvens, bruges et Synth_FREQUENCY modul.

Opret en Synth_FREQUENCY-modul (fra Moduler->Syntese->Oscillation & modulation) og forbind dets “pos” udgang til “pos” indgangen på Synth_WAVE_SIN. Sæt frekvensporten for frekvensgeneratoren til den konstante værdi 440.

Vælg Fil->Kør struktur. Du vil høre en sinusbølge på 440 Hz i en af dine højtalere. Hvis du har lyttet til den et stykke tid, så klik på O.k. og gå til trin 3.

O.k., det ville være bedre hvis du kunne høre sinusbølgen i begge højtalerne. Forbind også den højre port på Synth_PLAY til udgangen fra Synth_WAVE_SIN.

Opret et Synth_SEQUENCE-objekt (fra Moduler->Syntese->Midi & sekvensering). Det skal placeres øverst på skærmen. Hvis du behøver mere plads kan du flytte de andre moduler ved at markere dem (for at markere flere moduler holdes shift-tasten nede), og trække dem rundt.

Forbind nu frekvensudgangen på Synth_SEQUENCE til frekvensindgangen på Synth_FREQUENCY-modulet. Angiv derefter sekvensens hastighed som konstant værdi 0.13 (hastigheden er porten længst til venstre).

Gå nu til porten længst til højre (seq) på Synth_SEQUENCE og skriv A-3;C-4;E-4;C-4; som konstant værdi. Dette angiver en sekvens. Mere om dette i modulreferencen.

Vælg Fil->Kør struktur. Du vil høre en behagelig sekvens spille. Når du har nydt følelsen, så klik på O.k. og gå til trin 4.

Opret et Synth_PSCALE-modul (fra Moduler->Syntese->Envelopper). Afbryd forbindelsen fra udgangen for sinusbølgen ved at dobbeltklikke på den og vælg ikke forbundet. Forbind

Til slut, sættes PSCALE top til en værdi, for eksempel 0.1.

Hvordan virker dette nu: Synth_SEQUENCE giver yderligere information om positionen for tonen den spiller lige nu, hvor 0 betyder netop påbegyndt og 1 betyder afsluttet. Modulet Synth_PSCALE skalerer lydstrømmen som sendes gennem den fra lydstyrke 0 (tavs) til 1 (oprindelig lydstyrke) tilbage til 0 (tavs) ifølge positionen. Positionen hvor toppen skal ske kan angives som top. 0.1 betyder at efter 10 % af tonen er spillet har lydstyrken nået sin maksimale værdi, og begynder derefter at aftage.

Vælg Fil->Kør struktur. Du vil høre en behagelig sekvens spille. Når du har nydt følelsen, klik på O.k. og gå til trin 5.

Start endnu en aRts-builder.

Placér en Synth_AMAN_PLAY i den, og indstil den til et rimeligt navn. Placér en Synth_BUS_DOWNLINK i den og:

Begynd at køre strukturen. Som ventet hører du ingenting, ... ikke endnu.

Gå tilbage til strukturen med Synth_WAVE_SIN tingene og udbyt Synth_AMAN_PLAY-modulet mod en Synth_BUS_UPLINK, og indstil navnet til lyd (eller Peter hvis du vil). At fjerne moduler gøres ved at markere dem og vælge Redigér->slet fra menuen (eller trykke på tasten Del).

Vælg Fil->Kør struktur. Du vil høre sekvensen med skalerede toner, transporteret over bussen.

Hvis du vil finde ud af hvorfor noget sådant her kan være nyttigt, så klik på O.k. (i aRts-builder som kører Synth_SEQUENCE tingene, du kan lade den anden fortsætte med at køre) og gå til trin 6.

Vælg Fil->Omdøb struktur fra menuen i den aRts-bygger som indeholder Synth_SEQUENCE tingene, og kald den gennemgang. Tryk på O.k..

Vælg Fil->Gem.

Start yderligere en aRts-builder og vælg Fil->Åbn, og indlæs gennemgangen igen.

Nu kan du vælge Fil->Kør struktur i begge aRts-builder'er som har strukturen. Nu hører du det samme to gange. Afhængig af hvornår du starter dem kommer det til at lyde mere eller mindre godt.

En anden ting som det kan være godt at gøre på dette tidspunkt er at starte Noatun, og spille en mp3-fil. Start derefter artscontrol. Gå til Vis->Vis lydhåndtering. Det du ser er Noatun og din struktur “gennemgang” afspille noget. Det gode som du kan gøre er: dobbeltklik på Noatun. Du får nu en liste over tilgængelige busser. Og se? Du kan lade Noatun sende sin udskrift via lydbussen til afspilningsstrukturen som din gennemgang sørger for.

Endelig, nu skal du kunne lave din sinusbølge om til et rigtigt instrument. Dette er kun meningsfuldt hvis du har noget passende som kan sende MIDI-begivenheder til aRts. Her beskriver jeg hvordan du kan bruge et eksternt keyboard, men en sequencer, såsom Brahms, som kender til midibussen virker også.

Først af alt, så ryd op på din desktop indtil du kun har én aRts-builder med sinusbølgestrukturen i gang (men lad den ikke køre). Gå derefter tre gange til Porte->Opret IN-lydsignal, og tre gange til Porte->Opret UT-lydsignal. Placér portene et sted.

Gå til Porte+Ændr positioner og navne og døb portene frequency, velocity, pressed, left, right, done.

Endelig kan du slette modulet Synth_SEQUENCE, og i stedet forbinde inddataporten frequency for strukturen til frekvensporten på Synth_FREQUENCY. Hmm. Men hvad skal man gøre med pos?

Denne er ikke tilgængelig, eftersom der ikke er nogen algoritme i værdier som kan forudse hvornår brugeren vil slippe tasten han netop trykkede ned på sit midi-keyboard. Vi har i stedet parameteren pressed, som kun angiver om brugeren stadigvæk holder tasten nede. (pressed = 1: tasten stadigvæk nedtrykt, pressed = 0: tasten sluppet)

Dette betyder også at Synth_PSCALE-objektet skal udskiftes nu. Kobl en Synth_ENVELOPE_ADSR ind i stedet (fra Moduler->Syntese->Envelopper). Forbind:

Sæt parametrene attack til 0.1, decay til 0.2, sustain til 0.7, release til 0.1.

En ting til som vi skal tænke på er at instrumentstrukturen skal på en eller anden måde vide når den har spillet færdig og så kan ryddes væk, eftersom den ellers aldrig ville stoppe også selvom tasten er sluppet. Heldigvis ved ADSR enveloppen når der ikke er mere at høre, eftersom den alligevel skalerer signalet ned til nul på et tidspunkt efter tasten er sluppet.

Dette angives ved at sætte udgangen done til 1. Så forbind denne til strukturens udgang. Strukturen fjernes så snart done bliver 1.

Omdøb din struktur til instrument_gennemgang (fra Fil->Omdøb struktur. Gem den derefter med Gem som (det standardnavn som nu angives skal være instrument_gennemgang).

Start artscontrol, og gå til Vis->Vis midihåndtering, og vælg Tilføj->aRts syntese midi uddata. Tilsidst skal du kunne vælge dit instrument (gennemgang) her.

Åbn en terminal og skriv midisend. Du vil se at midisend og instrumentet nu er på listen i aRts MIDI-håndtering. Efter at have valgt begge to og trykket på forbind, er vi til sidst klare. Tag dit keyboard og begynd at spille (det skal naturligvis være forbundet til din maskine).

Du bør nu kunne arbejde med aRts. Her er nogle vink om hvad du nu vil kunne gøre for at forbedre dine strukturer:

Hvis du har lavet noget storartet, så overvej gerne at give det til aRts' netside, eller til at indgå i næste udgave.

Antag at du har et program som hedder “musepling” (som skal afgive en “pling”-lyd hvis du klikker på en museknap). Latensen er tiden mellem din finger trykker på museknappen til du hører plinget. Latensen for dette scenario består af flere forskellige latenstider, som har forskellige årsager.

I dette enkle program opstår latensen på følgende steder:

De første tre punkter er latensen udenfor aRts. De er interessante, men udenfor dette dokuments rækkevidde. Ikke desto mindre skal du vide at de findes, så selvom du har optimeret alt andet til virkelig små værdier, så får du måske ikke nødvendigvis nøjagtigt det resultat du forventer dig.

At bede serveren om at spille noget indebærer oftest kun et enkelt MCOP-kald. Der er målinger som bekræfter at det kan lade sig gøre at bede serveren at spille noget 9000 gange pr sekund med den nuværende implementering, på samme værtsmaskine med Unix domæne-sokler. Jeg antager at det meste af dette er kernens omkostning, for at skifte fra en proces til en anden. Naturligvis ændres denne værdi med den nøjagtige type af parametrene. Hvis man overfører et helt billede med et kald, bliver det langsommere end hvis man kun overfører en "long" værdi. Det samme er sandt for returværdien. For almindelige strenge (som filnavnet på wav-filen som skal afspilles) skulle dette ikke være et problem.

Dette betyder at vi kan tilnærme denne tid med 1/9000 sekund, det vil sige under 0,15 ms. Vi vil se at dette ikke er relevant.

Derefter kommer tiden efter serveren begynder at spille og lydkortet tager imod noget. Serveren skal buffre data, så ingen pauser høres når andre programmer, såsom din X11-server eller “musepling”-programmet, kører. Den måde dette håndteres på Linux® er at der er et antal fragmenter af en vis størrelse. Serveren genopfylder fragmenter, og lydkortet afspiller fragmenter.

Så antag at der er tre fragmenter. Serveren genopfylder det første og lydkortet begynder at afspille det. Serveren genopfylder det andet. Serveren genopfylder det tredje. Serveren er klar og andre programmer kan nu gøre noget.

Når lydkortet har afspillet det første fragment, begynder det at afspille det andet og serveren begynder at genopfylde det første, og så videre.

Den maksimale latenstiden du får med alt dette er (antal fragmenter) * (størrelse på hvert fragment) / (samplingsfrekvens * (størrelse på hver sampling)). Hvis vi antager 44 kHz stereo, og syv fragmenter på 1024 byte (de nuværende standardindstillinger i aRts), så får vi 40 ms.

Disse værdier kan indstilles efter dine behov. CPU-brugen øges dog med mindre latenstider, eftersom lydserveren skal genopfylde bufferne oftere, og med mindre dele. Det er også oftest umuligt at nå bedre værdier uden at give lydserveren realtidsprioritet, eftersom man ellers ofte får pauser.

Det er imidlertid realistisk at lave noget i stil med 3 fragmenter med 256 byte hver, som ville ændre denne værdi til 4,4 ms. Med 4,4 ms forsinkelse ville aRts CPU-forbrug være cirka 7,5 %. Med en 40 ms forsinkelse, ville den være cirka 3 % (for en PII-350, og værdien kan afhænge af dit lydkort, version af kernen og andet).

Så er der tiden som det tager for pling-lyden at gå fra højtalerne til dine ører. Antag at din afstand fra højtalerne er 2 meter. Lyden bevæger sig med hastigheden 330 meter pr sekund. Så vi kan ansætte denne tid til 6 ms.

Programmer med lydstrømme er dem som laver deres lyd selv. Tænk dig til et spil som sender en konstant strøm med samplinger, og nu skal tilpasses til at afspille lyd via aRts. Som et eksempel: når jeg trykker på en tast så hopper figuren som jeg bruger, og en bang-lyd afspilles.

Først så skal du vide hvordan aRts håndterer strømme. Det er meget lignende I/O med lydkortet. Spillet sender nogle pakker med samplinger til lydserveren, lad os antage tre styk. Så snart lydserveren er klar med den første pakke, sender den en bekræftelse tilbage til spillet om at denne pakke er færdig.

Spillet laver yderligere en lydpakke og sender den til serveren. I mellemtiden begynder serveren at konsumere den anden lydpakke, og så videre. Latenstiderne ligner dem i det enklere tilfælde:

De eksterne latenstider er, som ovenfor, udenfor dette dokuments rækkevidde.

Det er åbenbart at latenstiden for strømme afhænger af tiden det tager for alle pakker som bruges at afspilles en gang. Så den er (antal pakker) * (størrelse på hver pakke) / (samplingsfrekvensen * (størrelse på hver sampling)).

Som du ser er dette samme formel som gælder for fragmenterne. For spil er der dog ingen grund til at have så korte forsinkelser som ovenfor. Jeg vil sige at et realistisk eksempel for et spil kunne være 2048 byte pr pakke, når der bruges 3 pakker. Latenstidsresultatet ville så være 35 ms.

Dette er baseret på følgende: antag at et spil viser 25 billeder pr sekund (for skærmen). Det er antageligt helt sikkert at antage at en forskel på et billede for lydudskriften ikke vil kunne mærkes. Derfor er 1/25 sekunds forsinkelse for lydstrømmen acceptabelt, hvilket på sin side betyder at 40 ms skulle være o.k.

De fleste personer kører heller ikke deres spil med realtidsprioritet, og faren for pauser i lyden kan ikke negligeres. Strømme med 3 pakker på 256 byte er mulige (jeg prøvede det) - men forårsager meget CPU-forbrug til strømning.

Latenstider på serversiden kan du beregne præcis som ovenfor.

Der er mange faktorer som påvirker CPU-forbrug i et komplekst scenario, med nogle programmer med lydstrømme og nogle andre programmer, nogle plugin i serveren, osv. For at angive nogle få:

For beregning af rå CPU-forbrug, hvis du afspiller to strømme samtidigt skal du gøre additioner. Hvis du anvender et filter, er visse beregninger indblandede. For at tage et forenklet eksempel, at addere to strømme kræver måske fire CPU-cykler pr addition, på en 350 MHz processor er dette 44100 * 2 * 4 / 350000000 = 0,1 % CPU-forbrug.

aRts interne skemalægning: aRts skal bestemme hvilket plugin som skal beregne hvad hvornår. Dette tager tid. Brug et profileringsværktøj hvis du er interesseret i det. Hvad som kan siges i almindelighed er at jo mindre realtid som bruges (dvs. jo større blokke som kan beregnes af gangen) desto mindre skemalægningsomkostning fås. Udover beregning af blokke med 128 samplinger af gangen (altså med brug af fragmentstørrelser på 512 byte) er skemalægningsomkostningen formodentlig ikke værd at bryde sig om.

Konvertering fra heltal til decimaltal: aRts bruger decimaltal som internt dataformat. De er enkle at håndtere, og på moderne processorer er de ikke meget langsommere end heltalsoperationer. Hvis der er klienter som afspiller data som ikke er decimaltal (såsom et spil som skal lave sin lydudskrift via aRts), behøves konvertering. Det samme gælder hvis du vil afspille lyd på dit lydkort. Lydkortet behøver heltal, så du skal konvertere.

Her er værdier for en Celeron, cirka klokcykler pr sampling, med -O2 og egcs 2.91.66 (målt af Eugene Smith (hamster AT null.ru)). Dette er naturligvis yderst processorafhængigt:

convert_mono_8_float: 14
convert_stereo_i8_2float: 28
convert_mono_16le_float: 40
interpolate_mono_16le_float: 200
convert_stereo_i16le_2float: 80
convert_mono_float_16le: 80

Så dette betyder 1 % CPU-forbrug for konvertering og 5 % for interpolation på denne 350 MHz processor.

MCOP protokollomkostning: MCOP klarer, som en tommelfingerregel, 9000 kald pr sekund. En stor del af dette er ikke MCOP's fejl, men hører sammen med de to grunde for kernen som nævnes nedenfor. Dette giver i alle tilfælde en basis for at udføre beregninger af hvad omkostningen er for strømning.

Hver datapakke som sendes med en strøm kan anses for at være et MCOP-kald. Store pakker er naturligvis langsommere end 9000 pakker/s, men det giver en god idé.

Antag at du bruger pakkestørrelser på 1024 byte. På denne måde, for at overføre en strøm med 44 kHz stereo, behøver du at overføre 44100 * 4 / 1024 = 172 pakker pr sekund. Antag at du kunne overføre 9000 pakker med 100 % CPU-forbrug, så får du (172 *100) / 9000 = 2 % CPU-forbrug på grund af strømningen med 1024 byte pakker.

Dette er en approksimation. Det viser i alle tilfælde at du ville klare dig meget bedre (hvis du har råd for latenstiden), med for eksempel at bruge pakker på 4096 byte. Her kan vi oprette en kompakt formel, ved at beregne pakkestørrelsen som forårsager 100 % CPU-forbrug som 44100 * 4 / 9000 = 19,6 samplinger, og på den måde få hurtigformlen:

CPU-forbrug for en strøm i procent = 1960 / (din pakkestørrelse)

som giver os 0,5 % CPU-forbrug med en strøm af 4096 byte pakker.

Kernens proces/sammenhængsskift: Dette er en del af MCOP-protokollens omkostning. At skifte mellem to processer tager tid. Der er en ny hukommelsesafbildning, cacher er ugyldige, og en del andet (hvis en ekspert på kernen læser dette - fortæl mig om de nøjagtige grunde). Dette betyder: det tager tid.

Jeg er ikke sikker på hvor mange procesbyte Linux® kan lave pr sekund, men værdien er ikke uendelig. Så af MCOP-protokollens omkostning, antager jeg at en hel del afhænger af processkift. MCOP først påbegyndtes prøvede jeg samme kommunikation inde i en proces, og det var meget hurtigere (cirka fire gange hurtigere).

Kernens kommunikationsomkostning: Dette er en del af MCOP-protokollens omkostning. At overføre data mellem processer gøres for øjeblikket via et udtag (sokkel). Dette er bekvemt, eftersom den almindelige select() metode kan bruges til at afgøre hvornår en meddelelse er ankommet. Det kan også kombineres med andre I/O-kilder såsom lyd-I/O, X11-server eller hvad som helst andet.

Disse læse- og skrivekald koster definitivt processorcykler. For små kald (som at overføre en midi-begivenhed) er det formodentlig ikke så farligt, men for store kald (som at overføre et videobillede på flere Mbyte) er det helt klart et problem.

At tilføje brug af delt hukommelse til MCOP hvor det er passende er formodentlig den bedste løsning. Det skal dog gøres transparent for anvendelsesprogrammerne.

Tag et profileringsværktøj og udfør andre test for at finde ud af nøjagtigt hvordan nuværende lydstrømme påvirkes af ikke at bruge delt hukommelse. Det er dog ikke så dårligt, eftersom lydstrømme (afspilning af mp3) kan gøres med totalt 6 % CPU-forbrug for artsd og artscat (og 5 % for mp3-afkoderen). Dette omfatter alting fra nødvendige beregninger til omkostning for udtaget, så jeg vil bedømme at man måske ville vinde cirka 1 % på at bruge delt hukommelse.

Disse er lavet med den nuværende udviklingsversion. Jeg ville også forsøge med rigtigt svære tilfælde, så dette er ikke hvad programmer til daglig brug ville gøre.

Jeg skrev et program som hedder streamsound som sender datastrømmen til aRts. Her køres det med realtidsprioritet (uden problemer), og et lille plugin på serversiden (lydstyrkeskalning og klipning):

4974 stefan    20   0  2360 2360  1784 S       0 17.7  1.8   0:21 artsd
 5016 stefan    20   0  2208 2208  1684 S       0  7.2  1.7   0:02 streamsound
 5002 stefan    20   0  2208 2208  1684 S       0  6.8  1.7   0:07 streamsound
 4997 stefan    20   0  2208 2208  1684 S       0  6.6  1.7   0:07 streamsound

Hvert af programmerne sender en strøm med 3 fragmenter på 1024 byte (18 ms). Der er tre sådanne klienter som kører samtidigt. Jeg ved at det synes at være lidt vel meget, men som jeg sagde: tag et profileringsværktøj og find ud af hvad som koster tid, og hvis du vil, forbedr det.

Jeg tror i alt fald ikke at bruge strømning sådan her er realistisk eller giver mening. For at gøre det hele endnu mere ekstremt, forsøgte jeg med den mindst mulige latenstid. Resultat: man kan bruge strømme uden afbrud med et klientprogram, hvis man tager 2 fragmenter med 128 byte mellem aRts og lydkortet, og mellem klientprogrammet og aRts. Dette betyder at man har en total maksimal latenstid på 128 * 4 / 44100 * 4 = 3 ms, hvor 1,5 ms genereres på grund af I/O til lydkortet og 1,5 ms genereres af kommunikation med aRts. Begge programmer skal køre med realtidsprioritet.

Men dette koster en enorm mængde CPU. Dette eksempel koster cirka 45 % på min P-II/350. Det begynder også at klikke hvis man starter top, flytter vinduer på X11-skærmen eller laver disk-I/O. Alt dette har med kernen at gøre. Problemet er at skemalægge to eller flere processer med realtidsprioritet også koster en enorm anstrengelse, endnu mere end kommunikation og meddelelse til hinanden, osv..

Tilsidst, et mere hverdagsagtigt eksempel: Dette er aRts med artsd og en artscat (en klient med datastrøm) som kører 16 fragmenter på 4096 byte:

5548 stefan    12   0  2364 2364  1752 R       0  4.9  1.8   0:03 artsd
 5554 stefan     3   0   752  752   572 R       0  0.7  0.5   0:00 top
 5550 stefan     2   0  2280 2280  1696 S       0  0.5  1.7   0:00 artscat

Hver navnerumsdeklaration hører sammen med en deklaration af en “modul” i MCOP IDL.

// mcop idl

module M {
    interface A
    {
    }
};

interface B;

I dette tilfælde ville den genererede C++ kode for IDL-fragmentet se sådan her ud:

// C++ deklaration

namespace M {
    /* deklaration af A_base/A_skel/A_stub og lignende */
    class A {        // Smartwrap referenceklasse
        /* [...] */
    };
}

/* deklaration af B_base/B_skel/B_stub og lignende */
class B {
    /* [...] */
};

Så når du henviser til klasserne fra eksemplet ovenfor i din C++ kode, skal du skrive M::A, men kun B. Du kan imidlertid bruge “using M” et sted, som med alle navnerum i C++.

Der er et globalt navnerum som kaldes “Arts”, som alle programmer og biblioteker som hører til aRts selv bruger til at lægge deres deklarationer i. Dette betyder at når du skriver C++ kode som afhænger af aRts, skal du normalt bruge præfikset Arts:: for hver klasse du bruger, sådan her:

int main(int argc, char **argv)
{
    Arts::Dispatcher dispatcher;
    Arts::SimpleSoundServer server(Arts::Reference("global:Arts_SimpleSoundServer"));

    server.play("/var/foo/nogen_fil.wav");

Det andet alternativ er at skrive "using" en gang, sådan her:

using namespace Arts;

int main(int argc, char **argv)
{
    Dispatcher dispatcher;
    SimpleSoundServer server(Reference("global:Arts_SimpleSoundServer"));

    server.play("/var/foo/nogen_fil.wav");
    [...]

I IDL-filer, har du egentlig ikke noget valg. Hvis du skriver kode som tilhører aRts selv, skal du putte den i modulet aRts.

// IDL-fil for aRts-kode:
#include <artsflow.idl>
module Arts {        // put den i Arts-navnerum
    interface Synth_TWEAK : SynthModule
    {
        in audio stream invalue;
        out audio stream outvalue;
        attribute float tweakFactor;
    };
};

Hvis du skriver kode som ikke hører til selve aRts, skal du ikke putte den i navnerummet “Arts”. Du kan dog oprette et eget navnerum hvis du vil. Under alle omstændigheder, skal du bruge præfiks for klasser fra aRts som du bruger.

// IDL-fil for kode som ikke hører til aRts:
#include <artsflow.idl>

// skriv enten med eller uden moduldeklaration, og de genererede klasser
// kommer ikke til at bruge et navnerum:
interface Synth_TWEAK2 : Arts::SynthModule
{
    in audio stream invalue;
    out audio stream outvalue;
    attribute float tweakFactor;
};

// du kan dog vælge et eget navnerum hvis du vil, så hvis du
// skriver programmet "PowerRadio", ville du kunne gøre sådan her:
module PowerRadio {
    struct Station {
        string name;
        float frequency;
    };

    interface Tuner : Arts::SynthModule {
        attribute Station station;     // intet præfiks for Station, samme modul
        out audio stream left, right;
    };
};

MCOP har ofte brug for at henvise til navne på typer og grænseflader for typekonverteringer, grænseflader og metodesignaturer. Disse repræsenteres af strenge i de almindelige MCOP-datastrukturer, mens navnerummet altid er fuldstændigt repræsenteret i C++ stilen. Dette betyder at strengene skal indeholde “M::A” og “B”, ifølge eksemplerne ovenfor.

Bemærk at dette til og med gælder hvis navnerumskvalifikatorerne ikke blev givet inde i IDL-teksten, eftersom sammenhængen klargør hvilket navnerum grænsefladen A var beregnet til at bruge.

At bruge tråde er ikke muligt på alle platforme. Dette er grunden til at aRts oprindeligt blev skrevet uden at bruge tråde overhovedet. For næsten alle problemer, findes der en løsning uden tråde som gør det samme som hvert løsning med tråde.

For eksempel, i stedet for at placere lyduddata i en separat tråd, og gøre den blokerende, bruger aRts lyduddata som ikke blokerer, og regner ud hvornår næste del af uddata skal skrives med select().

aRts understøtter i det mindste (i de nyeste versioner) støtte for dem som vil implementere deres objekter med tråde. Hvis du for eksempel allerede har kode for en mp3-afspiller, og koden forventer at mp3-afkoderen skal køres i en separat tråd, er det oftest lettest at beholde denne konstruktion.

Implementeringen af aRts/MCOP er opbygget ved at dele tilstanden mellem forskellige objekter på tydelige og mindre tydlige måder. En kort liste af delte tilstande omfatter:

Ingen af de ovenstående objekter forventer at blive brugt samtidigt (dvs. at blive kaldt fra forskellige tråde samtidigt). I almindelighed er der to måder at løse dette:

aRts bruger den første måde. Du behøver en lås hver gang du skal have adgang til et af disse objekter. Den anden måde er sværere at gøre. Et hurtigt fiks som forsøger at opnå dette findes på http://space.twc.de/~stefan/kde/download/arts-mt.tar.gz, men for øjeblikket virker en minimal måde formodentlig bedre, og forårsager mindre problemer med eksisterende programmer.

Du kan få/slippe låsen med de to funktioner:

Generelt behøver du ikke at skaffe en lås (og du skal ikke forsøge at gøre det), hvis den allerede holdes. En liste over betingelser når dette er tilfældet er:

Der er også nogle undtagelse for funktioner som du kun kan kalde i hovedtråden, og af den grund aldrig behøver et låse for at kalde dem:

Men det er alt. For alt andet som på nogen måde hører sammen med aRts, skal du skaffe låsen, og slippe den igen når du er klar. Her er et enkelt eksempel:

class SuspendTimeThread : Arts::Thread {
public:
    void run() {
        /*
         * du behøver denne lås fordi:
         *  - oprettelse af en reference behøver en lås (eftersom global: går til
         *    objekthåndteringen, som derefter kunne have brug for GlobalComm
         *    objektet for at slå hver forbindelse der skal gøres op)
         *  - tildeling af en smartwrapper behøver en lås
         *  - oprettelse af et objekt fra en reference behøver en lås (eftersom
         *    den kan få brug for at forbinde til en server)
         */
        Arts::Dispatcher::lock();
        Arts::SoundServer server = Arts::Reference("global:Arts_SoundServer");
        Arts::Dispatcher::unlock();

        for(;;) {            /*
             * du behøver en lås her, eftersom
             *  - følge en reference for en smartwrapper behøver en lås
             *    (eftersom den kan oprette objektet når den bruges)
             *  - at gøre et MCOP-kald behøver en lås
             */
            Arts::Dispatcher::lock();
            long seconds = server.secondsUntilSuspend();
            Arts::Dispatcher::unlock();

            printf("sekunder til ventetilstand = %d",seconds);
            sleep(1);
        }
    }
}

Følgende trådrelaterede klasser er tilgængelige for øjeblikket:

Se linkene for dokumentationen.

Eftersom referencer kan pege på fjernobjekter, kan serverne som indeholder disse objekter bryde sammen. Hvad sker så?

Der er andre fejlbetingelser, såsom nedkobling af netværket (antag at du tager kablet mellem din server og klient væk mens dit program kører). Deres effekt er imidlertid den samme som et serversammenbrud.

Totalt set er det naturligvis et policy-spørgsmål hvor strengt du forsøger at håndtere kommunikationsfejl i hele dit program. Du kan følge metoden “hvis serveren bryder sammen, skal vi fejlsøge den til den aldrig bryder sammen igen”, som ville betyde at du ikke behøver bryde dig om alle disse problemer.

Et objekt skal ejes af nogen for at eksistere. Hvis det ikke gør det, vil det ophøre med at eksistere (mere eller mindre) med det samme. Internt angives en ejer ved at kalde _copy(), som forøger en reference tæller, og en ejer fjernes ved at kalde _release(). Så snart referencetælleren når nul, så slettes objektet.

Som en variation på temaet, angives fjernbrug med _useRemote(), og opløses med _releaseRemote(). Disse funktioner har en liste over hvilken server som har kaldt dem (og derfor ejer objektet). Dette bruges hvis serveren kobler ned (dvs. sammenbrud, netværksfejl), for at fjerne referencer som stadigvæk findes til objektet. Dette gøres i _disconnectRemote().

Nu er der et problem. Betragt en returværdi. I almindelige tilfælde ejes returværdiobjektet ikke af funktionen som kaldes længere. Det ejes heller ikke af den som kalder, førend meddelelsen som indeholder objektet er modtaget. Så der er en tid med objekter som “mangler ejere”.

Når vi nu sender et objekt kan man være rimeligt sikker på at så snart det modtages, ejes det af nogen igen, med mindre, igen, modtageren bryder sammen. Dette betyder i alle tilfælde at specielle hensyn skal tages for objekter i det mindste mens der sendes, og formodentlig også mens der modtages, så de ikke fjernes med det samme.

Måden som MCOP gør dette er ved at “mærke” objekter som er ved at blive kopieret over netværket. Inden en sådan kopiering begynder, kaldes _copyRemote. Dette forhindrer at objektet fjernes et stykke tid (5 sekunder). Så snart modtageren kalder _useRemote(), fjernes mærket igen. Så alle objekter som sendes over netværket, mærkes inden overførslen.

Hvis modtageren modtager et objekt som findes på samme server, så bruges _useRemote() naturligvis ikke. I dette specialtilfælde, findes funktionen _cancelCopyRemote() til at fjerne mærket manuelt. Foruden dette, er der også en tidsbaseret fjernelse af mærker, hvis mærkning udførtes, men modtageren ikke virkelig fik objektet (på grund af sammenbrud, netværksfejl). Dette gøres med klassen ReferenceClean.

Strømme definerer multimediadata, en af de vigtigste komponenter i et modul. Strømme defineres med følgende format:

[ async ] in|out [ multi ] typ stream navn [ , navn ] ;

Strømme har en defineret retning i forhold til modulet, som angives af de nødvendige parametre in eller out. Typeargumentet definerer datatypen, som kan være en hvilken som helst af typerne for egenskaber som beskrives senere (ikke alle understøttes endnu). Mange moduler bruger strømtypen audio, som er et alias for float eftersom det er det interne dataformatet for lydstrømme. Flere strømme af samme type kan indgå i samme definition med navne adskilt med kommategn.

Strømme er normalt synkrone, hvilket betyder at de er kontinuerlige dataflows med en konstant hastighed, såsom PCM-lyd. Parameteren async angiver en asynkron strøm, som bruges til ikke-kontinuerlige datastrømme. Det almindeligste eksempel på en asynkron strøm er MIDI-meddelelser.

Nøgleordet multi, som kun er gyldigt for inddatastrømme, angiver at grænsefladen understøtter et variabelt antal indgange. Dette er nyttigt til at implementere enheder såsom en mixer som kan tage imod et hvilket som helst antal inddatastrømme.

Attributter er data som hører sammen med en udgave af en grænseflade. De deklareres som medlemsvariabler i C++, og kan bruges af en hvilken som helst af de primitive typer boolean, byte, long, string, eller float. Du kan også bruge selvdefinerede struct- eller nummereringstyper samt sekvenser af variabel størrelse med syntaksen sekvens<type>. Attributter kan valgfrit markeres som skrivebeskyttede.

Som i C++, kan metoder defineres i grænseflader. Metodeparametrene er begrænsede til samme typer som attributterne. Nøgleordet oneway angiver en metode som returnerer umiddelbart og køres asynkront.

Flere grænseflader for standardmoduler er allerede definerede for dig i aRts, såsom StereoEffect, og SimpleSoundServer.

Et enkelt eksempel på et modul taget fra aRts er modulet med konstant forsinkelse, som findes i filen kdemultimedia/arts/modules/artsmodules.idl. Grænsefladedefinitionen angives nedenfor:

interface Synth_CDELAY : SynthModule {
        attribute float time;
        in audio stream invalue;
        out audio stream outvalue;
};

Modulet arver SynthModule. Den grænseflade, som findes i artsflow.idl, definerer alle standardmetoder som implementeres i alle syntesemoduler.

CDELAY-effekten forsinker en stereolydstrøm med tidsværdien som angives som en decimaltal parameter. Grænsefladedefinitionen har en attribut af typen float til at opbevare forsinkelsesværdien. Den definerer to inddata- og to uddatastrømme (typisk for stereoeffekter). Ingen metoder kræves ud over de arvede.

Der er forskellige krav for hvordan et modul kan håndtere strømningen. For at illustrere dette, betragt følgende eksempel:

Det første tilfælde er det enkleste: når modulet modtager 200 inddatasamplinger producerer det 200 uddatasamplinger. Det producerer kun uddata når det får inddata.

Det andet tilfælde producerer forskellige antal uddatasamplinger når det får 200 inddatasamplinger. Det afhænger af hvilken konvertering som udføres, men antallet er kendt i forvejen.

Det tredje tilfælde er endnu værre. Fra begyndelsen kan man ikke engang gætte hvor meget data som laves af 200 inddata byte (formodentlig meget mere end 200 byte, men...).

Det sidste tilfælde er et modul som aktiveres af sig selv, og sommetider laver data.

I aRts-0.3.4, håndteredes kun strømme af den første type, og de fleste ting virkede godt. Dette er formodentlig hvad du mest behøver når du skriver moduler som behandler lyd. Problemerne med de andre, mere komplekse slags strømme er, at de er svære at programmere, og at man for det meste ikke behøver funktionerne. Dette er grunden til at vi gør dette med to forskellige slags strømtyper: synkrone og asynkrone.

Synkrone strømme har følgende egenskaber:

Asynkrone strømme, på den anden side, opfører sig sådan her:

Når strømme deklareres, bruges nøgleordet “async” til at angive at strømmen skal være asynkron. Så antag for eksempel at du vil konvertere en asynkron strøm af byte til en synkron strøm af samplinger. Grænsefladen ville så kunne se sådan her ud:

interface ByteStreamToAudio : SynthModule {
    async in byte stream inddata;   // den asynkrone inddatasampling

    out audio stream left,right;   // de synkrone uddatasamplinger
};

Antag at du har bestemt dig for at skrive et modul som laver asynkron lyd. Dens grænseflade kunne se sådan her ud:

interface SomeModule : SynthModule
{
    async out byte stream outdata;
};

Hvordan sender man data? Den første metode kaldes “trykleverance”. Med asynkrone strømme sender man data som pakker. Det betyder at individuelle pakker sendes som i eksemplet ovenfor. Den virkelige proces er: allokér en pakke, fyld den, send den.

Her følger det i form af kode. Først allokerer vi en pakke:

DataPacket<mcopbyte> *packet = outdata.allocPacket(100);

Så fylder vi den:

// typekonvertering så fgets får en (char *) peger
char *data = (char *)packet->contents;

// som du ser, kan du krympe pakkestørrelsen efter allokeringen
// hvis du vil
if(fgets(data,100,stdin))
    packet->size = strlen(data);
else
    packet->size = 0;

Nu sender vi den:

packet->send();

Dette er meget enkelt, men hvis vi vil sende pakker nøjagtigt så hurtigt som modtageren kan håndtere dem, behøves en anden måde, metoden med “trækleverance”. Man beder om at sende pakker så hurtigt som modtageren er klar til at behandle dem. Man begynder med en vis mængde pakker som sendes. Mens modtageren behandler pakke efter pakke, begynder man at fylde dem igen med friske data, og sende dem igen.

Du starter det ved at kalde setPull. For eksempel:

outdata.setPull(8, 1024);

Dette betyder at du vil sende pakke via uddata. Du vil begynde med at sende 8 pakker på én gang, og når modtageren behandler nogle af dem, vil du fylde dem op igen.

Derefter behøver du at implementere en metode som fylder pakken, som kunne se sådan her ud:

void request_outdata(DataPacket<mcopbyte> *packet)
{
    packet->size = 1024;  // skal ikke være mere end 1024
    for(int i = 0;i < 1024; i++)
        packet->contents[i] = (mcopbyte)'A';
    packet->send();
}

Det er alt. Når du ikke har flere data, kan du begynde at sende pakker med størrelsen nul, som stopper trækleverancerne.

Bemærk at det er væsentligt at give metoden nøjagtigt navnet request_strømnavn.

Vi beskrev netop at sende data. At modtage data er meget enklere. Antag at du har et enkelt filter, ToLower, som helt enkelt konverterer alle bogstaver til små:

interface ToLower {
    async in byte stream inddata;
    async out byte stream uddata;
};

Dette er virkeligt enkelt at implementere. Her er hele implementationen:

class ToLower_impl : public ToLower_skel {
public:
    void process_inddata(DataPacket<mcopbyte> *inpacket)
    {
        DataPacket<mcopbyte> *outpacket = ouddata.allocPacket(inpacket->size);

        // lav om til små bogstaver
        char *instring = (char *)inpacket->contents;
        char *outstring = (char *)outpacket->contents;

        for(int i=0;i<inpacket->size;i++)
            outstring[i] = tolower(instring[i]);

        inpacket->processed();
        outpacket->send();
    }
};

REGISTER_IMPLEMENTATION(ToLower_impl);

Igen er det væsentligt at give metoden navnet process_strømnavn.

Som du kan se, så får du et kald til en funktion for hver pakke som ankommer (process_indata i vort tilfælde). Du skal kalde metoden processed() for en pakke for at angive at du har behandlet den.

Her er et implementeringstip: Hvis det tager lang tid at behandle data (dvs. hvis du skal vente på udskrift til lydkortet eller noget sådant), så kald ikke processed med det samme, men opbevar hele datapakken og kald kun processed når du virkelig har behandlet pakken. På denne måde, har afsenderne en chance for at vide hvor lang tid det virkelig tager at udføre arbejdet.

Eftersom synkronisering ikke er så behagelig med asynkrone strømme, skal man bruge synkrone strømme så ofte som muligt, og kun asynkrone hvis det er nødvendigt.

Antag at du har to objekter, for eksempel en AudioProducer og en AudioConsumer. AudioProducer har en uddatastrøm og AudioConsumer har en inddatastrøm. Hver gang du vil forbinde dem, bruger du disse to strømme. Den første brug af defaulting er at lade dig oprette forbindelsen uden at angive portene i dette tilfælde.

Antag nu at de to objekter ovenfor kan håndtere stereo, og begge har en “venstre” og “højre” port. Du vil stadigvæk skulle kunne koble dem sammen lige så let som tidligere. Men hvordan kan forbindelsesystemet vide hvilken udgang som skal kobles til hvilken indgang? Det har ingen måde at koble strømmene rigtigt sammen. Defaulting bruges så til at angive flere strømme med en vis rækkefølge. På den måde, hvis du forbinder et objekt med to standard uddatastrømme til et andet med to standard inddatastrømme, behøver du ikke angive portene, og forbindelserne gøres rigtigt.

Dette er naturligvis ikke begrænset til stereo. Hvilket som helst antal strømme kan gøres standard hvis det behøves, og forbindelsesfunktionen kontrollerer at antallet af standarder for to objekter passer sammen (med de angivne retninger) hvis du ikke angiver portene som skal bruges.

Syntaksen er den følgende: I IDL kan du bruge nøgleordet default i strømdeklarationen, eller på en enkelt linje. For eksempel:

interface TwoToOneMixer {
    default in audio stream input1, input2;
    out audio stream output;
};

I dette eksempel kommer objektet til at forvente at dets to inddataporte skal forbindes som standard. Rækkefølgen er den som angives på linjen, så et objekt som dette:

interface DualNoiseGenerator {
    out audio stream bzzt, couic;
    default couic, bzzt;
};

laver automatisk en forbindelse fra “couic” til “input1”, og “bzzt” til “input2” Bemærk at eftersom der kun er én udgang for mikseren, kommer den til at være standard i dette tilfælde (se nedenfor). Syntaksen som bruges i støjgeneratoren er nyttig til for at angive en anden rækkefølge end i deklarationen, eller til kun at vælge nogle få porte som standard. Retningen på portene på denne linje slås op af mcopidl, så angiv dem ikke. Du kan til og med blande ind- og udporte på en sådan linje, kun rækkefølgen spiller en rolle.

Der er nogle regler som følges når arv bruges:

Når du implementerer objekter som har egenskaber, skal du sende ændringsmeddelelser så snart en egenskab ændres. Koden til at gøre dette ser sådan her ud:

void KPoti_impl::value(float newValue)
 {
     if(newValue != _value)
     {
         _value = newValue;
         value_changed(newValue); // <- send ændringsmeddelelse
     }
 }

Det anbefales varmt at bruge kode som denne for alle objekter som du implementerer, så ændringsmeddelelser kan bruges af andre. Du bør dog undgå at sende meddelelser for ofte, så hvis du laver signalbehandling er det formodentlig bedst at holde styr på hvornår du sendte din seneste meddelelse, så du ikke sender en for hver sampling.

Det vil være særligt nyttigt at bruge ændringsmeddelelser sammen med målere (objekter som for eksempel visualiserer lyddata), grafiske grænseflader, kontrolelementer og monitorer. Kode som bruger dette findes i kdelibs/arts/tests, og i den eksperimentelle artsgui-implementation, som du finder i kdemultimedia/arts/gui.

I MCOP er der ingen “in” og “out” parametre for metodekald. Parametre er altid indgående, og returværdien er altid udgående, hvilket betyder at grænsefladen:

// CORBA idl
interface Account {
  void deposit( in long amount );
  void withdraw( in long amount );
  long balance();
};

skrives som

// MCOP idl
interface Account {
  void deposit( long amount );
  void withdraw( long amount );
  long balance();
};

i MCOP.

Der er ingen støtte for undtagelser. MCOP har ikke undtagelser, den bruger noget andet til fejlhåndtering.

Der er ingen union-typer og ingen typedefinitioner. Jeg ved ikke om det er en virkelig svaghed, noget man desperat behøver for at overleve.

Der er ingen understøttelse for at sende grænseflader eller objektreferencer

Du deklarerer sekvenser som “sequencetyp” i MCOP. Der er intet behov for en typedefinition. For eksempel, i stedet for:

// CORBA idl
struct Line {
    long x1,y1,x2,y2;
};
typedef sequence<Line> LineSeq;
interface Plotter {
    void draw(in LineSeq lines);
};

ville du skrive

// MCOP idl
struct Line {
    long x1,y1,x2,y2;
};
interface Plotter {
    void draw(sequence<Line> lines);
};

Du kan deklarere strømme, som senere behandles af aRts' skelet. Strømme deklareres på en måde som ligner egenskaber. For eksempel:

// MCOP idl
interface Synth_ADD : SynthModule {
    in audio stream signal1,signal2;
    out audio stream outvalue;
};

Dette betyder at dit objekt vil acceptere to indkommende synkrone lydstrømme som kaldes signal1 og signal2. Synkron betyder at de er strømme som leverer x samplinger pr sekund (eller anden tid), så skemalæggeren altid garanterer at du får en balanceret mængde inddata (f.eks. 200 samplinger af signal1 er der og 200 samplinger af signal2 er der). Du garanterer at hvis dit objekt kaldes med disse 200 samplinger af signal1 + signal2, så kan det producere præcis 200 samplinger uddata.

Dette adskiller sig fra CORBA i hovedsagen hvad angår:

Efter at have sendt dem gennem IDL-oversætteren, skal du aflede fra klassen _skel. Antag for eksempel at du har defineret grænsefladen sådan her:

// MCOP idl: hello.idl
interface Hello {
    void hello(string s);
    string concat(string s1, string s2);
    long sum2(long a, long b);
};

Du sender det gennem IDL-oversætteren ved at kalde mcopidl hello.idl, som derefter laver hello.cc og hello.h. For at implementere dette, behøver du en C++ klasse som arver skelettet:

// C++ deklarationsfil - indsæt hello.h et sted
class Hello_impl : virtual public Hello_skel {
public:
    void hello(const string& s);
    string concat(const string& s1, const string& s2);
    long sum2(long a, long b);
};

Til sidst skal du implementere metoderne som almindelig C++.

// C++ implementeringsfil

// som du ser sendes strenge som konstante strengreferencer
void Hello_impl::hello(const string& s)
{
    printf("Hello '%s'!\n",s.c_str());
}

// når de er en returværdi sendes de som "normale" strenge
string Hello_impl::concat(const string& s1, const string& s2)
{
    return s1+s2;
}

long Hello_impl::sum2(long a, long b)
{
    return a+b;
}

Når du har gjort dette, har du et objekt som kan kommunikere med MCOP. Opret kun et (med de normale C++ faciliteter til at oprette et objekt):

Hello_impl server;

Og så snart du giver nogen referencen

string reference = server._toString();
    printf("%s\n",reference.c_str());

og gå til MCOP:s venteløkke

Dispatcher::the()->run();

har alle adgang til objektet med

// denne kode kan køre hvorsomhelst - ikke nødvendigtvis i samme proces
// (den kan også køre på en anden maskine/arkitektur)

    Hello *h = Hello::_fromString([objektreferencen som blev udskrevet ovenifor]);

og kalde-metoder:

if(h)
        h->hello("test");
    else
        printf("Adgang mislykkedes?\n");

Den har begrebsmæssige ligheder med CORBA, men er beregnet til at kunne udvides på alle måder som kræves for multimediaoperationer i realtid.

Den sørger for en multimediaobjektmodel, som både kan bruges til kommunikation mellem komponenter i et adresserum (en proces), og mellem komponenter som findes i forskellige tråde, processer eller på forskellige værtsmaskiner.

Totalt set, vil den blive konstrueret til ekstremt høj ydelse (så alt skal optimeres for at være voldsomt hurtigt), passende for meget kommunikationsintensive multimedieprogrammer. At for eksempel sende video rundt er en af tilpasningerne for MCOP, hvor de fleste CORBA-implementationer ville gå i knæ.

Grænsefladedefinitionerne kan håndtere følgende selv:

og de vigtigste CORBA-kneb, såsom

Konstruktionsmål/idéer:

Kodningen af de forskellige typer vises i tabellen nedenfor:

struct test {
    string name;        // som er "hello"
    long value;         // som er 10001025  (0x989a81)
};

Hvis du har brug for at henvise til en type, angives alle primitive typer med navnene som findes ovenfor. Strukturer og nummereringstyper får deres egne navne (som Header). Sekvenser benævnes som *normal type, så en sekvens af long er “*long” og en sekvens af Header struct'er er “*Header”.

Formatet på MCOP's meddelelseshovede defineres af denne struktur:

struct Header {
    long magic;          // værdien 0x4d434f50, som kodes som MCOP
    long messageLength;
    long messageType;
};

De mulige meddelelsetyper er for øjeblikket

mcopServerHello                = 1
 mcopClientHello                = 2
 mcopAuthAccept                        = 3
 mcopInvocation                        = 4
 mcopReturn                                = 5
 mcopOnewayInvocation   = 6

Lidt information om MCOP's meddelelseshåndtering:

Meddelelseslængden i hovedet er naturligvis sommetider redundant, hvilket gør at metoden ikke altid er minimal med hensyn til antal byte.

Dette giver dog en enkel (og hurtig) implementation for behandling af meddelelser som ikke blokerer. Ved hjælp af hovedet kan meddelelser modtages af protokolhåndteringsklasser i baggrunden (uden blokering), hvis der er mange forbindelser til serveren kan alle behandles parallelt. Man behøver ikke kigge på meddelelsens indhold for at tage imod en meddelelse (og afgøre når man er klar), kun på hovedet, så koden for dette er ganske enkel.

Når en meddelelse er på plads, kan den afkodes og behandles i et enkelt skridt, uden at bryde sig om tilfælde hvor al data måske ikke er modtaget (eftersom meddelelseslængden garanterer at alt er på plads).

For at kalde en fjernmetode, skal man sende følgende struktur i en MCOP-meddelelse med messageType = 1 (mcopInvocation):

struct Invocation {
    long objectID;
    long methodID;
    long requestID;
};

derefter sendes parametrene som en struktur, f.eks. hvis man kalder metoden "string concat(string s1, string s2)", sendes strukturen

struct InvocationBody {
    string s1;
    string s2;
};

hvis metoden deklareredes som envejs, hvilket betyder asynkront uden returværdi, er det alt. Ellers får man en meddelelse som svar med messageType = 2 (mcopReturn).

struct ReturnCode {
    long requestID;
    <resulttype> result;
};

hvor <resulttype> er typen for resultatet. Eftersom void-typer udelades ved kodning, kan man også kun angive requestID hvis man returnerer fra en void-metode.

Så vor "string concat(string s1, string s2)" ville give en returkode som

struct ReturnCode {
    long   requestID;
    string result;
};

For at lave kald, skal man kende til metoderne som et objekt understøtter. For at gøre dette, er methodID 0, 1, 2 og 3 hårdkodede for visse funktioner. Det vil sige

long _lookupMethod(MethodDef methodDef);                                // metode-id altid 0
string _interfaceName();                                                                // metod-id altid 1
InterfaceDef _queryInterface(string name);                                // metodie-id altid 2
TypeDef _queryType(string name);                                                // metodie-id altid 3

for at læse dette, behøver du naturligvis også

struct MethodDef {
        string  methodName;
        string  type;
        long    flags;        // nu sat til 0 (kræves for strømme)
        sequence<ParamDef> signature;
};

struct ParamDef {
        string name;
        long   typeCode;
};

parameterfeltet indeholder typekomponenter som angiver typerne for parametrene. Typen for returkoden angives i typefeltet for MethodDef.

Hvis man skal være streng, er det kun metoderne _lookupMethod() og _interfaceName() som varierer fra objekt til objekt, mens _queryInterface() og _queryType() altid er ens.

Hvad er en sådan her methodID? Hvis man laver et MCOP-kald, forventes man at sende nummeret for metoden som kaldes. Årsagen til dette er at numre kan behandles meget hurtigere end strenge når en MCOP-forespørgsel køres.

Så hvordan skaffer man sig et sådan nummer? Hvis man kender til signaturen for metoden, dvs. en MethodDef som beskriver den (som indeholder navn, type, parameternavn, parametertyper og lignende), så kan man sende den til _lookupMethod for objektet hvor man vil kalde en metode. Eftersom _lookupMethod er hårdkodet til methodID 0, skulle det ikke være nogen problem at gøre dette.

Hvis man på den anden side ikke kender til metodens signatur, kan man finde hvilke metoder der understøttes ved at bruge _interfaceName, _queryInterface og _queryType.

Brugerdefinerede datatyper beskrives med strukturen TypeDef:

struct TypeComponent {
        string type;
        string name;
};

struct TypeDef {
        string name;

        sequence<TypeComponent> contents;
};

C-grænsefladen for aRts oprettedes for at gøre det let at skrive og overføre enkle C-programmer til aRts lydserver. Den sørger for strømningsfunktioner (at sende samplingsstrømme til artsd), enten med eller uden blokering. For de fleste programmer tager man helt enkelt de få systemkald væk som håndterer lydenheden og skifter dem ud mod passende kald til aRts.

Jeg lavede to overførsler for at verificere idéen: mpg123 og quake. Du kan skaffe programrettelserne herfra. Bidrag gerne med dine egne programrettelser til vedligeholderen af aRts eller til programmelpakken for multimedia så de kan integrere understøttelsen for aRts i deres kode.

At sende lyd til lydserveren med grænsefladen er meget enkelt:

Her er et eksempel på et lille program som viser dette:

#include <stdio.h>
#include <artsc.h>
int main()
{
    arts_stream_t stream;
    char buffer[8192];
    int bytes;
    int errorcode;

    errorcode = arts_init();
    if (errorcode < 0)
    {
        fprintf(stderr, "arts_init fejl: %s\n", arts_error_text(errorcode));
        return 1;
    }

    stream = arts_play_stream(44100, 16, 2, "artsctest");

    while((bytes = fread(buffer, 1, 8192, stdin)) > 0)
    {
        errorcode = arts_write(stream, buffer, bytes);
        if(errorcode < 0)
        {
            fprintf(stderr, "arts_write fejl: %s\n", arts_error_text(errorcode));
            return 1;
        }
    }

    arts_close_stream(stream);
    arts_free();

    return 0;
}

For let at kunne kompilere og linke programmer med aRts C-grænseflade, findes værktøjet artsc-config som kender til hvilke biblioteker som man skal linke med og hvor deklarationsfilerne findes. Det kaldes med

artsc-config --libs

for at finde ud af bibliotekerne og

artsc-config --cflags

for at finde ud af yderligere C-oversætterflag. Eksemplet ovenfor ville være kunnet kompileres med kommandolinjen:

cc -o artsctest artsctest.c `artsc-config --cflags` `artsc-config --libs`

cc -o artsctest artsctest.c `artsc-config --cflags` `artsc-config --libs`

[HUSK: opret dokumentation for artsc.h med kdoc]