2012-06-01 24 views
5

Ich habe mit der Erzeugung von Klängen mit mathematischen Wellenfunktionen in C gespielt. Der nächste Schritt in meinem Projekt besteht darin, Benutzereingaben von einem MIDI-Keyboard-Controller zu erhalten, um die Wellen auf verschiedene zu modulieren Stellplätze.C Linux Geräteprogrammierung - Lesen direkt von/Dev

Meine erste Idee war, dass dies relativ einfach wäre und Linux als Linux mir erlauben würde, den Rohdatenstrom von meinem Gerät zu lesen, so wie ich es bei jeder anderen Datei tun würde.

Forschung rät jedoch überwältigend, dass ich einen Gerätetreiber für den MIDI-Controller schreibe. Die allgemeine Idee ist, dass der Kernel selbst dann, wenn die Gerätedatei vorhanden ist, nicht weiß, welche Systemaufrufe ausgeführt werden sollen, wenn meine Anwendung Funktionen wie read() und write() aufruft.

Trotz dieser Warnungen habe ich ein Experiment gemacht. Ich habe den MIDI-Controller angeschlossen und die Device-Datei "/ dev/midi1" kattiert. Ein steter Strom von Null-Zeichen erschien, und als ich eine Taste auf dem MIDI-Controller drückte, erschienen mehrere Bytes, die den erwarteten Message-Chunks entsprachen, die ein MIDI-Gerät ausgeben sollte. MIDI Protocol Info

Also meine Fragen sind:

Warum hat der cat'ed Strom auf diese Weise verhalten?

Bedeutet dies, dass bereits ein Plug-and-Play-Gerätetreiber auf meinem System installiert ist?

Sollte ich immer noch einen Gerätetreiber schreiben, oder kann ich es wie eine Datei lesen?

Vielen Dank im Voraus für das Teilen Ihrer Weisheit in diesen Bereichen.

+0

anstatt zu cat'ting, würde ich empfehlen, dass Sie() das Gerät von einem 'C' Programm lesen. Sie sagen, Sie sehen "gültige" Daten, warum nicht sicher herausfinden? Übrigens muss dort bereits ein Gerätetreiber vorhanden sein, sonst hätten Sie keine Gerätedatei und auch keinen Zugriff darauf. – KevinDTimm

Antwort

5

Warum verhält sich der Cat'ed Stream so?

Weil das vermutlich die rohen MIDI-Daten sind, die vom Controller empfangen werden. Die Null-Bytes sind wahrscheinlich eine Art Synchronisations-Tick.

Bedeutet dies, dass bereits ein Plug-and-Play-Gerätetreiber auf meinem System installiert ist?

Ja.

Allerdings rät Forschung überwiegend, dass ich einen Gerätetreiber für den MIDI-Controller schreibe. Die allgemeine Idee ist, dass der Kernel selbst dann, wenn die Gerätedatei vorhanden ist, nicht weiß, welche Systemaufrufe ausgeführt werden sollen, wenn meine Anwendung Funktionen wie read() und write() aufruft.

< ...>

Soll ich noch weiter gehen und einen Gerätetreiber schreiben, oder kann ich weg mit ihm wie eine Datei zu lesen?

Ich bin mir nicht sicher, was Sie lesen oder wie Sie zu dieser Schlussfolgerung kommen, aber es ist falsch. :) Sie haben bereits einen perfekten Treiber für Ihren MIDI-Controller installiert - gehen Sie vor und benutzen Sie ihn!

2

Sind Sie sicher, dass Sie NUL Bytes lesen? Und nicht 0xf8 Bytes? Weil 0xf8 der MIDI Tick-Status ist und normalerweise periodisch gesendet wird, um die Instrumente synchron zu halten.Versuchen Sie, das Gerät zu lesen od mit:

od -vtx1 /dev/midi1 

Wenn Sie eine Reihe von 0xF8 sehen, es ist okay. Wenn Sie die von Ihrem MIDI-Controller gesendeten Tempoinformationen nicht benötigen, deaktivieren Sie diese entweder auf Ihrem Controller oder ignorieren Sie diese 0xf8-Statusbytes. Bitte beachten Sie, dass bei MIDI der aktuelle MIDI-Status normalerweise einmal gesendet wird (), um die Bytes zu speichern. Danach folgen die Nutzdaten so lange wie nötig. Zum Beispiel ist der Tonhöhenbeugungsstatus das Byte 0xeK (wobei K die Kanalnummer ist, d. H. 0 bis 15) und seine Nutzlast 7 Bits des niedrigstwertigen Bytes gefolgt von 7 Bits der höchstwertigen Bytes ist. Also, vielleicht hast du einen komischen Controller und du siehst nur wiederholte Payloads von irgendeinem Status, aber jeder Controller, der nicht dumm ist, wird nicht wiederholen, was er nicht braucht.

Jetzt für den Treiber: werfen Sie einen Blick auf dmesg, wenn Sie Ihren MIDI-Controller anschließen. Wenn jetzt Ihr OSS /dev/midi1 erscheint, wenn Sie Ihr Gerät anschließen (udev macht diesen Job), und dmesg keinen Fehler schießt, brauchen Sie nichts anderes. Das MIDI-Protokoll ist noch ein anderes serielles Protokoll, das eine feste Baudrate hat und Bytes sendet/empfängt. Es gibt nichts Kompliziertes daran ... einfach vom Gerät lesen oder auf das Gerät schreiben und fertig.

Das einzige Problem ist, dass Warteschlangen an einer bestimmten Stelle zu einer schlechten Audio-Latenz führen können (wenn Sie die MIDI-Befehle zur Steuerung von Live-Audio verwenden, was ich glaube, was Sie tun). Es scheint, als ob diese Geräte hauptsächlich für System-exklusive Nachrichten erstellt wurden, das heißt, zum Beispiel einige Patches/Presets für einen Synthesizer online herunterzuladen und sie mit MIDI auf das Gerät zu laden. Latenz spielt in dieser Situation keine Rolle.

Schauen Sie sich auch die ALSA way des Spiels mit MIDI unter Linux an.

1

Wenn Sie keine neue MIDI-Controller-Hardware entwickeln, sollten Sie sich keine Gedanken darüber machen, einen Treiber dafür zu schreiben. Es ist das Anliegen des Benutzers, seine Hardware zu installieren, und die Verpflichtung des Anbieters, die Treiber zu liefern.

Unter Linux lesen Sie nur die Datei. Jetzt interpretieren und nützliche Dinge mit den Daten machen.