Mini-Orgel mit "Raspberry Pi"

  • Ich habe einen der ersten und bisher leider keinen wirklichen Verwendungszweck dafür gefunden,
    daher bin ich auch gespannt.
    Für alle Mitleser: Der RasPi ist einer der ersten seiner Art, es gibt aber mittlerweile ähnliche Projekte die vergleichbares mit mehr CPU-Power und RAM bieten.

    Gruß,
    Michael

    • Offizieller Beitrag

    @alle:

    Zitat

    Original geschrieben von martin

    Ist der Download korrekt:

    Der Download war tatsächlich nicht korrekt. Bei 3-maligem Versuch hatte ich jedes mal eine andere Prüfsumme :/
    Das war, als ich die Dateien vom oben von martin angegeben Link geladen habe. Der Download vom folgenden Link hat dann aber auf Anhieb mit der richtigen Prüfsumme funktioniert:

    http://download.opensuse.org/repositories/h…gue/Debian_7.0/


    Resultant 64:
    Aber gibt es auch welche, die bei gleicher Größe deutlich mehr Leistung bringen und trotzdem nicht, oder nur unwesentlich mehr kosten? Auch die Höhe der Stromaufnahme ist zu berücksichtigen und nicht zuletzt auch das Angebot an verfügbaren Betriebssystemen und weiterer Software zu allen erdenklichen Anwendungsfällen. Ich glaube dann wird die Auswahl an Alternativen sehr schrumpfen.

    Wie es aussieht, wird GO mit einem älteren RPi mit nur 256 MB RAM nicht laufen können. Denn mit Raspbian und GrandOrgue geladen, bleiben mir jetzt von 512 MB RAM nur noch 247 MB übrig um Samplesets zu laden.


    martin:
    Wie du aus dem letzten Satz entnehmen kannst, hat es mit dem Build heute Nacht tatsächlich noch funktioniert. Das Bauen von GrandOrgue hat dann auf dem Zwerg ca. 220 Minuten gedauert.

    Die entstandene .deb Datei habe ich dann folgendermassen installiert:

    dpkg -i grandorgue_0.3.1.1592_armhf.deb

    Ist das das gesamte Paket oder hätte ich noch eine weitere .deb Datei zusätzlich installieren müssen?

    GrandOrgue lässt sich jetzt einwandfrei starten und lädt das Sampleset der Burea-Gravkapell von Lars Palo trotz mehrerer Register erstaunlich flott.
    Will ich aber einen Ton spielen, dann verabschiedet sich GO sofort kommentarlos. Ich habe schon die 3 verschiedenen Audiotreiber durch, bei allen möglichen Einstellungen - immer das Selbe.

    Vielleicht habe ich doch was übersehen? Oder ist der Prozessor doch vollkommen ungeeignet?
    Möglicherweise gibt der Performance-Test im Anhang einen Hinweis.

  • Das GO-demo deb enthält nur das Demo-Set. Ob du es brauchst, ist deine Sache..

    Sieht nicht gut aus :( Sowohl Perftest als GO sind abgestürzt.

    Kannst du mal
    cat /proc/cpu/alignment
    machen.
    Es sollte gelten, das "(Ergebnis Bit-AND 2) == 2". Ansonsten schreib 2 hinein:
    echo 2 > /proc/cpu/alignment

    Wenn es dann noch nicht geht, bitte

    Code
    sudo apt-get install gdb
    gdb /usr/bin/GrandOrgue
    run
    <Jetzt bring GO zum Abstürzen>
    info threads
    bt


    und poste den Output.

    PS: Wenn GO mit den Parameter geht, bin ich noch am Output von "make test" interessiert.

  • Ich glaube, ich haben einen Schuldigen gefunden: Der GCC 4.6 von Rasbian. Wahrscheinlich ist GCC 4.6 für ARM betroffen.

    Code
    if (m_Samplers.size())
                    m_AvailableSamplers.exchange(m_Samplers[0]);
            else
                    m_AvailableSamplers.exchange(NULL);


    "optimiert" er zu

    Code
    m_AvailableSamplers.exchange((GO_SAMPLER*)&m_AvailableSamplers);

    Ich würde es einfach mit GCC 4.7 probieren:

    In debian/control:

    Code
    Build-Depends: debhelper (>= 7), cdbs, cmake, gettext, po4a, libjack-jackd2-dev, libasound2-dev, libwxgtk2.8-dev, docbook-xsl, xsltproc, zip


    zu

    Code
    Build-Depends: debhelper (>= 7), cdbs, cmake, gettext, po4a, libjack-jackd2-dev, libasound2-dev, libwxgtk2.8-dev, docbook-xsl, xsltproc, zip, g++-4.7

    In debian/rules:

    Code
    include /usr/share/cdbs/1/rules/utils.mk


    zu

    Code
    include /usr/share/cdbs/1/rules/utils.mk
    CXX=g++-4.7


    PS: Hint an den Admin: Wenn die [ code ]-Tags noch Rahmen hätten, würde man es noch viel schöner sehen.

    • Offizieller Beitrag

    Die Nachforschung hat aber nicht sehr lange gedauert ;)

    OK - es gibt wieder "heiße Himbeere" - der RasPi baut gerade wieder ein neues GrandOrgue :)

    Allerdings waren die Änderungen als Newbie nicht ganz so einfach:

    - Das Debian-Verzeichnis musste ich erst mal finden - es versteckt sich unterhalb des grandorgue_xxxx Verzeichnis aus dem ersten Build.

    - Der Compiler in der Version 4.7 war noch nicht installiert - das habe ich dann so hinbekommen:

    apt-get install gcc-4.7
    apt-get install g++-4.7

    - Der Compiler (bzw. kam das wohl eher vom make-file?) hat kurz nach Start gemeckert, dass schon ein älterer Build besteht - das kann man mit dem Parameter -d übergehen, dann werden zuerst die alten Files gelöscht.

    dpkg-buildpackage -rfakeroot -d

  • Ich habe mich beim durchlesen deines letzten Beitrags schon etwas gewundert.
    dpkg-buildpackage räumt bei korrekten Packeten automatisch auf.

    -d macht etwas ganz anderes:

    Zitat


    -d Do not check build dependencies and conflicts.

    Sieht eher danach aus, wie wenn du g++-4.7 nicht korrekt in debian/control eingetragen hättest.

    dpkg-buildpackage legt am Anfang ein grandorgue_0.3.1......diff.gz File auf der Ebene an, wo auch das grandorgue-0.3... Directory liegt. Da sieht man einfach, was du geändert hast.

    • Offizieller Beitrag

    Die beiden Dateien hatte ich genau so geändert wie angegeben. Beim Parameter -d huschen zuerst ein paar Meldungen mit "delete xxx" über den Bildschirm, sodass ich annahm er löscht damit die schon vorhandenen Dateien.

    Auf jeden Fall ist der Zwerg nun fertig und hat das neue GrandOrgue deutlich schneller zusammengebastelt als beim ersten mal.

    Ich darf berichten:

    GrandOrgue läuft auf Raspberry Pi

    :love:

    Vom Sampleset Burea Gravkapell kann man alle 5 Register benutzen. Wie es aber mit Polyphonie aussieht muss ich erst noch mit einem größeren Keyboard ausprobieren. Mein Akai LPK-25, das im Moment zum Test dranhängt hat ja nur 2 Oktaven. Aber ich denke mit den 5 Registern wird die Polyphoniegrenze hier schon erreicht sein. Das optimale Sampleset für den Zwerg muss ich erst noch suchen und anpassen.

  • Auf meinen virtuellen Rasbian habe ich es geschafft, mit gcc 4.7 GO zu übersetzten. Der Compiler ist ein paar Mal mit Internal-Compiler-Errors abgestürtzt - beim nächsten Versuch hat er es geschafft.

    perftest läuft auf meinen virtuellen ARM - bei 16 Bit unkomprimiert komme ich auf Polyphonie-Limit von 53.

    GO nutzt atomare Operation (zB Addition) zur Vermeidung von Locking - am ARM wird das nur simuliert => Atom & Co sind derzeit sicher besser geeignet für GO als ARM.

    PS:
    "make test" gibt eine Leistungsschätzung.

    • Offizieller Beitrag
    Zitat

    Original geschrieben von martin

    Auf meinen virtuellen Rasbian habe ich es geschafft, mit gcc 4.7 GO zu übersetzten. Der Compiler ist ein paar Mal mit Internal-Compiler-Errors abgestürtzt - beim nächsten Versuch hat er es geschafft.

    Wie lange hat das Compilieren da gedauert? Müsste doch sicher deutlich schneller laufen - oder schluckt die Emulation den CPU-Vorteil wieder auf?

    Zitat

    perftest läuft auf meinen virtuellen ARM - bei 16 Bit unkomprimiert komme ich auf Polyphonie-Limit von 53.

    Jau - eine Rakete ist es nicht :D

    Zitat

    GO nutzt atomare Operation (zB Addition) zur Vermeidung von Locking - am ARM wird das nur simuliert => Atom & Co sind derzeit sicher besser geeignet für GO als ARM.

    Auf meinem Netbook mit Atom läuft GO schon lange prima. Aber das lässt sich schlecht in ein Keyboard einpflanzen. Ich habe auch ein Mini-ITX Mainboard mit Atom CPU, aber mit passendem Netzteil ist das trotzdem schon wieder zu unhandlich. Und auf einem Board in Scheckkartenformat hab ich noch keine Atom CPU gesehen.

    Zitat

    Original geschrieben von Resultant 64

    Was Alternativen zum RasPi betrifft dachte ich z.B. an das Odroid u3.

    Oh ja - das sieht wirklich sehr vielversprechend aus. Ist aber wohl noch etwas schwierig an eines heranzukommen. Rechnet man Versandkosten, Steuern und Einfuhrzoll dazu, dann kostet es wohl auch 2 bis 3 mal soviel wie ein RPi.
    Ich denke die nächste Zeit wird sich in dem Bereich sicher noch einiges tun. Im Massenmarkt der Smartphones & Co. tauchen ja ständig neue, winzige CPUs mit immer höheren Recheneistungen auf.

    • Offizieller Beitrag

    Hier nun die lauffähige Version von GrandOrgue für Raspberry Pi

    Um die Datei herunterladen zu können muss man den Benutzerstatus "Mitglied" der MPS-Orgelseite haben. Das heißt, man muss insgesamt mindestens drei Beiträge im Forum gepostet haben - eigentlich nicht schwer - oder?

  • Die freie CPU-Zeit während des Tests reicht höchstens für einen Polyphonie von 52 - 113.
    44.1kHz, 16 Bit ohne Lossless-Compression, Linear hat den besten Wert geliefert.

    Zitat

    .
    22:48:00: Error: 300 sampler, 9,999093 seconds, 8 bits, 44100, Y, Linear, 128 block: 27770 ms cpu time, limit: 108,020451


    300 sampler, 9.999 sec: Rechenumfang [fix]
    Sample-Größe: 8 Bit
    44.1 kHz
    Y/N: Lossless Ja/Nein
    Linear/Polyphase Interpolation
    128 Samples Per-Buffer
    27770 ms Rechenzeit
    =>
    108,020451 Samples schafft ein Kern des Prozessors in der Konfig maximal.

    Um Störungen auszugleichen, muss man das ein paar Mal laufen lassen. Das ist nur ein oberes Limit - im Echtbetrieb muss der Prozessor noch mehr machen, daher wird es eher weniger.

  • Jetzt gibt es einen neuen Raspberry PI 2 mit 4 Kernen und 1MB Arbeitsspeicher. Damit müsste auch die Polyphonie kräftig steigen. Die Ott-Orgel sollte damit durchaus lauffähig sein.

  • Hallo martin und Mikelectric,

    ich hab mir jetzt einen raspberry pi 2+ besorgt und will auch mal probieren, GrandOrgue drauf zum Laufen zu bekommen. Die Hinweise von martin waren sehr hilfreich - der raspberry übersetzt jetzt seit etwa einer Stunde die Quellen von GrandOrgue. Ich bediene ihn mommentan übers Netz per putty von einem Windows-Rechner aus. Bisher sind 56% der Übersetzung geschafft - ich glaub, ich geh jetzt schlafen und schaue morgen, wie weit er gekommen ist.

    Grüße aus Neufahrn bei Freising - Martin