Liebe Community, gleich vorweg, ich beginne erst, mich mit Microcontrollern zu beschäftigen und bin daher für alle Vorschläge und Plattformen offen. Vereinfacht gesagt möchte ich ein USB-Interface bauen, über eine Desktopanwendung steuerbar, das Musik abspielen kann. Soweit keine Aufgabe, die nicht am Rechner selbst erledigt werden kann oder für die es nicht schon tausende Player und Audio-Interfaces gibt. Da ich jedoch zu dieser Musik zeitsynchron(!) Hardware ansteuern möchte ist es mit dieser Desktop-Anwendung nicht getan. Ich habe mich jetzt einige Wochen mit dem Raspberry PI rumgequält und schaffe es dort auch relativ synchron Musik abzuspielen und die IO-Pins anzusteuern, jedoch bin ich eher auf der Suche nach einer, naja, ordentlichen Lösung :D (... da ich nicht mit dem PI selbst arbeiten will, ich brauche kein Betriebssystem) Da bin ich nun also nach einem Tipp eines Kollegen beim Arduino gelandet, und die Möglichkeit das ganze über USB in C zu programmieren (ganz ohne Schnickschnack) sagt mir auch sehr zu. Ich bin mir aber auch sicher, dass das ganze für mich keine Zukunft hat, wenn die Audioqualität nicht stimmt. Jetzt also zur ganz allgemeinen Frage, bei der mir Google als "Neuling" nicht wirklich geholfen hat. Gibt es eine Möglichkeit über eine uC-Plattform, sei es nun Arduino, Teenzy und was es alles gibt, eine digitale Audioausgabe (optimalerweise SPDIF über Koax oder optisch) zu realisieren. Und mit realisieren meine ich 'irgendwie, aber mit vertretbarem Aufwand'. Das Signal muss nicht zwangsläufig auf dem uC selbst erzeugt werden, ich fahre sehr gut damit auf externe Module zurückzugreifen, die das für mich übernehmen und eine C-Library auf dem uC fürs Versenden der nötigen Daten an das externe System zu haben. Wie schon erwähnt bin ich für alle Plattformen offen, es sollten aber "echte" uC-Plattformen sein und nicht so etwas wie der RPi, da ich mich nicht um die Macken eines Betriebssystems kümmern möchte, das ich nicht brauche. Ich hoffe der Sinn der Frage wird ersichtlich und vielleicht hat ja sogar jemand schon eine passende Lösung im Ärmel. Vielen Dank im Voraus :)
>Vereinfacht gesagt möchte ich ein USB-Interface bauen >über eine Desktopanwendung steuerbar, das Musik abspielen kann. Das ist aber jetzt nun wirklich gar nichts für einen Anfänger.
holger schrieb: >>Vereinfacht gesagt möchte ich ein USB-Interface bauen >>über eine Desktopanwendung steuerbar, das Musik abspielen kann. > > Das ist aber jetzt nun wirklich gar nichts für einen Anfänger. Anfänger bezieht sich auch nur auf Microcontroller. Elektronik- und Programmiererfahrung ist vorhanden und ich bin gerne bereit mich ins Abenteuer zu stürzen ;)
Nunja...Ich würde in der Tat holger zustimmen. Allerdings wo ein Wille ist... Vorschlag: Du nimmst eine fertige Platine. Würde dir z.B. gleich die vorschlagen: http://de.rs-online.com/web/p/products/8820278/ Diese ist sehr gut, hat ein Audio-IC drauf, sehr gutes Display, Rechenresourcen, Speicherresourcen, alles, was das Herz begehrt. Und dann steigst du langsam in die Programmierung ein. Ich sage nicht, dass es einfach wird. Aber lohnen wird es sich allemal, wenn du selbstständig einen Einstieg in diese Platine hinkriegst. Also meine Meinung - mit etwas Mut und recht viel Geduld und selbstständige Forschungsarbeiten an der Platine kannst du Vieles erreichen.
Ist das nicht eher was für eine Midi Schnittstelle, statt USB? Wo kommt die Musik denn her, die abgespielt werden soll? Soll der µC die Musik erzeugen oder soll er ein Gerät steuern, dass die Musik macht? Oder geht es darum, eine aufgezeichnete Audio Datei (MP3 oder so) abzuspielen? Oder soll das Ding wie eine USB Soundkarte funktionieren, also einen PCM Stream abspielen, die der PC an das Gerät sendet.
ProjektX schrieb: > Vorschlag: Du nimmst eine fertige Platine. Würde dir z.B. gleich die > vorschlagen: http://de.rs-online.com/web/p/products/8820278/ Danke schonmal, ich gehe mal davon aus, dass ich dieses ARM-Board auch über USB in einer IDE programmiere? :) Stefan U. schrieb: > Wo kommt die Musik denn her, die abgespielt werden soll? Die Musik soll als 16-bit Wave (normale CD-Qualität) vom PC kommen. Dass ich sie mit dem uC abspielen will hängt mit der Idee zusammen, die Latenz zwischen Beginn Audio und Beginn Hardwaresteuerung zu minimieren. Mehr als 10ms sollten das auf keinen Fall sein und wenn ich die Musik über eine Library auf dem PC abspiele verliere ich glaube ich die Kontrolle über den Startzeitpunkt der Musik. Also auch kein PCM-Stream vom PC, da ich nicht weiß mit welche Latenz der losgeschickt wird. Ich hoffe es wird jetzt klar, warum ich das Playback der Musik möglichst nah an der HW-Steuerung halten möchte :) Wiegesagt, ich studiere Elektrotechnik (jaja, die Theoretiker), programmiere in meiner Freizeit hauptsächlich Software in C# (aber eben nur high-level) und habe auch schon mit (nicht-programmierbarer) Elektronik gebastelt, daher sind die Grundlagen vorhanden, was mir im "Portfolio" fehlt ist die Software AUF Hardware, aber da bin ich bereit zu lernen :)
Eine "Audio auf HW"-Lösung wäre mir auch alleine deswegen sehr lieb, um später auch unabhängig vom PC meine Musik abspielen zu können und den PC nur noch zum Bespielen zu nutzen.
> Danke schonmal, ich gehe mal davon aus, dass ich dieses ARM-Board auch > über USB in einer IDE programmiere? :) Ich gehe davon aus, dass am rechten Rand des geposteten Links alle Informationen, sowie das Datenblatt zum MCU und dem Board selbst vorliegen :) Aber ja, programmieren kannst du das Ding auch über USB. Musst dir jetzt "nur noch" die Programmierung aneignen. Ich zieh mich mal zurück, Stefan Us wird dich schon gut beraten :)
Die kleinen 8bit Controller sind sicher nicht geeignet. Mir ist noch nicht klarum, warum du eine eigene Soundkarte neu erfinden willst. Einen Treiber für Windows müsstest du dann auch noch schreiben. Liegt es micht näher, ein simples Schaltinterface mit einer handelsüblichen Soundkarte zu kombinieren?
Stefan U. schrieb: > Die kleinen 8bit Controller sind sicher nicht geeignet. Mir ist noch > nicht klarum, warum du eine eigene Soundkarte neu erfinden willst. Einen > Treiber für Windows müsstest du dann auch noch schreiben. Ich weiss zwar auch nicht wie genau die Synchronisation denn sein soll, aber grundsätzlich hat man bei Windows ja kaum eine Kontrolle über die Latenzen. Dort schiebt man afaik im besten Fall einen Buffer von PCM-Samples an die API, aber wann die Töne tatsächlich aus dem Lautsprecher kommen kann man nur abschätzen. Da ist man mit einem Eigenbau auf jeden Fall besser dran. Und wenn es nur ein PCM-Player@48kHz werden soll wäre das auch für einen 8-Bitter keine so große Sache. Dazu kommt freilich, daß das Gerät in Zukunft möglicherweise standalone betrieben werden soll, also ohne PC. Eine Frage, die sich mir gerade allerdings noch stellt, ist ob die Synchronisation (zwischen Musik und der Ansteuerung sonstiger HW) allein anhand der Zeit erfolgen soll? Oder kommt da noch eine Fourieranalyse o.ä. ins Spiel?
Wie zeitsynchron muss es denn sein? Mit einem normalen Windows solltest du relativ problemlos im einstelligen ms-Bereich bleiben können, notfalls mit ASIO-Treibern (http://www.asio4all.com/) und passender Software (und wenn der Rechner nicht unter Last ächzt).
Genau diese nicht abschätzbaren Latenzen sind das Problem, wenn sie wenigstens immer gleich wären, dann würde ich mich auch erstmal damit begnügen. Besucher schrieb: > Eine Frage, die sich mir gerade allerdings noch stellt, ist ob die > Synchronisation (zwischen Musik und der Ansteuerung sonstiger HW) allein > anhand der Zeit erfolgen soll? Oder kommt da noch eine Fourieranalyse > o.ä. ins Spiel? Ich beschreibe kurz was ich habe und warum ich auf einen uC will .. Bisher ist es auf dem RPi in python auf die primitivste Variante reduziert: Die Musik wird schonmal vorgebuffert und in einem ausgelagerten Thread mithilfe der pyalsaaudio-Library, die auf der hardwarenahen und recht flotten alsa-C-Library basiert, abgespielt. Sobald dieser Thread startet wird ein timer (python-time-Library) gestartet und nun immer nach einem bestimmten Zeitintervall Aktionen ausgeführt, sprich GPIOs angesteuert. Das ganze im Takt, dazu wird das Zeitintervall als Bruchteil eines Taktes vorberechnet (wie bei MIDI). Das funktioniert mit einem GPIO auch so wie geplant und läuft synchron, nur wird sich das mit mehr GPIOs, Befehlen und Abfragen etc. pro Zeitintervall wohl ändern, daher will ich weg von der high-level-python Programmierung und auch weg vom PI, da ich mehr als Musik und IO-Steuerung nicht brauche und es gleich richtig machen will! :) Die Lösung mit dem Timer im Endless-Loop würde ich so dann auch erstmal auf dem uC übernehmen, sie ist natürlich nicht optimal (BPM muss genau bestimmt sein, man kann nicht pausieren und springen) aber das kommt später, erstmal wäre es wichtig überhaupt ein Audiooutput zu haben, und das auch mit der Möglichkeit der digitalen Ausgabe oder zumindest einer sehr hochwertigen Analogen .. Wenn ich aber 24bit/96kHz an einen DAC schicken kann, dann wird es auch eine Lösung geben das ganze als SPDIF da raus zu kriegen :P
Du könntest zB einen dsPIC33EP512MU810 verwenden. Der hat USB Device und Host Interface, und der hat I2S und AC97, d.h. Du kannst einen passenden Codec oder einen SPDIF-Transmitter anschließen. Die Audiodaten kannst Du zB auf einem SPI-NOR-Flash oder SPI-NAND-Flash oder einer SD-Karte ablegen. Mit 70 MHz effektivem Prozessortakt und 52k internem RAM solltest Du genug Leistung haben. fchk
S. R. schrieb: > Wie zeitsynchron muss es denn sein? Mit einem normalen Windows solltest > du relativ problemlos im einstelligen ms-Bereich bleiben können, > notfalls mit ASIO-Treibern (http://www.asio4all.com/) und passender > Software (und wenn der Rechner nicht unter Last ächzt). Wäre als Zwischenlösung (ohne die Möglichkeit den PC irgendwann wegzulassen) auch erstmal okay für mich, ich bin avon Latenzen im niedrigen dreistelligen ms-Bereich ausgegangen, das wirft schon ein anderes Licht auf die Sache .. Ich denke um die 4-6ms sind für mich okay und keinesfalls wahrnehmbar .. wenn es 8 sind wird die Hardware sicher auch ihre 2ms Verzögerung über USB haben je nach Programmierung (steinigt mich bitte nicht wenn es doch viel schneller ist :D), dann passt es wieder. Grüße
Vor allem hast du keine Feedbackschleife, also darfst du die realen Latenzen auch gerne ausmessen und deine Steuerung nachkorrigieren. Der Windows-Audiostack ist nicht bei WfW 3.11 stehen geblieben. ;-) Ansonsten wäre es vermutlich auch sinnvoll, direkt C mit ALSA oder Pulseaudio (das ist dafür mal gemacht worden) auf dem RPi zu machen. Damit kommst du auch auf deine Latenzanforderungen und wirklich anders als ein Mikrocontroller ist das auch nicht.
:
Bearbeitet durch User
In welcher Form sind denn die I/O-Aktionen überhaupt mit den Audiodaten verknüpft? Ist es ein spezielles Dateiformat? Mit WAV geht sowas ja nicht ohne Weiteres. Im Übrigen schaffen Videoplayer Bild und Ton beieinander zu halten. Auch unter Windows. Vielleicht lohnt sich ein Blick in die Sourcen von xine, mplayer und Co. ... Audioausgabe mit dem µC auf bis zu 12 Kanälen mache ich derzeit mit dem PIC32MZ. Der hat mit 200 bzw. 250MHz auch ordentlich Dampf. Gruß Jobst
Hennes schrieb: > Ich denke um die 4-6ms sind für mich okay und keinesfalls wahrnehmbar .. Ich weiß nicht, was genau du planst, aber evtl. musst du auch bedenken, dass du bei 5m Abstand zum Lautsprecher schon ca. 15ms Latenz (zusätzlich) hast.
Klops schrieb: > Hennes schrieb: >> Ich denke um die 4-6ms sind für mich okay und keinesfalls wahrnehmbar Meine Messungen ergaben IIRC eher so 50ms Latenz. Hatte allerdings kein Windows Core Audio in Verwendung.
> hat man bei Windows ja kaum eine Kontrolle über die Latenzen
Wenn das so wäre, dann könnte man Windows weder zur Produktion von
Popmusik benutzen, noch zum Abspielen von ganz gewöhnlichen Videoclips.
Ich bin ziemlich sicher, dass Anwendungsprogramme die Verzögerung der
Audio-Wiedergabe ermitteln können. Das ist ganz sicher kein
Zufallsprodukt.
>@ Hennes (Gast)
Ist bei dir der Weg das Ziel um was zu lernen, oder willst du primär
dein Ziel erreichen?
Wenn du primär dein Ziel erreichen willst, kannst du eine DMX512
Freeware hernehmen wie z.B. DMX Control und einen USB<>DMX512 Adapter.
Dann kannst du auf Basis von 8Bittern und einem RS485 Baustein deine
Slaves selbst bauen.
Um ehrlich zu sein, frage ich mich immer, wie in solchen PC Programmen
ein Ablauf wie der der Lichtsteuerung zu einem anderen wie der Musik
synchron gehalten wird, wenn das darunter liegende OS nicht echtzeitfähg
ist. Nur so in den Raum geworfen...
Hallo, ich denke die Synchronisation kann man auch mit einem 8bitter hin bekommen. Kommt drauf an, wo die Daten durch müssen. Vorschlag: Wenn du dir die DACs von Texas anschaust (z.B. PCM1753), dann kannst du dir genau das Musik-Interface anschauen. Realisiert wird das über drei Leitungen (BCK, LRCK und DATA). BCK ist der Clock, Data ist auch klar. Wichtig ist hier LRCK. Dieses Signal wechselt immer zwischen linken und rechtem Kanal bei jedem Sample. Die Frequenz von 192kHz kann man auch mit einem 8Bitter erfassen (Über einen Timer) und dann bei einer Anzahl x Samplen einen Interrupt auslösen und irgendwas schalten. Damit bist du sehr synchron zum Musiksignal. Ich denke ein Delay von 1µs ließe sich so realisieren. Die Musikdaten selber laufen dann direkt von SPDIF (über ein entsprechendes IC) direkt an den DAC uns können von da weiter verarbeitet werden. Gruß, jens
Jedes konstante Delay, auch wenn es eine Sekunde ist, bekommt man in Software auf ~0. Sprich: der mittlere Fehler. Was schwerer zu kontrollieren ist, ist der Jitter. Wenn du da 5ms hast, ist das für einen Menschen nicht mehr wahrnehmbar. Pro Meter Abstand von der Tonquelle hast du schon 3ms Delay. Trotzdem macht Kino noch Spaß.
> frage ich mich immer, wie in solchen PC Programmen > ein Ablauf wie der der Lichtsteuerung zu einem anderen wie > der Musik synchron gehalten wird, Man könnte jeden befehl mit einer Zeitangabe versehen, die dem Empfänger sagt, wann er den Befehl ausführen soll. Und dann alle Befehle ein bisschen früher absenden.
S. R. schrieb: > Vor allem hast du keine Feedbackschleife, also darfst du die realen > Latenzen auch gerne ausmessen und deine Steuerung nachkorrigieren. Was meinst du genau damit? Und "Messen" mit Hardware oder per Software messen, wann das Signal wirklich die Soundkarte verlässt? Jobst M. schrieb: > In welcher Form sind denn die I/O-Aktionen überhaupt mit den Audiodaten > verknüpft? Ist es ein spezielles Dateiformat? Mit WAV geht sowas ja > nicht ohne Weiteres. Bisher ist es so geplant, die IO-Ausgabe in einem sereaten Format in etwa dieser Form zu speichern: Pin 1: 1001010010100011 ... Pin 2: 1111000011110000 ... wobei 0 für aus und 1 für an steht und jede Spalte für einen Timestep, Audio seperat als wave. Klops schrieb: > Ich weiß nicht, was genau du planst, aber evtl. musst du auch bedenken, > dass du bei 5m Abstand zum Lautsprecher schon ca. 15ms Latenz > (zusätzlich) hast. Stimmt, vielleicht wäre es sowieso sinnvoll einen Latenzregler am fertigen System zu haben! Milhouse van Hauten schrieb: > Ist bei dir der Weg das Ziel um was zu lernen, oder willst du primär > dein Ziel erreichen? Ich möchte etwas lernen und hardwareseitig mein eigenes System aufbauen (bzw. meinen eigenen "Dateistandard" softwareseitig), daher auch kein DMX oder MIDI nutzen. Jens W. schrieb: > Die Frequenz von 192kHz kann man auch mit einem 8Bitter erfassen (Über > einen Timer) und dann bei einer Anzahl x Samplen einen Interrupt > auslösen und irgendwas schalten. Den Ansatz finde ich ganz spannend, die Übertragung werde ich mir mal näher ansehen. --- Vielen Dank für die zahlreichen Antworten! Das kenne ich von wenigen Foren, dass wirklich versucht wird zu helfen (traurig, aber wahr :D) Ich bin mir bewusst, dass das was ich vorhabe nicht einfach ist, denke aber auch gleichzeitig dass es mit entsprechner Motivation so schwer gar nicht sein kann wenn man es elegant löst. Im Moment schwanke ich ein wenig zwischen: 1) einer Audio-Software-Lösung in C mit ASIO und Latenzregler an der Hardware (das kommt drauf an, wie hoch die Latenz im Endeffekt wirklich schwankt) und einem einfachen 8-bitter an USB für die Steuerung. 2) oder der HW-Lösung, die mich unabhängig vom PC macht, aber mich eventuell mehr Nerven kosten könnte als ich es jetzt abschätzen kann. Ich denke eine fertige Audiolösung auf HW-Chip (wie z.B. I2S, das man ja mit einem Chip sicher in SPDIF wandeln kann) und die Steuerung der Output-Pins auf dem selben Chip wäre der elegante Ansatz für Variante 2; Ich habe zwar Programmiererfahrung, aber das Schreiben eines eigenen Soundtreibers werde ich, auch mangels Freizeit im Studium, in den nächsten Jahren wohl noch nicht schaffen können, da wäre es schön auf etwas wie I2S oder gleich SPDIF zurückgreifen zu können .. Falls jemand noch weitere Ansätze oder geeignete uCs mit Audio-Lösungen parat hat oder diese sogar für ähnliche Projekte nutzt: immer her damit, ich sammle gerne Inspiration, ansonsten vielen Dank für alle Antworten und ich werde dann mal starten :) Grüße PS: Kann jemand, der jetzt einen Überblick über mein Vorhaben und Vorwissen hat ein Buch empfehlen? Ich brauche keine 500 Seiten Elektronik- oder C-Basics (daher sind für mich viele Bücher rausgeworfenes Geld), es sollte aber auch nicht unbedingt für uC-Profis bzw. zu spezialisiert sein .. ich habe zum Lernen immer gerne was in der Hand :)
Was wäre mit 2.1 über SPDIF? dann hättest R/L und im 3ten Kanal kannst deine Schalt-/Digitalinformation schicken. Start, Stop, vor und zurück, wären dann auch kein Problem. Müsste man nur schauen, wie man das am PC dann komfortable "programmiert". Hans
Hans M. schrieb: > Was wäre mit 2.1 über SPDIF? dann hättest R/L und im 3ten Kanal kannst > deine Schalt-/Digitalinformation schicken. > Start, Stop, vor und zurück, wären dann auch kein Problem. > Müsste man nur schauen, wie man das am PC dann komfortable > "programmiert". Ist auf jeden Fall eine Option, um die genannten Funktionen elegant zu realisieren, allerdings müsste ich dazu dann wohl den Codec ändern, dann weiß ich nicht mehr ob es noch so elegant bleibt .. Grüße
Codec ändern? Du missbrauchst doch nur den .1 Kanal als "Datenträger". Für den Player und "Übertrager" ändert sich doch nix. musst im µC nur auf trennen in R/L Kanal und IO-Daten. Der 3te Kanal sollte halt nur nie nicht auf nem Lautsprecher an kommen^^ Hans
> @ Hans
Grade recherchiert: SPDIF ünterstützt leider nur Stereo, also 2 32-bit
Blöcke für den linken und rechten Kanal :/
Stefan U. schrieb: >> hat man bei Windows ja kaum eine Kontrolle über die Latenzen > > Ich bin ziemlich sicher, dass Anwendungsprogramme die Verzögerung der > Audio-Wiedergabe ermitteln können. Richtig, sowohl für die Eingabe als auch für die Ausgabe. BTW: Wenn man mit geringen Latenzen liebäugelt, sollte man sich in Punkto Audio-Hardware im Musiker-Bereich umsehen, da sind 6 und 3ms durchaus üblich und sogar 1,5ms möglich.
Klops schrieb: >>> hat man bei Windows ja kaum eine Kontrolle über die Latenzen >> >> Ich bin ziemlich sicher, dass Anwendungsprogramme die Verzögerung der >> Audio-Wiedergabe ermitteln können. > > Richtig, sowohl für die Eingabe als auch für die Ausgabe. Das muss es sicher geben, ich habe auch ein Focusrite Scarlett 2i2 hier von dem ich mir geringe Latenzen erwarte. Mal schauen, ob ich da eine passende Library finde .. :)
Hennes schrieb: > Grade recherchiert: SPDIF ünterstützt leider nur Stereo, also 2 32-bit > Blöcke für den linken und rechten Kanal :/ Nö. Falsch. Man kann auch mehr als 2 oder auch nur einen Kanal übertragen. Allerdings muss die Hardware das unterstützen. Mir ist keine Hardware bekannt, die das kann. Das Protokoll kann es aber. Zusätzlich zu jedem Sample wird ein U und C Bit übermittelt (Userdata und Channelstatus). Während C in den meisten Encodern fest ist, lässt sich mit dem U-Bit zu jedem Sample ein Bit übertragen. Die 32 Bit bestehen aus Preamble (4 Bit), Audio (24 Bit), sowie Validity, User, Channelstatus und Prüfbit. Wenn man mag, könnte man die 8 unteren Bit des Audiostroms nutzen. Gruß Jobst
Du kannst mal hier reinkucken: http://www.beis.de/Elektronik/ADDA24QS/ADDA24QS.html die kannst du auch bei ihm ordern mit digitalem oder optischem Ausgang, das wäre ja so ein bisschen was du meinst, und alles funktioniert eben mit den teurenADCs DACs http://www.beis.de/Elektronik/ADDA-USB/ADDA-USB.html der passt vielleicht eher besser, kannst ja mal drübersehen. Als Ansatz bzw Einstieg ist das sicherlich hilfreich und dann kann man ja sein eigenes System daraus entwickeln, mit Zeit,.. viel Zeit :)
Es gibt Audiosoftware (DAW) in Hülle und Fülle die Audio und Midi synchron abspielen können. Und das sogar vom Timing so genau, dass man damit Hits produzieren kann. Mit einem kleinen 8Bitter kannst du z.B. Midi-Daten in beliebige GPIO Aktionen übersetzen. Ich steuere seit bestimmt 15 Jahren mit Sonar über Midi Licht und LED Effekte. Neben über GPIOs realisierten Sachen machen dezentrale Controller (AVRs) aus Midi DMX um moderne Lichttechnik anzusteuern. Ist alles evolutionär gewachsen, aber für das was ich brauche ist die Programmierung der Effekte in der Pianorollenansicht der Midi-Spuren sehr einfach.
temp schrieb: > Es gibt Audiosoftware (DAW) in Hülle und Fülle die Audio und Midi > synchron abspielen können. Und das sogar vom Timing so genau, dass man > damit Hits produzieren kann. Mit einem kleinen 8Bitter kannst du z.B. > Midi-Daten in beliebige GPIO Aktionen übersetzen. Wenn es so viel Software dazu gibt die das synchron kann, dann muss es ja auch mit vertretbarem Aufwand möglich sein, sich selbst eine solche Schnittstelle zu definieren. Ich möchte kein MIDI nutzen, da der softwareseitige Lerneffekt auch da sein soll und ich etwas, naja, eigenes haben möchte :) Aber das macht mir auf jeden Fall Mut, ich denke dass ich mich auch erstmal an die ersten Variante wage, also ASIO in C mit dem Focusrite-Interface und ein Arduino Uno als Einstieg zur Hardwaresteuerung per USB. Grüße
>da sind 6 und 3ms >durchaus üblich und sogar 1,5ms möglich. Ja wenn man genug Kohle für ein Hammerfall Interface hat... Ansonsten ist die Kombination Treiber / Hardware viel wichtiger. Also wie stabil läuft das Interface...Roland USB-Karten kann ich empfehlen. Ein PC als Master beim Synchronisieren ist meistens murks, besser ein externen HArdwaresequncer mit dem man die DAW steuert. So machen wir das: Gruß´J
atari st hat midi onboard, also keine timing Probleme. Nur kurz zu USB, weiss nicht ob das bekannt ist war: USB teilt sich ja immer je nach PC und Anwendungen einen Bus für alles, also sobald mehrere USB-Geräte oder ein Hub angeschlossen sind, kommt es da sicherlich zu messbaren Verzögerungen, die niemals gleich sein werden, weil die halt davon abhängen welche Geräte gerade abgefragt werden. Ob das ganze dann hörbar und oder sichtbar wird, ist eine andere Frage. Mir wurden mal die Motu USB to Midi empfohlen, benutze aber selber nichts dergleichen. Und an deiner Stelle würde ich mich schon durchaus auf Midi stürzen, da alle Geräte im Studio meist Midifähig sind, da kann man dann doch viel herumspielen, aber das ist ja jedem selber überlassen :)
Als mögliche Lösung für das Synchronisationsproblem könnte ich mir auch vorstellen eine RTC auf der Hardware zu nutzen und dann beim Abspielen zu sagen: fange exakt zu dieser zeit an mit der Hardware. Softwareseitig müsste ich das ja auch hinbekommen, sofern die Latenz im Toleranzbereich messbar ist. Ich weiß allerding nicht wie realistisch dieses Vorhaben ist .. jo schrieb: > besser ein > externen HArdwaresequncer mit dem man die DAW steuert. Mit welchem Aufwand muss ich da etwa rechnen? (nicht, dass ich mir die Zeit nicht nehmen will, aber das klingt für mich als Laien schon fast so komplex wie SOuntreiber selbst programmieren :D) Stefan S. schrieb: > Und an deiner Stelle würde ich mich schon durchaus auf Midi stürzen, da > alle Geräte im Studio meist Midifähig sind, da kann man dann doch viel > herumspielen, aber das ist ja jedem selber überlassen :) Vielleicht sollte ich mich dem wirklich erstmal beugen, dann könnte man die Hardwaresequenz auch über ein MIDI-Keyboard oder ein Sequencer-Pad später bequem einspielen .. Vielleicht kann ich ja intern meine eigene Lösung entwickeln und das extern mit MIDI wrappen, falls das nicht zu viel Leistung verbrät .. Grüße
>Mit welchem Aufwand muss ich da etwa rechnen?
Du meinst die Bauzeit? Ca. ein Jahr mit Gehäuse und allem. Oder Monetas?
Bestimmt 400€, nur Bauteile ohne Bauzeit. Aber das Ding kann halt fast
alles und am Rest wird weiterentwickelt.
Gruß J
Einfach einen Player nutzen der Timecode ausgibt. Per Midi,Artnet oder sonst was. Timecode einlesen und Funktionen auslösen, wenn es sooo genau sein soll. Dann eiert auch nichts auseinander. http://www.memsolution.com/ gibt sogar 8 Audiochannels wieder und besitzt Timecode.
:
Bearbeitet durch User
Marco H. schrieb: > Einfach einen Player nutzen der Timecode ausgibt. Per Midi,Artnet > oder sonst was. > Timecode einlesen und Funktionen auslösen, wenn es sooo genau sein soll. > > Dann eiert auch nichts auseinander. > > http://www.memsolution.com/ gibt sogar 8 Audiochannels wieder und > besitzt Timecode. Den Player würde ich gerne selbst schreiben, zwecks Editorfunktionen und Einstellungen etc. aber ich schaue mir das mal ans Inspiration an :)
Dann mach mal ... USB würde ich aber aus dem Schwierigkeitsgrad heraus nicht empfehlen. TimeCode per Artnet also über Ethernet zu versenden wäre einfacher und hierzu gibt auch schon Softwarelösungen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.