Bug 178930

Hello,
when i try to start aRts by an application (like xine with aRts-output), aRts starts in multiple instances. 
The Problem seems to depend to the "arts-start-on-demand" Patch, because when i remove the Patch before rebuilding aRts, i can start arts with no Problem.
I already explained the Problem to the Author of aRts, and i would like to let you know the answer.

Michael

---------------------------------------------------------------------------
   Hi!

Ich schreib' Dir erstmal eine schnelle Antwort. Wenn Du mehr wissen
willst, frag' mich nochmal nach Details.

Also

1. das in mcop/tmpglobalcomm.cc reinzuhacken ist eine schlechte Idee,
aus mehreren Gründen
  - es gibt noch X11GlobalComm (was man verwendet, wenn artsd nicht über
    /tmp sondern übers X11-Display zwischen den einzelnen Programmen
    Informationen austauscht, wo artsd läuft, und was er da macht

  - der richtige Ort wäre 

string ObjectManager::getGlobalReference(const string& name)
    
    Code sollte in etwa lauten:

    (a) prüfen ob das Objekt da ist
    (b) wenn nicht, es sich aber um ein bekanntes Objekt handelt:

        (das wären diese hier (aus artsd.cc kopiert)):

        result=om->addGlobalReference(server,"Arts_SoundServerV2")
            && om->addGlobalReference(server,"Arts_SoundServer")
            && om->addGlobalReference(server,"Arts_SimpleSoundServer")
            && om->addGlobalReference(server,"Arts_PlayObjectFactory")
            && om->addGlobalReference(audioManager,"Arts_AudioManager");


       (1) Startvorgang auslösen (also system("kcminit arts"))
       (2) warten, bis artsd gestartet ist (also etwa mit Timeout,
           und immer wieder prüfen ob artsd da ist)

           das ist *ganz wichtig*, weil kcminit arts sofort zurückkommt,
           aber artsd dann noch nicht notwendigerweise fertig
           initialisiert ist

    (c) Referenz auf den frisch gestarteten artsd zurückgeben (also
        nochmal das GlobalComm objekt fragen)

2. eine statische Variable verhindert nicht ausreichend gut, dass nicht
zweimal artsd gestartet werden kann; der Grund ist, dass es mehrere
Prozesse gibt, die auf artsd zugreifen können - wenn artsd jetzt nicht
da ist, wird in *jeder* Prozess artsd starten, und dann hat man halt
fünf Stück, wenn das fünf Prozesse waren

Hier kann auch das GlobalComm Objekt helfen: *vor* dem starten von artsd
eine art lock damit anlegen, *nach* dem starten von artsd den lock
wieder wegmachen - allerdings ist das Problem dabei, dass der lock
liegenbleiben könnte, und dann würde niemand mehr versuchen artsd zu
starten

Zuverlässigen Code, der sowas macht, gibt es in artsd.cc, der kümmert
sich ja darum, daß im GlobalComm Objekt die Referenzen dann gelöscht
werden, wenn artsd nicht mehr läuft, aber die entsprechenden Einträge
trotzdem noch da sind. Das funktioniert darüber, daß tatsächlich
versucht wird eine Verbindung zu artsd aufzubauen.


3. wenn man sowas macht, dann will man vielleicht einen generischen Weg
implementieren, der nicht irgendwas hardcoded; aber dann wird es noch
komplizierter, weil alles was wir bisher als fest annehmen
(beispielsweise welches Programm man aufrufen muss, damit artsd
gestartet wird, und welche Objekte er dann registriert) dann Variablen
sind; also selbst wenn alles in (1) und (2) entsprechend geändert wird,
würde ich nicht empfehlen, daß KDE das Feature backfolded und mit neuen
aRts Versionen mitreleast.


Zusammenfassend: der Patch kann so nicht gehen, und es ist nicht einfach
einen zu schreiben, der tut.

   Cu... Stefan

On Thu, May 25, 2006 at 12:15:14PM +0200, Michael Schueller wrote:
> Hallo Stefan,
> bitte erlaube mir mich an Dich zu wenden.
> Da Du der Author von arts bist, und ich hier mit arts ein kleines 
> Problem hab, dachte ich Du wärst der Richtige Ansprechpartner.
> 
> Es geht in meinem Problem um den "arts-start-on-demand" Patch, der , 
> soweit ich weiß, seit SuSE 10.0 verbaut wird.
> Es scheint so als ob dieser Patch dazu führt das arts, wenn er 
> gestartet wird, nicht nur einmal sondern 3-6 mal gestartet wird.
> 
> Im ~/.xsession-errors ist dazu folgendes notiert
> --------------------------------------------------------------------------------
> There are already artsd objects registered, looking if they are 
> active...
> server status: running, autosuspend disabled
> real-time status: real-time
> server buffer time: 31.9728 ms
> buffer size multiplier: 1
> minimum stream buffer time: 31.9728 ms
> auto suspend time: 0 s
> audio method: alsa
> sampling rate: 44100
> channels: 2
> sample size: 16 bits
> duplex: half
> device: default
> fragments: 6
> fragment size: 940
> warning: leaving MCOP Dispatcher and still 9 object references 
> alive.
>   - Arts::SampleStorage
>   - Arts::Synth_MULTI_ADD
>   - Arts::Synth_MULTI_ADD
>   - Arts::Synth_PLAY
>   - Arts::StereoVolumeControl
>   - Arts::StereoEffectStack
>   - Arts::Synth_BUS_DOWNLINK
>   - Arts::SoundServerV2
>   - Arts::MidiManager
> warning: leaving MCOP Dispatcher and still 75 types alive.
> sound server terminated
> ... cleaned 5 unused mcop global references.
> 
> There are already artsd objects registered, looking if they are 
> active...
> There are already artsd objects registered, looking if they are 
> active...
> 
> Error: Can't add object reference (probably artsd is already 
> running).
>        If you are sure it is not already running, remove the 
> relevant files:
> 
>        /tmp/ksocket-marvin/Arts_SoundServerV2
>        /tmp/ksocket-marvin/Arts_SoundServer
>        /tmp/ksocket-marvin/Arts_SimpleSoundServer
>        /tmp/ksocket-marvin/Arts_PlayObjectFactory
>        /tmp/ksocket-marvin/Arts_AudioManager
> 
> starting artsd!
> There are already artsd objects registered, looking if they are 
> active...
> 
> Error: Can't add object reference (probably artsd is already 
> running).
>        If you are sure it is not already running, remove the 
> relevant files:
> --------------------------------------------------------------------------------
> 
> ...und so geht das dann immer weiter.
> Beobachte ich den Vorgang mit top, sehe ich wie bis zu 6 Instanzen 
> um die Vorherschaft kämpfen und dabei bis zu 40% CPU vereinnahmen.
> Der Vorgang hält ca 5 min an, bis dann nur noch eine Instanz übrig 
> ist.
> 
> Nun hab ich versucht den Patch wegzulassen.
> Das Ergebniss ist eindeutig. Arts wird nunmehr nicht mehr durch eine 
> Anwendung gestartet, aber wenn ich im Kontrollzentrum den Sound 
> prüfe, wird arts in wenigen sekunden gestartet, und auch nur 
> einmal.
> 
> Da ich nun also den Eindruck habe das mit dem Patch was nicht 
> stimmt, wollte ich Dich bitten mal einen Blick darauf zu werfen.
> Ich denke das hier irgendwas mit dem Aufruf von aRts nicht stimmt.
> 
> Vielen Dank
> Michael Schüller
> 
> Index: mcop/tmpglobalcomm.cc
> ================================================================================
> --- mcop/tmpglobalcomm.cc
> +++ mcop/tmpglobalcomm.cc
> @@ -54,8 +54,17 @@
>       {
>               string result = "";
>               string filename = MCOPUtils::createFilePath(variable);
> +             static bool started_arts = false;
>  
>               int fd = open(filename.c_str(),O_RDONLY);
> +             if (fd == -1 && !started_arts) 
> +             {
> +                       fprintf(stderr, "starting artsd!\n");
> +                       system("kcminit arts");
> +                       fd = open(filename.c_str(),O_RDONLY);
> +                    started_arts = true;
> +             }
> +
>               if(fd != -1)
>               {
>                       char buffer[8192];
> 

-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan