OpenAL bringt mich zur Weißglut

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • OpenAL bringt mich zur Weißglut

    Hier ein kleines Beispiel. Es wird einfach ein Sample geladen und abgespielt. Das Problem dabei, es klingt nicht so wie es im original klingt.
    Das seltsame dabei, wenn ich das Ding gelooped spiele, klingt es wie es soll.

    Quellcode

    1. alSourcei( _source, AL_LOOPING, 1) ;
    2. alSourcePlay(_source);

    Ich dachte zuerst es liegt am Wav-Loader, der ist es aber nicht, hab es mit CoreAudio geladen und mit OpenAL abgespielt, gleiches Problem.
    Irgendwie ist es, als wenn OpenAL erst warm laufen muss.

    Jemand nen Tipp?

    Projekt

  • Ja der Buffer passt schon, es liegt auch nicht daran, wann oder wo das Sample abgespielt wird. Ich vermute eher mal dass es ein Latenz-Problem ist. Es lässt sich aber
    nicht eindeutig fest machen, da teilweise andere Sounds richtig abgespielt werden, wieder andere werden gar nicht abgespielt. Ich hab auch schon an der Sample-Rate rum gespielt.

    Bringt alles nix.
    Das gleiche Sample mit Core Audio wird einwandfrei wieder gegeben, es scheint wirklich an OpenAL zu liegen, bzw. an der Implementierung.
    Scheiße.... auf Core Audio hab ich gar keinen Bock :cursing:

  • Also mal unter die Kopfhörer und KickDrum0001.wav direkt abgespielt.
    Klingt deutlich anders beim zweiten abspielen.
    Direkt danach Hi Conga0001.wav abgespielt und wieder KickDrum0001.wav.

    Weiß ja nicht, was die Hardware da treibt, aber mit OpenAl hat das nichts zu tun.

  • 1. Klick auf KickDrum0001.wav Klangeindruck "X"
    2. Klick auf KickDrum0001.wav Klangeindruck "Y"
    Danach immer wie "Y", außer wenn ich ein anderes wav abspiele.
    Dann wieder "X".

    Entweder klingt ein und dieselbe wav-Datei stets gleich, oder mein System macht da was nicht richtig.

    Da ich den Test außerhalb einer App, fernab von Xcode gemacht habe, irritiert mich das gewaltig!

  • Also, das ist definitiv kein OpenAL Problem, das ist ein Bug im System, bei recht kurzen Sound >1 Sek. spielt selbst der Finder nur Müll oder gar nichts ab. Manchmal schafft er es dann doch.
    Längere Sounds funktionieren wieder einwandfrei.

    Schöner Scheiß, ist das nur beim Mountain Brüller so?

  • wolf_10de schrieb:

    Schöner Scheiß, ist das nur beim Mountain Brüller so?


    Anscheinend. Mit dem Schneeleoparden spielen die Samples im Finder problemlos - im OpenAL-Code ist es allerdings das gleiche Problem.

    Ich weiß nicht, was der Finder unter 10.8 so anstellt, aber CoreAudio kann sowas. Wenn Du präzise timen willst, geht da kein Weg vorbei.
    Multigrad - 360°-Produktfotografie für den Mac

  • mattik schrieb:

    Wenn Du präzise timen willst, geht da kein Weg vorbei.
    Das hab ich schon befürchtet, wenn das Framework endlich mal ordentlich gemacht wäre, wenn ich schon so was sehe:

    Quellcode

    1. printf("Playing...\n");
    2. do
    3. {
    4. CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.25, false);
    5. } while (!player.isDone /*|| gIsRunning*/);
    7. // isDone represents the state of the Audio File enqueuing. This does not mean the
    8. // Audio Queue is actually done playing yet. Since we have 3 half-second buffers in-flight
    9. // run for continue to run for a short additional time so they can be processed
    10. CFRunLoopRunInMode(kCFRunLoopDefaultMode, 2, false);
    12. // end playback
    13. player.isDone = true;
    14. CheckError(AudioQueueStop(queue, TRUE), "AudioQueueStop failed");
    Alles anzeigen

    krieg ich Schweißperlen auf der Stirn. Ich hab keine Ahnung für was die beiden RunLoops sein sollen.
    Arghhhh, echt he, was soll das denn sein. Low Level hin oder her, aber so was .....

    Aber stimmt schon mit Core Audio wird das Sample sauber abgespielt.

  • wolf_10de schrieb:

    Ich hab keine Ahnung für was die beiden RunLoops sein sollen.

    Die sollen zeigen, dass der Autor der Zeilen auch keine Ahnung hatte, was er tut :)

    In der Schleife wartet er, bis die Datei fertig abgespielt ist. Und dann wartet er nochmal ein bisschen, um sicher zu gehen, dass die Datei so wirklich richtig fertig ist. Die Runloop-Sache benutzt er als Sleep-Ersatz (verhindert den Beach Ball of Death, ist aber trotzdem Käse). Nicht jedes Beispiel von SO ist vorbildlich... ich habe hier sicher noch irgendwo ein einfacheres Beispiel rumfliegen, bei Interesse sag' Bescheid. Was willste eigentlich machen?
    Multigrad - 360°-Produktfotografie für den Mac

  • mattik schrieb:

    wolf_10de schrieb:

    Ich hab keine Ahnung für was die beiden RunLoops sein sollen.

    Die sollen zeigen, dass der Autor der Zeilen auch keine Ahnung hatte, was er tut :)

    In der Schleife wartet er, bis die Datei fertig abgespielt ist. Und dann wartet er nochmal ein bisschen, um sicher zu gehen, dass die Datei so wirklich richtig fertig ist. Die Runloop-Sache benutzt er als Sleep-Ersatz (verhindert den Beach Ball of Death, ist aber trotzdem Käse). Nicht jedes Beispiel von SO ist vorbildlich... ich habe hier sicher noch irgendwo ein einfacheres Beispiel rumfliegen, bei Interesse sag' Bescheid. Was willste eigentlich machen?
    Das ist bitter, wenn ich sehe, dass es ein Buch über CA ist. Sollte man eigentlich davon ausgehen, dass die Jungs wissen von was sie schreiben. Dachte mir schon das da was faul ist.
    In dem Beispiel wird irgendwo ein Puffer angelegt, für 2 Sekunden, egal wie lang der Sound ist, der da rein geladen werden soll, völlige Schrott sowas.

    Ich will mir nen kleinen Sequenzer bauen, 16 Spuren, kleines Gerät eben. Im Prinzip läuft das Ding auch schon super, bis auf das Manko, dass die Sounds nicht sauber abgespielt werden, was
    ja offensichtlich am System und nicht an OpenAL liegt.

    Also einfach 16 Puffer anlegen in jeden nen Sound laden und den mit nem Timer triggern. Nix großes eigentlich. Wenn alles sauber läuft, will ich das Ding noch bouncen, sprich den Loop
    rausspielen, aber so weit bin ich noch nicht.