Probleme bei der Initialisierungsreihenfolge von globalen Objekten

Anon-81275

Jo, Race Conditions ... https://share.google/aimode/8Ri2k2s1jHnqyTZLI

InternalHigh

Ein Rassenkonflikt

Anon-81275

Die Formulierung ist mir auch aufgestoßen er hat aber wohl einfach "Race Conditions" 1:1 übersetzt.. Hoffe, der Lösungsvorschlag ist dagegen richtig..

Anon-81275

Es gibt noch einen Klopper:
https://www.reddit.com/r/cursedchemistry/comments/1vhgo1m/a_tool_used_to_rephrase_plagiarised_text_changed/

D_Key

@InternalHigh sagte in Probleme bei der Initialisierungsreihenfolge von globalen Objekten:

Ein Rassenkonflikt

Läuft bei google....

@Anon-81275 sagte in Probleme bei der Initialisierungsreihenfolge von globalen Objekten:

Hoffe, der Lösungsvorschlag ist dagegen richtig..

Leider nein.
Wenn man das begin im Konstruktor heraus nimmt
übernimmt der Software timer die "responsibility".
if (update_scheduled == false)
{
update_setup();
float usec = 1e6 * AUDIO_BLOCK_SAMPLES / AUDIO_SAMPLE_RATE_EXACT;
s_audio_ticks = USec2TimerBusClock(usec);
s32 id = AllocTimerCounter();
SetTimerHandler(id, s_audio_ticks, tick_cb, &s_audio_ticks);
StartTimerCounter(id);
}
}

// When an object has taken responsibility for calling update_all()
// at each block interval (approx 2.9ms), this variable is set to
// true. Objects that are capable of calling update_all(), typically
// input and output based on interrupts, must check this variable in
// their constructors.
bool AudioStream::update_setup(void)
{
if (update_scheduled) return false;
bootIOP();
update_scheduled = true;
return true;
}
Das ist nur dann notwendig wenn man keine Hardware für Audio Nutzt.
z.B ein Sinus Ton mit einer FFT Verknüpft.
Sobald ein Hardware Gerät ins Spiel kommt übernimmt das die Taktung.
Das ist das Problem an KI, es kann den vollen Umfang der Audio Bibliothek nicht erfassen.
Das ganze soll aber Plug&Play laufen.

Man kann sich hier:
https://www.janbob.com/electron/OpenAudio_Design_Tool/index.html
Audio Verbindungen zusammen bauen.

Mittlerweile ist das Problem gefunden, nachdem ich Wochen nicht weiter gekommen bin.
Habe in der main Funktion die main Thread Priorität herab gesetzt:
int main(int argc, char **argv)
{
ChangeThreadPriority(GetThreadId(), 100);
AudioMemory(32);

Jetzt läuft es.
Ein bisschen bin ich verwundert warum es erst mit einer Priorität von 100 geht.
Ist aber auch egal Hauptsache Audio läuft.

Anon-81275

@D_Key sagte in Probleme bei der Initialisierungsreihenfolge von globalen Objekten:

Läuft bei google

Könnte auch etwas mit dem aktuellen Tagesgeschehen unserer Nachbarn aus Frankreich zu tun haben. Würde Google da jetzt keinen Strick draus drehen...

@D_Key sagte in Probleme bei der Initialisierungsreihenfolge von globalen Objekten:

Leider nein.
Wenn man das begin im Konstruktor heraus nimmt
übernimmt der Software timer die "responsibility".

Das kann ich wie gesagt nicht überprüfen... Ich besaß noch nie eine Playstation.

Anon-81275

AudioStream.h

class AudioStream {
    // ... dein bestehender Code ...
protected:
    static volatile bool is_audio_system_ready; 
};

AudioStream.cpp

// Am Anfang der Datei initialisieren
volatile bool AudioStream::is_audio_system_ready = false;

void software_isr(void* arg) {
    // 1. Warten, bis der Main-Thread komplett fertig ist
    while (!AudioStream::is_audio_system_ready) {
        EE_SYNC(); // Verhindert CPU-Optimierungen beim Schleifen-Check
    }

    while(1) {
        // 2. Erst jetzt ist die Semaphore garantiert gültig erstellt!
        WaitSema(AudioStream::audioSemaID);

        if (AudioStream::update_exceptions == 0) {
            AudioStream *p;
            for (p = AudioStream::first_update; p; p = p->next_update) {
                if (p->active) p->update();
            }
        }
        EE_SYNC();
    }
}

void AudioStream::initialize_memory(audio_block_t *data, unsigned int num) {
    // ... Deine bisherige Initialisierung (Speicher, Semaphore, Thread-Erstellung) ...

    s32 threadID = CreateThread(&threadParam);
    StartThread(threadID, NULL);

    // ... Timer-Setup ...
    s32 id = AllocTimerCounter();
    SetTimerHandler(id, s_audio_ticks, tick_cb, &s_audio_ticks);
    StartTimerCounter(id);

    // GANZ AM ENDE: Erst wenn alles (Sema, Thread, Timer) bereit ist, 
    // geben wir den Audio-Thread frei.
    EE_SYNC(); 
    is_audio_system_ready = true;
    EE_SYNC(); // Garantiert, dass die Flag im RAM landet, bevor dieser Thread etwas anderes tut
}

Das wäre vermutlich "sauberer", als die pauschale Thread-Priorität 100 zu setzen - da es dabei zu weiteren Problemen kommen könnte, wenn die main umfangreicher werden und somit länger brauchen sollte...

Assisted by: https://share.google/aimode/nfpRxkKSHe0v2wUcO

D_Key

@Anon-81275 sagte in Probleme bei der Initialisierungsreihenfolge von globalen Objekten:

Das kann ich wie gesagt nicht überprüfen... Ich besaß noch nie eine Playstation.

Das hat auch nichts mit der Playstaion gemein. Das ist das Konzept was hinter der Audio Bibliothek steht.
Und generell muss bei Audio irgend ein Gerät den Takt angeben Input und Output müssen synchron laufen.
Sonnst hast du Samplerate Abweichung zwischen input und output .

@Anon-81275 sagte in Probleme bei der Initialisierungsreihenfolge von globalen Objekten:

Das wäre vermutlich "sauberer", als die pauschale Thread-Priorität 100 zu setzen

Das habe ich mir auch schon überlegt.
Die niedrige Priorität kann später dafür sorgen das die Bildschirmausgabe flackert, weil der Main Thread lange angehalten wird.

Anon-81275

Und jetzt? Leider bin ich, was die Audio-Lib(s) betrifft, in der Bloom'schen Taxonomie (Stufen des Wissenerwerbs) auch nur irgendwo zwischen Stufe 0 (völlige Ahnungslosigkeit) und Stufe 1 (Kennen/Erinnern/Aufzählen). Also weit weg von dem Ideal, um anderen helfen zu können (auch, wenn ich mich mit den übergeordneten Nebenläufigkeitskonzepten ein wenig auskenne, aber das zählt (an für sich/allg.) nicht).

Quiche Lorraine

@D_Key sagte in Probleme bei der Initialisierungsreihenfolge von globalen Objekten:

Ich habe mal über deinen Code geschaut und jetzt soweit keinen kritischen Punkt entdeckt.

Der einzigste Punkt welcher etwas verdächtig aussieht, liegt in initialize_memory wo zuerst der Semaphore, danach der Thread und danach der Timer initialisiert wird. Ich frage mich, was passiert wenn der Thread etwas länger braucht und der Timer schon zuschlägt.

Es hilft nichts. Ich vermute du musst deinen Code um Ausgaben erweitern und mittels absichtlichen Delay den Fehler herausprovozieren.

if(audioSemaID == -1 ) wird nie true bzw false im dem Fall.

Was meinst du damit?

BTW: Und nenne doch bitte die Funktion software_isr um. Ich sehe da nämlich keine Interrupt Service Routine.

Anon-81275

Dieser Beitrag wurde gelöscht!

Anon-81275

@Quiche-Lorraine sagte in Probleme bei der Initialisierungsreihenfolge von globalen Objekten:

BTW: Und nenne doch bitte die Funktion software_isr um.

Vorschläge:

audio_worker_thread (klassischer Name für Hintergrund-Threads, die auf Signale warten)
audio_update_thread (zeigt sofort, dass es sich um einen separaten Thread/Task handelt)
audio_processing_loop (betont Endlosschleife, in der Audiodaten blockweise verarbeitet werden)