Handbok aRts

Starta aRts-byggaren.

Du behöver en Synth_AMAN_PLAY-modul för att höra utdata som du skapar. Så skapa en Synth_AMAN_PLAY-modul genom att välja Moduler->Syntes->Ljud-IO->Synth_AMAN_PLAY och klicka på den tomma modulytan. Placera den nedanför den femte raden ungefär, eftersom vi kommer att lägga till en del grejor ovanför.

Modulen kommer att ha en parameter title (porten längst till vänster), och autoRestoreID (intill porten längst till vänster) för att den ska kunna hittas. För att fylla i de här, dubbelklicka på portarna, välj konstant värde och skriv handledning i textrutan. Klicka OK för att verkställa.

Välj Arkiv->Kör struktur. Du hör absolut ingenting. Uppspelningsmodulen behöver också någon indata... ;) Om du har lyssnat på tystnaden ett tag, klicka Avsluta och gå till steg 2.

Skapa en Synth_WAVE_SIN-modul (från Moduler->Syntes->Vågformer) och placera den ovanför Synth_AMAN_PLAY-modulen (lämna en rads mellanrum mellan dem).

Som du ser, så producerar den någon utdata, men kräver pos som indata. Låt oss först ansluta utporten till högtalarna. Klicka på porten out på Synth_WAVE_SIN och sedan på porten left på Synth_AMAN_PLAY. Voila, du har kopplat ihop två moduler.

Oscillatorer i aRts kräver inte en frekvens som indata, utan istället en position i vågformen. Positionen ska vara mellan 0 och 1, som i ett standardobjekt Synth_WAVE_SIN översätts till området 0 .. 2*Pi. För att skapa oscillerande värden från en frekvens, används en Synth_FREQUENCY modul.

Skapa en Synth_FREQUENCY-modul (från Moduler->Syntes->Oscillation & modulation) och anslut dess “pos” utgång till “pos” ingången på Synth_WAVE_SIN. Sätt frekvensporten för frekvensgeneratorn till det konstanta värdet 440.

Välj Arkiv->Kör struktur. Du kommer att höra en sinusvåg på 440 Hz i en av dina högtalare. Om du har lyssnat på den ett tag, klicka Avsluta och gå till steg 3.

OK, det vore trevligare om du kunde höra sinusvågen i båda högtalarna. Anslut den högra porten på Synth_PLAY till utgången från Synth_WAVE_SIN också.

Skapa ett Synth_SEQUENCE-objekt (från Moduler->Syntes->Midi & sekvensiering). Det ska placeras överst på skärmen. Om du behöver mer utrymme kan du flytta de andra modulerna genom att markera dem (för att markera flera moduler håll nere skifttangenten), och dra omkring dem.

Anslut nu frekvensutgången på Synth_SEQUENCE till frekvensingången på Synth_FREQUENCY-modulen. Ange sedan sekvensens hastighet som konstant värde 0.13 (hastigheten är porten längs till vänster).

Gå nu till porten längs till höger (seq) på Synth_SEQUENCE och skriv in A-3;C-4;E-4;C-4; som konstant värde. Det här anger en sekvens. Mer om detta i modulreferensen.

Välj Arkiv->Kör struktur. Du kommer att höra en trevlig sekvens spelas upp. Om du har njutit av känslan, klicka Avsluta och gå till steg 4.

Skapa en Synth_PSCALE-modul (från Moduler->Syntes->Envelopper). Koppla bort utgången från sinusvågen genom att dubbelklicka på den och välja inte ansluten. Anslut

Till slut, sätt PSCALE top till något värde, till exempel 0.1.

Hur fungerar detta nu: Synth_SEQUENCE ger ytterligare information om positionen för tonen den spelar just nu, där 0 betyder precis påbörjad och 1 betyder avslutad. Modulen Synth_PSCALE skalar ljudflödet som skickas genom den från volymen 0 (tyst) till 1 (ursprunglig ljudstyrka) tillbaka till 0 (tyst) enligt positionen. Positionen där toppen ska ske kan anges som top. 0.1 betyder att efter 10 % av tonen har spelats har volymen nått sitt maximala värde, och börjar sedan avta.

Välj Arkiv->Kör struktur. Du kommer att höra en trevlig sekvens spelas upp. Om du har njutit av känslan, klicka Avsluta och gå till steg 5.

Starta en aRts-byggare till.

Placera en Synth_AMAN_PLAY i den, och ställ in den till ett vettigt namn. Placera en Synth_BUS_DOWNLINK i den och:

Börja köra strukturen. Som väntat hör du ingenting, ... inte än.

Gå tillbaka till strukturen med Synth_WAVE_SIN grejorna och byt ut Synth_AMAN_PLAY-modulen mot en Synth_BUS_UPLINK, och ställ in namnet till ljud (eller Fred om du vill). Att ta bort moduler görs genom att markera dem och välja Redigera->Ta bort från menyn (eller trycka på tangenten Del).

Välj Arkiv->Kör struktur. Du kommer att höra sekvensen med skalade toner, transporterad över bussen.

Om du vill ta reda på varför något sådant här kan vara användbart, klicka Avsluta (i aRts-byggaren som kör Synth_SEQUENCE grejorna, du kan låta den andra fortsätta köra) och gå till steg 6.

Välj Arkiv->Byt namn på struktur från menyn i den aRts-byggare som innehåller Synth_SEQUENCE grejorna, och kalla den handledning. Tryck OK.

Välj Arkiv->Spara som.

Starta ytterligare en aRts-byggare och välj Arkiv->Öppna, och ladda handledningen igen.

Nu kan du välja Arkiv->Kör struktur i båda aRts-byggarna som har strukturen. Nu hör du samma sak två gånger. Beroende på när du startar dem kommer det att låta mer eller mindre bra.

En annan sak som kan vara bra att göra vid det här tillfället är att starta Noatun, och spela en mp3-fil. Starta sedan artscontrol. Gå till Visa->Visa ljudhanterare. Vad du ser är Noatun och din struktur “handledning” spela upp någonting. Det trevliga som du kan göra är: dubbelklicka på Noatun. Du får nu en lista på tillgängliga bussar. Och ser du? Du kan låta Noatun skicka sin utmatning via ljudbussen till uppspelningsstrukturen som din handledning tillhandahåller.

Till slut, nu ska du kunna göra om din sinusvåg till ett riktigt instrument. Det här är bara meningsfullt om du har något lämpligt som kan skicka MIDI-händelser till aRts. Här beskriver jag hur du kan använda ett externt keyboard, men en sequencer, som Brahms, som känner till midibussen fungerar också.

Först av allt, rensa på ditt skrivbord till du bara har en aRts-byggare med sinusvågstrukturen igång (men låt den inte köra). Gå därefter tre gånger till Portar->Skapa IN-ljudsignal, och tre gånger till Portar->Skapa UT-ljudsignal. Placera portarna någonstans.

Gå till Portar+Ändra positioner/namn och döp portarna till frequency, velocity, pressed, left, right, done.

Till sist kan du ta bort modulen Synth_SEQUENCE, och istället ansluta inporten frequency för strukturen till frekvensporten på Synth_FREQUENCY. Hmm. Men vad ska man göra med pos?

Den här är inte tillgänglig, eftersom det inte finns någon algoritm i värden som kan förutse när användaren ska släppa tangenten han just tryckte ner på sitt midi-keyboard. Vi har istället parametern pressed, som bara anger om användaren fortfarande håller nere tangenten. (pressed = 1: tangenten fortfarande nertryckt, pressed = 0: tangenten släppt)

Det här betyder också att Synth_PSCALE-objektet måste bytas ut nu. Koppla in en Synth_ENVELOPE_ADSR istället (från Moduler->Syntes->Envelopper). Anslut:

Ställ in parametrarna attack till 0.1, decay till 0.2, sustain till 0.7, release till 0.1.

En sak till som vi måste tänka på är att instrumentstrukturen måste på något sätt veta när den har spelat färdigt och då kunna rensas bort, eftersom den annars aldrig skulle stanna även om tangenten har släppts. Som tur är, vet ADSR enveloppen när det inte finns mer att höra, eftersom den ändå skalar ner signalen till noll vid någon tidpunkt efter tangenten har släppts.

Det här anges genom att sätta utgången done till 1. Så anslut den här till strukturens utgång. Strukturen tas bort så fort done blir 1.

Döp om din struktur till instrument_handledning (från Arkiv->Byt namn på struktur. Spara den sedan med Spara som (det förvalda namnet som nu anges ska vara instrument_handledning).

Starta aRts control, och gå till Visa->Visa midihanterare, och välj Lägg till->aRts synthes midi utmatning. Till sist ska du kunna välja ditt instrument (handledning) här.

Öppna en terminal och skriv midisend. Du kommer att se att midisend och instrumentet nu listas i aRts MIDIhanterare. Efter att ha valt båda två och tryckt på Anslut, är vi till sist klara. Ta ditt keyboard och börja spela (det måste förstås vara anslutet till din dator).

Du bör nu kunna arbeta med aRts. Här är några tips om vad du nu skulle kunna göra för att förbättra dina strukturer:

Om du har skapat något storartat, fundera gärna på att tillhandahålla det till aRts webbsida, eller för att ingå i nästa utgåva.

Anta att du har ett program som heter “muspling” (som ska avge ett “pling” ljud om du klickar på en musknapp). Latenstiden är tiden mellan ditt finger trycker på musknappen och du hör plinget. Latenstiden för det här scenariot består av flera olika latenstider, som har olika orsaker.

För det här enkla programmet uppstår latenstiden på följande ställen:

De första tre punkterna är latenstid utanför aRts. De är intressanta, men utanför det här dokumentets omfattning. Hur som helst, var medveten om att de finns, så att även om du har optimerat allting annat till verkligt små värden, så kanske du inte nödvändigtvis får exakt det resultat du förväntar dig.

Att be servern att spela någonting innebär oftast bara ett enda MCOP-anrop. Det finns mätningar som bekräftar att det går att be servern att spela någonting 9000 gånger per sekund med den nuvarande implementeringen, på samma värddator med Unix domänuttag. Jag antar att det mesta av det här är kärnans omkostnad, för att byta från en process till en annan. Naturligtvis ändras det här värdet med de exakta typerna på parametrarna. Om man överför en hel bild med ett anrop, blir det långsammare än om man bara överför ett "long" värde. Detsamma är sant för returvärdet. För vanliga strängar (som filnamnet på wav-filen som ska spelas) ska inte det här vara ett problem.

Det här betyder att vi kan approximera den här tiden med 1/9000 sekund, det vill säga under 0,15 ms. Vi kommer att se att detta inte är relevant.

Därefter kommer tiden efter servern börjar spela och ljudkortet tar emot någonting. Servern måste buffra data, så att inga pauser hörs när andra program, som din X11-server eller “muspling”-programmet, kör. Det sätt som detta hanteras på Linux® är att det finns ett antal fragment av en viss storlek. Servern fyller på fragment, och ljudkortet spelar fragment.

Så antag att det finns tre fragment. Servern fyller det första och ljudkortet börjar spela det. Servern fyller det andra. Servern fyller det tredje. Servern är klar och andra program kan nu göra någonting.

När ljudkortet har spelat det första fragmentet, börjar det spela det andra och servern börjar fylla det första igen, och så vidare.

Den maximala latenstiden du får med allt detta är (antal fragment) * (storlek på varje fragment) / (samplingsfrekvens * (storlek på varje sampling)). Om vi antar 44 kHz stereo, och sju fragment på 1024 byte (de nuvarande förvalda inställningarna i aRts), så får vi 40 ms.

De här värdena kan anpassas enligt dina behov. CPU-användningen ökar dock med mindre latenstider, eftersom ljudservern måste fylla på buffrarna oftare, och med mindre delar. Det är också oftast omöjligt att nå bättre värden utan att ge ljudservern realtidsprioritet, eftersom man annars ofta får pauser.

Det är i alla fall realistiskt att göra någonting i stil med 3 fragment med 256 byte vardera, som skulle ändra det här värdet till 4,4 ms. Med 4,4 ms fördröjning skulle aRts CPU-användning vara ungefär 7,5 %. Med en 40 ms fördröjning, skulle den vara ungefär 3 % (för en PII-350, och värdet kan bero på ditt ljudkort, version av kärnan och annat).

Så är det tiden som det tar för pling-ljudet att gå från högtalarna till dina öron. Antag att ditt avstånd från högtalarna är 2 meter. Ljud rör sig med hastigheten 330 meter per sekund. Så vi kan uppskatta den här tiden till 6 ms.

Program med ljudflöden är de som skapar sitt ljud själva. Tänk dig ett spel som skickar ett konstant flöde med samplingar, och nu ska anpassas att spela upp ljud via aRts. Som ett exempel: när jag trycker på en tangent så hoppar figuren som jag använder, och ett bång-ljud spelas upp.

Först så måste du veta hur aRts hanterar strömmar. Det är mycket likt I/O med ljudkortet. Spelet skickar några paket med samplingar till ljudservern, låt oss anta tre stycken. Så fort som ljudservern är klar med det första paketet, skickar det en bekräftelse tillbaka till spelet att det paketet är klart.

Spelet skapar ytterligare ett ljudpaket och skickar det till servern. Under tiden börjar servern konsumera det andra ljudpaketet, och så vidare. Latenstiden här liknar den i det enklare fallet:

De externa latenstiderna, som ovan, är utanför det här dokumentets omfattning.

Det är uppenbart att latenstiden för strömmar beror på tiden det tar för alla paket som används att spelas en gång. Så den är (antal paket) * (storlek på varje paket) / (samplingsfrekvensen * (storlek på varje sampling)).

Som du ser är detta samma formel som gäller för fragmenten. För spel finns det dock ingen anledning att ha så korta fördröjningar som ovan. Jag skulle vilja säga att ett realistiskt exempel för ett spel skulle vara 2048 byte per paket, använd 3 paket. Latenstidsresultatet skulle då vara 35 ms.

Det här är baserat på följande: antag att ett spel renderar 25 bilder per sekund (för skärmen). Det är antagligen helt säkert att anta att en skillnad på en bild för ljudutmatningen inte skulle märkas. Därför är 1/25 sekunds fördröjning för ljudflöden acceptabelt, vilket i sin tur betyder att 40 ms skulle vara ok.

De flesta personer kör inte heller sina spel med realtidsprioritet, och faran med pauser i ljudet kan inte bortses ifrån. Strömmar med 3 paket på 256 byte är möjliga (jag provade det) - men orsakar mycket CPU-användning för strömhantering.

Latenstider på serversidan kan du beräkna precis som ovan.

Det finns många faktorer som påverkar CPU-användning i ett komplext scenario, med några program med ljudflöden och några andra program, några insticksprogram i servern, etc. För att ange några få:

För beräkning av rå CPU-användning, om du spelar upp två strömmar samtidigt måste du göra additioner. Om du applicerar ett filter, är vissa beräkningar inblandade. För att ta ett förenklat exempel, att addera två strömmar kräver kanske fyra CPU-cykler per addition, på en 350 MHz processor är detta 44100 * 2 * 4 / 350000000 = 0,1 % CPU-användning.

aRts interna schemaläggning: aRts behöver bestämma vilken insticksmodul som ska beräkna vad när. Detta tar tid. Använd ett profileringsverktyg om du är intresserad av det. Vad som kan sägas i allmänhet är att ju mindre realtid som används (dvs. ju större block som kan beräknas åt gången) desto mindre schemaläggningsomkostnad fås. Över beräkning av block med 128 samplingar åt gången (alltså med användning av fragmentstorlekar på 512 byte) är schemaläggningsomkostnad förmodligen inte värt att bry sig om.

Konvertering från heltal till flyttal: aRts använder flyttal som internt dataformat. De är enkla att hantera, och på moderna processorer inte mycket långsammare än heltalsoperationer. Om det i alla fall finns klienter som spelar data som inte är flyttal (som ett spel som ska göra sin ljudutmatning via aRts), behövs konvertering. Detsamma gäller om du vill spela upp ljud på ditt ljudkort. Ljudkortet behöver heltal, så du måste konvertera.

Här är värden för en Celeron, ungefärliga klockcykler per sampling, med -O2 och egcs 2.91.66 (mätta av Eugene Smith (hamster AT null.ru)). Det här är förstås ytterst processorberoende:

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å detta betyder 1 % CPU-användning för konvertering och 5 % för interpolation på den här 350 MHz processorn.

MCOP protokollomkostnad: MCOP klarar, som en tumregel, 9000 anrop per sekund. En stor del av detta är inte MCOP:s fel, utan hör ihop med de två orsakerna för kärnan som nämns nedan. Det här ger i alla fall en bas för att göra beräkningar av vad kostaden för strömhantering är.

Varje datapaket som skickas med en ström kan anses vara ett MCOP-anrop. Stora paket är förstås långsammare än 9000 paket/s, men det ger en god idé.

Antag att du använder paketstorlekar på 1024 byte. På så sätt, för att överföra en ström med 44 kHz stereo, behöver du överföra 44100 * 4 / 1024 = 172 paket per sekund. Antag att du kunde överföra 9000 paket med 100 % CPU-användning, då får du (172 *100) / 9000 = 2 % CPU-användning på grund av strömmen med 1024 byte paket.

Detta är en approximation. Det visar i alla fall att du skulle klara dig mycket bättre (om du har råd med latenstiden), med att till exempel använda paket på 4096 byte. Här kan vi skapa en kompakt formel, genom att beräkna paketstorleken som orsakar 100 % CPU-användning som 44100 * 4 / 9000 = 19,6 samplingar, och på så sätt få snabbformeln:

CPU-användning för en ström i procent = 1960 / (din paketstorlek)

som ger oss 0,5 % CPU-användning med en ström av 4096 byte paket.

Kärnans process/sammanhangsbyte: Det här är en del av MCOP-protokollets omkostnad. Att byta mellan två processer tar tid. Det blir en ny minnesmappning, cachar blir ogiltiga, och en del annat (om en expert på kärnan läser det här - tala om de exakta orsakerna för mig). Det här betyder: det tar tid.

Jag är inte säker på hur många processbyten Linux® kan göra per sekund, men värdet är inte oändligt. Så av MCOP-protokollets omkostnad, antar jag att en hel del beror på processbyten. När MCOP först påbörjades provade jag samma kommunikation inne i en process, och det var mycket snabbare (ungefär fyra gånger snabbare).

Kärnans kommunikationsomkostnad: Det här är en del av MCOP-protokollets omkostnad. Att överföra data mellan processer görs för närvarande via ett uttag (socket). Det här är bekvämt, eftersom den vanliga select() metoden kan användas för att avgöra när ett meddelande har anlänt. Det kan också kombineras med andra I/O-källor som ljud-I/O, X11-server eller vad som helst annat.

De här läs- och skrivanropen kostar definitivt processorcykler. För små anrop (som att överföra en midi-händelse) är det förmodligen inte så farligt, men för stora anrop (som att överföra en videobild med flera Mibyte) är det helt klart ett problem.

Att lägga till användning av delat minne till MCOP där det är lämpligt är förmodligen den bästa lösningen. Det måste dock göras transparent för tillämpningsprogrammeraren.

Ta ett profileringsverktyg och gör andra prov för att exakt ta reda på hur nuvarande ljudströmmar påverkas av att inte använda delat minne. Det är dock inte så dåligt, eftersom ljudströmmar (spela upp mp3) kan göras med totalt 6 % CPU-användning för artsd och artscat (och 5 % för mp3-avkodaren). Det här innefattar dock allting från nödvändiga beräkningar till omkostnad för uttaget, så jag skulle uppskatta att man skulle vinna ungefär 1 % på att använda delat minne.

De här är gjorda med den nuvarande utvecklingsversionen. Jag ville också försöka med riktigt svåra fall, så det här är inte vad program för daglig användning skulle göra.

Jag skrev ett program som heter streamsound som skickar dataflöden till aRts. Här körs det med realtidsprioritet (utan problem), och en liten insticksmodul på serversidan (volymskalning och klippning):

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

Var och en av programmen skickar en ström med 3 fragment på 1024 byte (18 ms). Det finns tre sådana klienter som kör samtidigt. Jag vet att det verkar vara lite väl mycket, men som jag sa: ta ett profileringsverktyg och ta reda på vad som kostar tid, och om du vill, förbättra det.

Jag tror i alla fall inte att använda strömmar så här är realistiskt eller vettigt. För att göra det hela ännu mer extremt, försökte jag med den minsta möjliga latenstiden. Resultat: man kan använda strömmar utan avbrott med ett klientprogram, om man tar 2 fragment med 128 byte mellan aRts och ljudkortet, och mellan klientprogrammet och aRts. Det här betyder att man har en total maximal latenstid på 128 * 4 / 44100 * 4 = 3 ms, där 1,5 ms skapas på grund av I/O till ljudkortet och 1,5 ms skapas av kommunikation med aRts. Båda programmen måste köra med realtidsprioritet.

Men det här kostar en enorm mängd CPU. Det här exemplet kostar ungefär 45 % på min P-II/350. Det börjar också gå fel om man startar top, flyttar fönster på X11-skärmen eller gör disk-I/O. Allt det här har med kärnan att göra. Problemet är att schemalägga två eller flera processer med realtidsprioritet också kostar en enorm ansträngning, ännu mer än kommunikation och meddelande till varandra, etc.

Till sist, ett mer vardagligt exempel: Det här är aRts med artsd och en artscat (en klient med dataflöde) som kör 16 fragment 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

Varje namnrymdsdeklaration hör ihop med en deklaration av en “modul” i MCOP IDL.

// mcop idl

module M {
    interface A
    {
    }
};

interface B;

I det här fallet skulle den genererade C++ koden för IDL-fragmentet se ut så här:

// C++ deklaration

namespace M {
    /* deklaration av A_base/A_skel/A_stub och liknande */
    class A {        // Smartwrap referensklass
        /* [...] */
    };
}

/* deklaration av B_base/B_skel/B_stub och liknande */
class B {
    /* [...] */
};

Så när du hänvisar till klasserna från exemplet ovan i din C++ kod, måste du skriva M::A, men bara B. Du kan förstås använda “using M” någonstans, som med alla namnrymnder i C++.

Det finns en global namnrymd som kallas “Arts”, som alla program och bibliotek som hör till aRts själv använder för att lägga sina deklarationer i. Det här betyder att när du skriver C++ kod som beror på aRts, måste du normalt använda prefixet Arts:: för varje klass som du använder, så här:

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

    server.play("/var/foo/någon_fil.wav");

Det andra alternativet är att skriva "using" en gång, så här:

using namespace Arts;

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

    server.play("/var/foo/någon_fil.wav");
    [...]

I IDL-filer, har du egentligen inget val. Om du skriver kod som tillhör aRts själv, måste du lägga den i modulen aRts.

// IDL-fil för aRts-kod:
#include <artsflow.idl>
module Arts {        // lägg den i Arts-namnrymd
    interface Synth_TWEAK : SynthModule
    {
        in audio stream invalue;
        out audio stream outvalue;
        attribute float tweakFactor;
    };
};

Om du skriver kod som inte hör till aRts själv, ska du inte lägga den i namnrymden “Arts”. Du kan dock skapa en egen namnrymd om du vill. Hur som helst, måste du använda prefix för klasser från aRts som du använder.

// IDL-fil för kod som inte hör till aRts:
#include <artsflow.idl>

// skriv antingen med eller utan moduldeklaration, och de genererade klasserna
// kommer inte att använda en namnrymd:
interface Synth_TWEAK2 : Arts::SynthModule
{
    in audio stream invalue;
    out audio stream outvalue;
    attribute float tweakFactor;
};

// du kan dock välja en egen namnrymd om du vill, så om du
// skriver programmet "PowerRadio", skulle du kunna göra så här:
module PowerRadio {
    struct Station {
        string name;
        float frequency;
    };

    interface Tuner : Arts::SynthModule {
        attribute Station station;     // inget prefix för Station, samma modul
        out audio stream left, right;
    };
};

MCOP behöver ofta hänvisa till namn på typer och gränssnitt för typkonverteringar, gränssnitt och metodsignaturer. Dessa representeras av strängar i de vanliga MCOP-datastrukturerna, medan namnrymden alltid är fullständigt representerad i C++ stilen. Det här betyder att strängarna skulle innehålla “M::A” och “B”, enligt exemplen ovan.

Observera att detta gäller till och med om namnrymdskvalificeringen inte angavs inne i IDL-texten, eftersom sammanhanget klargör vilken namnrymd gränssnittet A var tänkt att användas.

Att använda trådar är inte möjligt på alla plattformar. Det här är orsaken att aRts ursprungligen skrevs utan att använda trådar alls. För nästan alla problem, finns det en lösning utan trådar som gör samma sak som varje lösning med trådar.

Till exempel, istället för att placera ljudutmatning i en separat tråd, och göra den blockerande, använder aRts ljudutmatning som inte blockerar, och räknar ut när nästa del av utdata ska skrivas med select().

aRts stöder åtminstone (i de senaste versionerna) de som vill implementera sina objekt med trådar. Till exempel om du redan har kod för en mp3-spelare, och koden förväntar sig att mp3-avkodaren ska köras i en separat tråd, är det oftast lättast att behålla den konstruktionen.

Implementeringen av aRts/MCOP är uppbyggd genom att dela tillståndet mellan olika objekt på tydliga och mindre tydliga sätt. En kort lista på delade tillstånd innefattar:

Inget av de ovanstående objekten förväntar sig att användas med samtidighet (dvs. anropas från olika trådar samtidigt). I allmänhet finns det två sätt att lösa detta:

aRts använder det första sättet. Du behöver ett lås varje gång du ska komma åt några av de här objekten. Det andra sättet är svårare att göra. En snabbfix som försöker åstadkomma detta finns på http://space.twc.de/~stefan/kde/download/arts-mt.tar.gz, men för närvarande fungerar förmodligen ett minimalt sätt bättre, och orsakar mindre problem med befintliga program.

Du kan skaffa/släppa låset med de två funktionerna:

I allmänhet behöver du inte skaffa ett lås (och du ska inte försöka att göra det), om det redan hålls. En lista på villkor när detta är fallet är:

Det finns också några undantag för funktioner som du bara kan anropa i huvudtråden, och av den anledningen aldrig behöver ett lås för att anropa dem:

Men det är allt. För allt annat som på något sätt hör ihop med aRts, måste du skaffa låset, och släppa det igen när du är klar. Här är ett enkelt exempel:

class SuspendTimeThread : Arts::Thread {
public:
    void run() {
        /*
         * du behöver det här låset därför att:
         *  - skapa en referens behöver ett lås (eftersom global: går till
         *    objekthanteraren, som i sin tur kan behöva GlobalComm
         *    objektet för att slå upp vart anslutningen ska göras)
         *  - tilldela en smartwrapper behöver ett lås
         *  - skapa ett objekt från en referens behöver ett lås (eftersom
         *    det kan behöva ansluta till en server)
         */
        Arts::Dispatcher::lock();
        Arts::SoundServer server = Arts::Reference("global:Arts_SoundServer");
        Arts::Dispatcher::unlock();

        for(;;) {            /*
             * du behöver ett lås här, eftersom
             *  - följa en referens för en smartwrapper behöver ett lås
             *    (eftersom det kan skapa objektet när det används)
             *  - att göra ett MCOP-anrop behöver ett lås
             */
            Arts::Dispatcher::lock();
            long seconds = server.secondsUntilSuspend();
            Arts::Dispatcher::unlock();

            printf("sekunder till vänteläge = %d",seconds);
            sleep(1);
        }
    }
}

Följande trådrelaterade klasser finns tillgängliga för närvarande:

Se länkarna för dokumentation.

Eftersom referenser kan peka på fjärrobjekt, kan servrarna som innehåller de här objekten krascha. Vad händer då?

Det finns andra felorsaker, som nerkoppling av nätverket (antag att du tar bort kabeln mellan din server och klient medan ditt program kör). Deras effekt är ändå likadan som en serverkrasch.

Totalt sett är det förstås en policyfråga hur strikt du försöker hantera kommunikationsfel i hela ditt program. Du kan följa metoden “om servern kraschar, måste vi avlusa den till den aldrig kraschar igen”, som skulle betyda att du inte behöver bry dig om alla de här problemen.

Ett objekt måste ägas av någon för att finnas till. Om det inte gör det, kommer det upphöra att finnas till (mer eller mindre) omedelbart. Internt anges en ägare genom att anropa _copy(), som räknar upp en referensräknare, och en ägare tas bort genom att anropa _release(). Så fort referensräknaren når noll, så tas objektet bort.

Som en variation på temat, anges fjärranvändning med _useRemote(), och löses upp med _releaseRemote(). Dessa funktioner har en lista över vilken server som har anropat dem (och därför äger objektet). Det här används om servern kopplar ner (dvs. krasch, nätverksfel), för att ta bort referenser som fortfarande finns till objektet. Det här görs i _disconnectRemote().

Nu finns det ett problem. Betrakta ett returvärde. I vanliga fall ägs inte returvärdesobjektet av funktionen som anropas längre. Det ägs inte heller av den som anropar, förrän meddelandet som innehåller objektet har tagits emot. Så det finns en tid med objekt som “saknar ägare”.

Nu när vi skickar ett objekt kan man vara rimligt säker på att så fort det tas emot, ägs det av någon igen, om inte, återigen, mottagaren kraschar. Det här betyder i alla fall att speciell hänsyn måste tas för objekt åtminstone vid sändning, och troligen också vid mottagning, så att de inte tas bort meddetsamma.

Sättet som MCOP gör det här är genom att “tagga” objekt som håller på att kopieras över nätverket. Innan en sådan kopiering börjar, anropas _copyRemote. Det här förhindrar att objektet tas bort på ett tag (5 sekunder). Så fort mottagaren anropar _useRemote(), tas taggen bort igen. Så alla objekt som skickas över nätverket, taggas innan överföringen.

Om mottagaren tar emot ett objekt som finns på samma server, så används förstås inte _useRemote(). I det här specialfallet, finns funktionen _cancelCopyRemote() för att ta bort taggen manuellt. Förutom detta, finns det också en tidsbaserad borttagning av taggen, om taggning gjordes, men mottagaren verkligen inte fick objektet (på grund av krasch, nätverksfel). Det här görs med klassen ReferenceClean.

Strömmar definierar multimediadata, en av de viktigaste komponenterna i en modul. Strömmar definieras med följande format:

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

Strömmar har en definierad riktning i förhållande till modulen, som anges av de nödvändiga bestämningarna in eller out. Typargumentet definierar datatypen, som kan vara vilken som helst av typerna för egenskaper som beskrivs senare (alla stöds inte än). Många moduler använder strömtypen audio, som är ett alias för float eftersom det är det interna dataformatet för ljudströmmar. Flera strömmar av samma typ kan ingå i samma definition med namn separerade med kommatecken.

Strömmar är normalt synkrona, vilket betyder att de är kontinuerliga dataflöden med en konstant hastighet, som PCM-ljud. Bestämningen async anger en asynkron ström, som används för icke-kontinuerliga dataflöden. Det vanligaste exemplet på en asynkron ström är MIDI-meddelanden.

Nyckelordet multi, som bara är giltigt för indataströmmar, anger att gränssnittet stöder ett variabelt antal ingångar. Det här är användbart för att implementera enheter som en mixer som kan ta emot vilket antal indataströmmar som helst.

Egenskaper är data som hör ihop med en instans av ett gränssnitt. De deklareras som medlemsvariabler i C++, och kan använda vilken som helst av de primitiva typerna boolean, byte, long, string, eller float. Du kan också använda egendefinierade struct- eller uppräkningstyper samt sekvenser av variabel storlek med syntaxen sekvens<typ>. Egenskaper kan valfritt markeras som skrivskyddade.

Som i C++, kan metoder definieras i gränssnitt. Metodparametrarna är begränsade till samma typer som egenskaperna. Nyckelordet oneway anger en metod som returnerar omedelbart och körs asynkront.

Flera gränssnitt för standardmoduler är redan definierade åt dig i aRts, som StereoEffect, och SimpleSoundServer.

Ett enkelt exempel på en modul taget från aRts är modulen med konstant fördröjning, som finns i filen kdemultimedia/arts/modules/artsmodules.idl. Gränssnittsdefinitionen anges nedan:

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

Modulen ärver SynthModule. Det gränssnittet, som finns i artsflow.idl, definierar alla standardmetoder som implementeras i alla syntesmoduler.

CDELAY-effekten fördröjer ett stereoljudflöde med tidsvärdet som anges som en flyttalsparameter. Gränssnittsdefinitionen har ett attribut av typen float för att lagra fördröjningsvärdet. Det definierar två indata- och två utdataströmmar (typiskt för stereoeffekter). Inga metoder krävs förutom de ärvda.

Det finns olika krav för hur en modul kan hantera flöden. För att illustrera detta, betrakta följande exempel:

Det första fallet är det enklaste: när modulen tar emot 200 indatasamplingar producerar den 200 utdatasamplingar. Den producerar bara utdata när den får indata.

Det andra fallet producerar olika antal utdatasamplingar när den får 200 indatasamplingar. Det beror på vilken konvertering som utförs, men antalet är känt i förväg.

Det tredje fallet är ännu värre. Från utdata kan man inte ens gissa hur mycket data som skapas av 200 indatabyte (förmodligen mycket mer än 200 byte, men...).

Det sista fallet är en modul som aktiveras av sig själv, och ibland skapar data.

I aRtss-0.3.4, hanterades bara strömmar av den första typen, och de flesta saker fungerade bra. Det här är troligen vad du behöver mest när du skriver moduler som behandlar ljud. Problemen med de andra, mer komplexa sorternas flöden, är att de är svåra att programmera, och att man inte behöver funktionerna för det mesta. Det här är orsaken vi gör detta med två olika sorters strömtyper: synkrona och asynkrona.

Synkrona strömmar har följande egenskaper:

Asynkrona strömmar, å andra sidan, beter sig så här:

När strömmar deklareras, används nyckelordet “async” för att ange att strömmen ska vara asynkron. Så anta till exempel att du vill konvertera en asynkron ström av byte till en synkron ström av samplingar. Gränssnittet skulle då kunna se ut så här:

interface ByteStreamToAudio : SynthModule {
    async in byte stream indata;   // den asynkrona indatasamplingen

    out audio stream left,right;   // de synkrona utdatasamplingarna
};

Antag att du har bestämt dig för att skriva en modul som skapar asynkront ljud. Dess gränssnitt kan se ut så här:

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

Hur skickar man data? Den första metoden kallas “tryckleverans”. Med asynkrona strömmar skickar man data som paket. Det betyder att individuella paket skickas som i exemplet ovan. Den verkliga processen är: allokera ett paket, fyll det, skicka det.

Här följer det i form av kod. Först allokerar vi ett paket:

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

Vi fyller det:

// typkonvertera så att fgets får en (char *) pekare
char *data = (char *)packet->contents;

// som du ser, kan du krympa paketstorleken efter allokeringen
// om du vill
if(fgets(data,100,stdin))
    packet->size = strlen(data);
else
    packet->size = 0;

Nu skickar vi det:

packet->send();

Det här är mycket enkelt, men om vi vill skicka paket precis så snabbt som mottagaren kan hantera dem, behövs ett annat sätt, metoden med “dragleverans”. Man begär att skicka paket så snabbt som mottagaren är klar att behandla dem. Man börjar med en viss mängd paket som skickas. Medan mottagaren behandlar paket efter paket, börjar man fylla i dem med färsk data, och skickar dem igen.

Du startar det genom att anropa setPull. Till exempel:

outdata.setPull(8, 1024);

Det här betyder att du vill skicka paket via outdata. Du vill börja med att skicka 8 paket på en gång, och när mottagaren behandlar några av dem, vill du fylla dem igen.

Därefter behöver du implementera en metod som fyller paketen, som skulle kunna se ut så här:

void request_outdata(DataPacket<mcopbyte> *packet)
{
    packet->size = 1024;  // ska inte vara mer än 1024
    for(int i = 0;i < 1024; i++)
        packet->contents[i] = (mcopbyte)'A';
    packet->send();
}

Det är allt. När du inte har mer data, kan du börja skicka paket med storleken noll, som stoppar dragleveranserna.

Observera att det är väsentligt att ge metoden exakt namnet request_strömnamn.

Vi beskrev just att skicka data. Att ta emot data är mycket enklare. Antag att du har ett enkelt filter, ToLower, som helt enkelt konverterar alla bokstäver till små:

interface ToLower {
    async in byte stream indata;
    async out byte stream utdata;
};

Det här är verkligt enkelt att implementera. Här är hela implementationen:

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

        // omvandla till små bokstäver
        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);

Återigen är det väsentligt att ge metoden namnet process_strömnamn.

Som du kan se, så får du ett anrop till en funktion för varje paket som anländer (process_indata i vårt fall). Du måste anropa metoden processed() för ett paket för att ange att du har behandlat det.

Här är ett implementeringstips: Om det tar lång tid att behandla data (dvs. om du måste vänta på utmatning till ljudkortet eller något sådant), anropa inte processed omedelbart, utan lagra hela datapaketet och anropa processed bara när du verkligen har behandlat paketet. På detta sätt, har avsändarna en chans att veta hur lång tid det verkligen tar att utföra arbetet.

Eftersom synkronisering inte är så trevlig med asynkrona strömmar, ska man använda synkrona strömmar så ofta det är möjligt, och asynkrona bara om det är nödvändigt.

Antag att du har två objekt, till exempel en AudioProducer och en AudioConsumer. AudioProducer har en utdataström och AudioConsumer har en indataström. Varje gång du vill förbinda dem, använder du de här två strömmarna. Den första användningen av förval är att låta dig upprätta förbindelsen utan att ange portarna i det här fallet.

Antag nu att de två objekten ovan kan hantera stereo, och båda har en “vänster” och “höger” port. Du skulle fortfarande vilja kunna koppla ihop dem lika lätt som tidigare. Men hur kan förbindelsesystemet veta vilken utgång som ska kopplas till vilken ingång? Det har inget sätt att koppla ihop strömmarna korrekt. Förval används då för att ange flera strömmar med en viss ordning. På så sätt, om du ansluter ett objekt med två förvalda utdataströmmar till ett annat med två förvalda indataströmmar, behöver du inte ange portarna, och förbindelserna görs på ett riktigt sätt.

Det här är förstås inte begränsat till stereo. Vilket antal strömmar som helst kan göras förvalda om det behövs, och anslutningsfunktionen kontrollerar att antalet förval för två objekt passar ihop (med de angivna riktningarna) om du inte anger portarna som ska användas.

Syntaxen är den följande: I IDL kan du använda nyckelordet default i strömdeklarationen, eller på en ensam rad. Till exempel:

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

I det här exemplet kommer objektet att förvänta sig att dess två indataportar ska anslutas med förval. Ordningen är den som anges på raden, så ett objekt som det här:

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

skapar automatiskt en förbindelse från “couic” till “input1”, och “bzzt” till “input2” Observera att eftersom det bara finns en utgång för mixern, kommer den att vara förvald i det här fallet (se nedan). Syntaxen som används i brusgeneratorn är användbar för att ange en annan ordning än i deklarationen, eller för att välja bara några få portar som förval. Riktningen på portarna på den här raden slås upp av mcopidl, så ange dem inte. Du kan till och med blanda in- och utportar på en sådan här rad, bara ordningen spelar roll.

Det finns några regler som följs när arv används:

När du implementerar objekt som har egenskaper, måste du skicka ändringsmeddelanden så snart en egenskap ändras. Koden för att göra detta ser ut så här:

void KPoti_impl::value(float newValue)
 {
     if(newValue != _value)
     {
         _value = newValue;
         value_changed(newValue); // <- skicka ändringsmeddelande
     }
 }

Det rekommenderas varmt att använda kod som den här för alla objekt som du implementerar, så att ändringsmeddelanden kan användas av andra. Du bör dock undvika att skicka meddelanden för ofta, så om du gör signalbehandling är det troligen bäst att hålla reda på när du skickade ditt senaste meddelande, så att du inte skickar ett för varje sampling.

Det kommer att vara särskilt användbart att använda ändringsmeddelanden tillsammans med mätare (objekt som till exempel visualiserar ljuddata), grafiska gränssnitt, styrelement och monitorer. Kod som använder det här finns i kdelibs/arts/tests, och i den experimentella artsgui-implementeringen, som du hittar i kdemultimedia/arts/gui.

I MCOP finns det inga “in” och “out” parametrar för metodanrop. Parametrar är alltid ingående, och returvärdet är alltid utgående, vilket betyder att gränssnittet:

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

skrivs som

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

i MCOP.

Det finns inget stöd för undantag. MCOP har inte undantag, det använder något annat för felhantering.

Det finns inga union-typer och inga typdefinitioner. Jag vet inte om det är en verklig svaghet, något man desperat behöver för att överleva.

Det finns inget stöd för att skicka gränssnitt eller objektreferenser

Du deklarerar sekvenser som “sequencetyp” i MCOP. Det finns inget behov av en typdefinition. Till exempel, istället för:

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

skulle du skriva

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

Du kan deklarera strömmar, som sedan behandlas av aRts grundstomme. Strömmar deklareras på ett sätt som liknar egenskaper. Till exempel:

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

Det här betyder att ditt objekt kommer att acceptera två inkommande synkrona ljudströmmar som kallas signal1 och signal2. Synkron betyder att de är strömmar som levererar x samplingar per sekund (eller annan tid), så att schemaläggaren alltid garanterar att du får en balanserad mängd indata (t.ex. 200 samplingar av signal1 finns och 200 samplingar av signal2 finns). Du garanterar att om ditt objekt anropas med de här 200 samplingarna av signal1 + signal2, så kan det skapa precis 200 samplingar utdata.

Det här skiljer sig från CORBA i huvudsak angående:

Efter att ha skickat dem genom IDL-kompilatorn, måste du härleda från klassen _skel. Antag till exempel att du har definierat gränssnittet så här:

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

Du skickar det genom IDL-kompilatorn genom att anropa mcopidl hello.idl, som i sin tur skapar hello.cc och hello.h. För att implementera det, behöver du en C++ klass som ärver stommen:

// C++ deklarationsfil - infoga hello.h någonstans
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);
};

Till sist måste du implementera metoderna som vanlig C++.

// C++ implementeringsfil

// som du ser skickas strängar som konstanta strängreferenser
void Hello_impl::hello(const string& s)
{
    printf("Hello '%s'!\n",s.c_str());
}

// när de är ett returvärde skickas de som "normala" strängar
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 väl har gjort detta, har du ett objekt som kan kommunicera med MCOP. Skapa bara ett (med de normala C++ faciliteterna för att skapa ett objekt):

Hello_impl server;

Och så fort du ger någon referensen

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

och går till MCOP:s väntesnurra

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

kan alla komma åt objektet med

// den här koden kan köra var som helst - inte nödvändigtvis i samma process
// (den kan också köra på en annan dator/arkitektur)

    Hello *h = Hello::_fromString([objektreferensen som skrevs ut ovan]);

och anropa metoder:

if(h)
        h->hello("test");
    else
        printf("Åtkomst misslyckades?\n");

Den har begreppsmässiga likheter med CORBA, men är avsett för att kunna utökas på alla sätt som krävs för multimediaoperationer i realtid.

Den tillhandahåller en multimediaobjektmodell, som både kan användas för kommunikation mellan komponenter i ett adressrum (en process), och mellan komponenter som finns i olika trådar, processer eller på olika värddatorer.

Totalt sett, kommer den att konstrueras för extremt hög prestanda (så att allt ska optimeras för att vara våldsamt snabbt), lämpligt för mycket kommunikationsintensiva multimediaprogram. Att till exempel skicka runt video är en av tillämpningarna för MCOP, där de flesta CORBA-implementeringar skulle gå på knäna.

Gränssnittsdefinitionerna kan hantera följande själv:

och de viktigaste CORBA-knepen, som

Konstruktionsmål/idéer:

Kodningen av de olika typerna visas i tabellen nedan:

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

Om du behöver hänvisa till en typ, anges alla primitiva typer med namnen som finns ovan. Strukturer och uppräkningstyper får sina egna namn (som Header). Sekvenser benämns som *normal typ, så att en sekvens av long är “*long” och en sekvens av Header struct:ar är “*Header”.

Formatet på MCOP:s meddelandehuvud definieras av den här strukturen:

struct Header {
    long magic;          // värdet 0x4d434f50, som kodas som MCOP
    long messageLength;
    long messageType;
};

De möjliga meddelandetyperna är för närvarande

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

Lite information om MCOP:s meddelandehantering:

Meddelandelängden i huvudet är förstås redundant i vissa fall, vilket gör att metoden inte alltid är minimal med avseende på antal byte.

Detta ger dock en enkel (och snabb) implementering för behandling av meddelanden som inte blockerar. Med hjälp av huvudet kan meddelanden tas emot av protokollhanteringsklasser i bakgrunden (utan blockering), om det finns många anslutningar till servern kan alla behandlas parallellt. Man behöver inte titta på meddelandets innehåll för att ta emot ett meddelande (och avgöra när man är klar), bara på huvudet, så koden för detta är ganska enkel.

När ett meddelande väl finns på plats, kan det avkodas och behandlas i ett enda steg, utan att bry sig om fall där all data kanske inte tagits emot (eftersom meddelandelängden garanterar att allt är på plats).

För att anropa en fjärrmetod, måste man skicka följande struktur i ett MCOP-meddelande med messageType = 1 (mcopInvocation):

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

därefter skickas parametrarna som en struktur, t.ex. om man anropar metoden "string concat(string s1, string s2)", skickas strukturen

struct InvocationBody {
    string s1;
    string s2;
};

om metoden deklarerades som envägs, vilket betyder asynkront utan returvärde, är det allt. Annars får man ett meddelande som svar med messageType = 2 (mcopReturn).

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

där <resulttype> är typen för resultatet. Eftersom void-typer utelämnas vid kodning, kan man också bara ange requestID om man returnerar från en void-metod.

Så vår "string concat(string s1, string s2)" skulle ge en returkod som

struct ReturnCode {
    long   requestID;
    string result;
};

För att göra anrop, måste man känna till metoderna som ett objekt stöder. För att göra detta, är methodID 0, 1, 2 och 3 hårdkodade för vissa funktioner. Det vill säga

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

för att läsa detta, behövs förstås också

struct MethodDef {
        string  methodName;
        string  type;
        long    flags;        // nu satt till 0 (krävs för strömmar)
        sequence<ParamDef> signature;
};

struct ParamDef {
        string name;
        long   typeCode;
};

parameterfältet innehåller typkomponenter som anger typerna för parametrar. Typen för returkoden anges i typfältet för MethodDef.

För att vara strikt, är det bara metoderna _lookupMethod() och _interfaceName() som varierar från objekt till objekt, medan _queryInterface() och _queryType() alltid är likadana.

Vad är ett sådant här methodID? Om man gör ett MCOP-anrop, förväntas man skicka numret för metoden som anropas. Orsaken till detta är att nummer kan behandlas mycket snabbare än strängar när en MCOP-begäran körs.

Så hur skaffar man sig ett sådant här nummer? Om man känner till signaturen för metoden, dvs. en MethodDef som beskriver den (som innehåller namn, typ, parameternamn, parametertyper och liknande), så kan man skicka den till _lookupMethod för objektet där man vill anropa en metod. Eftersom _lookupMethod är hårdkodad till methodID 0, ska det inte vara några problem att göra detta.

Om man å andra sidan inte känner till metodens signatur, kan man ta reda på vilka metoder som stöds genom att använda _interfaceName, _queryInterface och _queryType.

Användardefinierade datatyper beskrivs med strukturen TypeDef:

struct TypeComponent {
        string type;
        string name;
};

struct TypeDef {
        string name;

        sequence<TypeComponent> contents;
};

C-gränssnittet för aRts skapades för att göra det lätt att skriva och anpassa enkla C-program till aRts ljudserver. Det tillhandahåller flödesfunktioner (att skicka samplingsströmmar till artsd), antingen med eller utan blockering. För de flesta program tar man helt enkelt bort de få systemanrop som hanterar ljudenheten och byter ut dem mot lämpliga anrop till aRts.

Jag gjorde två anpassningar för att verifiera idén: mpg123 och quake. Du kan skaffa programfixarna härifrån. Bidra gärna med dina egna programfixar till underhållaren av aRts eller till programvarupaket för multimedia så att de kan integrera stöd för aRts i sin kod.

Att skicka ljud till ljudservern med gränssnittet är mycket enkelt:

Här är ett exempel på ett litet program som visar det här:

#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 fel: %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 fel: %s\n", arts_error_text(errorcode));
            return 1;
        }
    }

    arts_close_stream(stream);
    arts_free();

    return 0;
}

För att lätt kunna kompilera och länka program med aRts C-gränssnitt, finns verktyget artsc-config som känner till vilka bibliotek som man måste länka med och var deklarationsfilerna finns. Det anropas med

artsc-config --libs

för att ta reda på biblioteken och

artsc-config --cflags

för att ta reda på ytterligare C-kompilatorväljare. Exemplet ovan skulle ha kunnat kompileras med kommandoraden:

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

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

[ATT GÖRA: skapa dokumentation för artsc.h med kdoc]