Hat jemand eine S/PDIF Interface als CORE in HDL (programmiert ?)
Ich will eine Recordereinheit für Studiogeräte als FPGA programmieren
und das USB-Protokoll einbinden um aus Studiogeräte direkt auf einen
USB-Stick aufnehmen zu können.
Das war mir bisher entgangen. Werde mir das mal ansehen. Was ich
benötige ist z.B: auch eine automatische Detektion von 16/24 bit und
natürlich der Freuqenz von 48/96 kHz. Ich möchte ein FPGA bauen, das
die eingehenden Daten von biszu 8 Kanälen synchronisiert als wav auf
einen USB-Stick oder einen anderen Flash-Speicher schreiben kann. Dazu
müssen die Daten von mindestens 4-5 samples gepuffert und resampled
werden um einen effektiv koheränten Datenstrom zu erhalten.
Mein Problem sind derzeit ein ganze Anzahl von nicht oder nur
unzureichend synchfähigen Digitalquellen unterschiedlicher Standards,
die ich gerne einfacher zusammen betreiben möchte.
Hallo,
wirst Du wahrscheinlich ohnehin schon haben, aber falls nicht, hier
kannst Du Dir den passenden AES-Standard runterladen (AES3-2003):
http://www.aes.org/publications/standards/
Ist quasi (fast) dasselbe wie S/PDIF.
Interessant hierzu auch folgendes Dokument ("Interfacing AES3 and
S/PDIF"): www.rane.com/pdf/note149.pdf
Evtl. auch noch von Interesse könnte das hier sein:
http://www.altera.com/literature/an/an369.pdf
HD will ich wegen des Lärms nicht, aber CF wäre durchaus eine lohnende
IDEE. Ich benötige das Systemauch noch für eine anderen Zweck: Es gibt
inzwischen Mikros mit Digitalausgang. Dort könnte man ein
batteriegetriebens Speichersystem gebrauchen. - Aber es VOLLKOMMEN
LAUTLOS sein!
Hallo Xenu, bei der AES bin ich Mitglied :-) aber die Altere-Note hatte
ich noch nicht erspäht. Danke.
Werde mich mal dranmachen, sobald ich Zeit dafür finde, ob dann AES
oder SPDIf, ist am Ende nur eine Frage der Analogkomponente am Eingang-
und das ist ja hinlänglich dargelegt. ;-)
Ja, hab ich schon gesehen und weiter oben in dem dortigen Them auch was
dauz gesagt. Das ist sehr interessant, aber es gibt im Markt schon
programmierbare Lösungen mit vorzüglichen analogen Interfaces. In
meinem Falle ist es die Chameleon. Desweiteren bliebe die Möglichkeit,
sich in die Developper-Riege einiger anderer MOT-basierter Systeme
einzuklinken, was aber nicht so einfach ist: Ich hatte mich mal mit
SYDEC (-> "soundscape mixtreme") diesbezüglich besprochen - habe aber
nicht die Zeit übrig, die es erfodern würde, dort vertiefter
einzusteigen. Ansonsten liebäugle ich derzeit mit der UAD-1. Generell
würde ich würde aber aus aktueller Sicht in jedem Falle zu einem
MOT-basierten System tendieren: Die 65303-Architektur kenne ich
inzwischen einigermassen, habe Code dafür und es arbeiten eine heilige
Masse an Studiogeräten, Synthies und Mischpulten mit exakt diesem
Prozzi! Theoretisch könnte man jederzeit auf ein proprietäres System
überwechseln, aber die Zeit, die Zeit, die Zeit:
Für den Gegenwert des Zeitaufwandes einer solchen Neuentwicklung
bekomme ich den neuesten Virus-TI, das neueste SoundScape-System mit
allen plugins und einen Hartmann Neuron!
Daher beschränke ich meine derzeitigen Überlegungen darauf, Hardwareund
Software zu bauen, die ich NICHT kaufen kann, wie ich sie brauche! Das
programmierbare FPGA mit S/PDIF core wäre exakt ein solchess.
Hallo,
etwas spät, aber vielleicht hilft es dir noch:
Ich stand auch vor dem Problem einen AES3-Eingang auf einem FPGA zu
implementieren. Die opencores-Variante habe ich schnell wieder
verworfen, da ich mit der Doku nicht zurecht gekommen bin.
Ich habe dann den cwda03 der Firma coreworks (http://www.coreworks.pt)
verwendet, innerhalb einer Viertelstunde hatte ich einen AES3-I²S
Umsetzer am Start. Kostet halt eine Kleinigkeit, aber wenn ich mich
eine Woche mit der opencores-Variante beschäftigt hätte wäre ich auf's
gleiche herausgekommen.
Ich möchte mit möglichst wenig externer Hardware auskommen und auch
keine IPs kaufen :-) daher werde ich mir die open core Variante antun.
Erstmal kümmere ich mich aber um die Hardware und das CF. USB ist aber
nicht vom Tisch, da das Teil letztlich auch mal gesteuert werden können
soll und da braucht es eine PC Schnittstelle.
-> USB: http://www.mikrocontroller.net/forum/read-9-330659.html#new
>Daher beschränke ich meine derzeitigen Überlegungen darauf, Hardwareund>Software zu bauen, die ich NICHT kaufen kann, wie ich sie brauche! Das>programmierbare FPGA mit S/PDIF core wäre exakt ein solchess.
@ Jürgen Schuhmacher: Welche Audiohardware ist das?
Ich habe das Projekt etwas verfolgt, hast Du das jetzt weitergebaut?
Auch mit USB und S/PDIF
>Welche Audiohardware ist das?
@Matthias: Es handelt sich eigentlich um mehrere Dinge: Einmal gilt es,
diverse Clock- und Synch-Probleme im Studiosetup zu lösen. So geht es um
das ofrt benötigte Resampling und es geht um einfache Delays von
Kanälen, um alle Geräte wieder Samplegenau zu bekommen -> Anpassunge der
Latenzen.
Dazu brauche ich erst einmal nichts anderes, als einige SPDIF- oder AES
EBU Eingänge / Ausgänge und etwas RAM. Diese Config kann ich funktionell
zwar am Digitalpult im Prinzip auch fahren, verstopfe mir aber damit
nahezu alle Kanäle des Pults, das ich gerne für wichtigere dinge über
hätte, wie Aux-Send Effekte, Abmischung der Analogsignalquellen etc.
Für ein FPGA + RAM ist das aber alles kein Thema. Die Messungen für die
Delays habe ich schon :-)
Auf diese Weise kriegt man Hardwaresoundkarte, DSP-System und die
AD-Wandler auf einige Samples genau hin - ganz ohne Aufwand. Das ist
wichtig brim Prozessieren von Stereosignalen, wo Reflexionen wirklich
auf die us genau kommen müssen, um nicht auf der Stereobasis zu wandern
oder falsch zu wirken.
Ein Bespiel sind Choraufnahmen, wo man Stützmikrofone passend verzögert,
um sie Laufzeit-gestteuert auf der Stereobasis zu schieben. Das mache
ich im Moment bei der Aufnahme mit einer DSP-Soundkarte. Ferner müssen
einige EQs und Kompressoren / Limiter laufen. All das lässt sich in
einem Spartan machen, der gerade 24% gefüllt wird. Bei voll gepipelinter
Funktion habe ich derzeit etwa 640 clocks Latenz. Die Zahl der Kanäle
spielt dabei schon gar keine Rolle mehr :-)
Ich benutze z.B. ein und denselbem EQ mehrfach in der Signalkette,
wodurch ich je Kanal nur ein 5tel der Bandbreite habe. Da ich aber in
jedem EQ-Druchlauf mindestens 80 clocks Latenzt habe, kann ich auch 80
Kanäle mischen. Das reicht mir fürs Erste ! :-)
Als Hardware benutze ich einen Prototy<penaufbau aus inzwsichen
Spartan3-FPGAs. Ich habe aber noch keine voll ausgebauten Platinen, da
mir hierfür die Zeit fehlt :-(
> Ein Bespiel sind Choraufnahmen, wo man Stützmikrofone passend> verzögert, um sie Laufzeit-gestteuert auf der Stereobasis zu> schieben. Das mache ich im Moment bei der Aufnahme mit einer> DSP-Soundkarte.
Kann man dazu Nöheres erfahren? oder hören?
>Ein Bespiel sind Choraufnahmen, wo man Stützmikrofone passend verzögert,>um sie Laufzeit-gestteuert auf der Stereobasis zu schieben. Das mache>ich im Moment bei der Aufnahme mit einer DSP-Soundkarte. Ferner müssen>einige EQs und Kompressoren / Limiter laufen. All das lässt sich in>einem Spartan machen, der gerade 24% gefüllt wird. Bei voll gepipelinter>Funktion habe ich derzeit etwa 640 clocks Latenz. Die Zahl der Kanäle>spielt dabei schon gar keine Rolle mehr :-)
wie machst du das ?! bzw welchen spartan hast du ?
also delay bekommt man ja recht einfach hin. aber eq/comp/limiter ...
mehrkanalig im spartan ?
der code würd mich mal interessieren da ich ja auch mit meinem
audio-projekt in eine ähnliche richtung gehe (nur das es da
frei-programmierbar ist, also modular).
Ursprünglich ist es ein System aus Spartan 2 FPGAs, habe aber auch
Prototypen mit S3E gebastelt. Es war sogar auch mal gedacht, das zu
verkaufen, wurde aber vorerst eingestellt. Das System kann in mehrerlei
Arten genutzt werden, die einzelnen Module kompiliere ich passend rein.
Ich benutze es, ummehrkanalig zu mastern und einiges an Klangbearbeitug
zu machen.
Zum Thema Synchronisation: Ich benutze derzeit vorwiegend ein EVAL
board, um diese Samplinganpassung zu machen. Eigentlich geht es darum,
alles auf die gleiche Clockflanke des Audiotaktes zu bringen, gfs zu
resampeln wo nötig. Wichtig wird das bei autarken Quellen, z.B.
Digitalmikrofonen ohne Synchfunktion.
Zum Thema Delay: Bei akustischen Aufnahmen werden neben einem
Hauptmikrofon auch Zusatzmikrofone eingesetzt, deren Laufzeitvorteil
(sie stehen näher an der Quelle) relevant ist. Diesen Vorteil und die
Laufzeit untereinander passe ich mit Delays an. Ich bearbeite auch die
Echoreflexionen so, dass für das Ohr authentische Echos entstehen, die
helfen, einen realistischeren Eindruck zu bekommen. Das geht sowohl auf
der DSP-Karte als auch im FPGA voll parallel. Die DSP-Karte ist aber
eingeschränkt user-progrmmierbar, daher bin ich von den DSPs weg.
Welche Delays und EQs ich einsetze ist natürlich Toningenieurgeheimnis,
aber das Grundprinzip des Verschiebens der Quellen auf der Stereobasis
lässt sich nachlesen: Sieh mal das Thema "Hörkurven" im Tontechnikbuch
von M. Dickreiter oder bei www.sengpielaudio.com Als Grobansatz kann man
rechnen, dass eine einzelne Quelle voll im linken Lautpsrecher steht,
wenn das Signal auf dem rechten zwar gleichlaut, aber 1-2ms später
kommt.
Ich habe mein System nun soweit, dass ich theroetisch auf die ns genau
schieben kann :-)
"Ich habe mein System nun soweit, dass ich theroetisch
" auf die ns genau schieben kann :-)
Wieso muss man was bei Audio auf die ns genau schieben?
Die samples liegen doch im Bereich von us.
"eq/comp/limiter ... mehrkanalig im spartan ?"
Wieviele Kanaäle lassen sich denn im Spartan machen und wie genau sind
diese Equalizer?
Die ganzen Platinen hängen wie in einer pipeline digital aneinander und
sind auf Datenebene verknüpft. Allerdings gehe ich nicht auf seriell
SPDIF zurück, sondern bleibe parallel bei 96kHz x (2 x 24 Bit +
Steuerleitungen). Das heisst z.B. dass Effekte aus einem Nachbar-FGPA
nicht in Echtzeit, also im selben Sample, wieder eingeschleift werden
können. Ich kompensiere das mit Verzögerungen im finalen Mischer
Ich habe auch höhere Raten probiert, aber es bringt faktisch keinen
echten Erfolg für dies APP. Man bekommt nur irgendwann Schwierigkeiten
mit der Signalintegrität, weil der Eigenbau da naturgemäß etwas
limitiert ist :-)
Für Daten, die in einem Netz hin und her geschaufelt werden solle,
müsste man sich aber was anderes überlegen. Am Besten eine Art
LVDS-Interface zwischen den FPGAs.
@Jürgen
Hast Du den Core aufgebaut? Ich möchte mir einen Verteiler für Consumer
Audio / Heimkino bauen und wollte mich an dem Core von "open cores"
probieren. Welche Erfahrungen hast Du mit dem gemacht?
Jürgen S. schrieb:> Welche Delays und EQs ich einsetze ist natürlich Toningenieurgeheimnis,
Dazu habe ich eine Frage:
Das Ohr hört den Schall aus der einen Ecke logischerweise lauter und
früher. Das müsste sich eigentlich genau berechnen lassen- jedenfalls,
für eine bekannte Person. Wenn der Schall z.B. aus der 180-Grad Position
erklingt, müsste das eine Ohr alles und das andere gar nichts mehr
hören. Dazwischen bewegt sich das Signal langsam in ein 50:50 -
Verhältnis würde ich mal annehmen, wenn die Quelle in die
Geradeausrichtung wandert.
Andere Frage: Wozu benötigt man überhaupt ein Delay? Eine
Lautstärkeänderung reicht doch, eigentlich.
Thomas Riesche schrieb:> Andere Frage: Wozu benötigt man überhaupt ein Delay? Eine> Lautstärkeänderung reicht doch, eigentlich.
Nein, reicht nicht. Da ist zum Beispiel das "Gesetz der ersten Welle":
Das menschliche Gehör (oder vielmehr das Processing im nachgeschalteten
Gehirn) nimmt die erste Welle als Quelle wahr, selbst wenn danach
Reflexionen kommen, welche wesentlich lauter sind.
Die reine Lautstärkeänderung zur Positionierung ist ein "künstlicher"
Fall, wo die beiden (identischen, aber unterschiedlich lauten) Quellen
gleichzeitig auf den Menschen treffen.
Thomas Riesche schrieb:> Hast Du den Core aufgebaut?
Ich habe mir was Eigenes gemacht. Ich verarbeite gleich mehrere Kanäle
und kann auch höhere Bandbreiten, als im original Protokoll vorgesehen,
weil ich damit die Latenz zwischen zwei boards reduzieren kann, wenn ich
beide Seiten im Griff habe.
Du kannst ruhig den opencores nehmen, der ist gut getestet. Das
Nachbauen ist aber auch nicht schwer, da nur serielles Protokoll.
Thomas Riesche schrieb:> Das Ohr hört den Schall aus der einen Ecke logischerweise lauter und> früher. Das müsste sich eigentlich genau berechnen lassen- jedenfalls,> für eine bekannte Person.
Das kann man, ja und ich habe damit auch rumprobiert. Man kann
theoretisch jedes trockene Signal virtuell irgendwo in einem 3D-Raum
platzieren und alle Reflektionen nachahmen, die das Ohr abbekommt -
stösst dann aber auf ein praktisches Problem: Wie bringt man das Signal
in die menschlichen Ohren?
Das normale Stereoverfahren über zwei Lautsprecher führt dazu, dass
beide Ohren beide Lautsprecher hören, wodurch eine Überlagerung und
Abschwächung entsteht. Zudem kommen oft noch Wände hinzu, die im
Wohnzimmer die Akustik verändern. Nimmt man aber Kopfhörer und gibt die
Signale isoliert von einander auf das Gehör, fehlen die mechanischen
Ohrreflexionen und die Schallanteile, die durch die Schädeldecke
eindringen. Man bekommt auch dann nicht den realen Eindruck, einer
echten im Raum platzierten Schallquelle. Das Stereosystem hat hier eben
gewisse Grenzen und diese Randbedingungen müssen beachtet werden.
Die sich hieraus ergebenden Abbildungen sind abhängig von den sognannten
Hörkurven und diese sind für den Durchschnittsmenschen sogar schon
bekannt. So braucht es für eine reine Lautstärkestereofonie je nach
Frequenz rund 18dB-20dB Unterschied für eine totale Auslenkung in +/-45
Grad, während man ca. 1ms (Höhen)-2ms(Bässe) Verzögerung benötigt, um
denselben Effekt nur mit Phasenverschiebung zu erzielen. In der Praxis
hat man meistens beides, bzw eine Mischung aus verschiedenen Verfahren.
Für 4CH-Stereo oder 5/7-Kanal Surround gelten wieder andere Gesetze,
weil die Lautsprecher wieder anders stehen.
Die Tontechnik ist an diesem Punkt alles andere als trivial, z.b. ist es
so, dass man signaltechnisch ein reines Lautstärkesterosignal, wie aus
dem Mischpult (panning) oder dem XY-Verfahren, sehr gut nachträglich in
der Breite ändern kann, wenn (weil!) es mit einer MS-Stereomatrix
bearbeitet wird. Für Phasenverschiebungsstereo, wie ich es gerne nenne,
wie man es aus AB-Aufnahmen oder einem Mischpult-Delay erhält, versagt
eine MS-Matrix völlig.
Ich habe für meine Chor-Aufnahmen inzwischen ein Mikrofonsystem
entwickelt, das mit zwei speziellen Mikrofonpaaren in variantem Abstand
beide Verfahren nutzt, wobei sich die Nachteile jeweils gegenseitig
etwas wegheben und dies sogar für einen sehr weiten Frequenzbereich und
auch in der off axis Region. Sie klingen über Lautsprecher und Kopfhörer
gleichermassen voluminös. Die gefundenen Abstände der Mikros, deren
Richtung und deren signaltechnische Bearbeitung und Überlagerung sind
aber Ergebnis von Probeaufnahmen und stehen in keinster Weise mit den
rein rechnerischen Phasenverschiebungen im Zusammenhang, wie man sie für
eine durchschnittliche Kopfbreite erwarten könnte, oder wie sie sich
mathematisch aus der Abschattung des Kopfes für hohe Frequenzen ergeben.
Dies hat mit dem sogenannten Trading zu tun, wenn (negative)
Lautstärkeelongation auf positive Phasenelongatino treffen, was nicht
linear ist und sehr viel mit der Aufnahmecharakteristik der Mikros zu
tun hat. Die Ganze Geschichte ist eine recht komplexe Kompromissbildung.
Was man tun kann, ist, mit den Raumreflexionen, Verzögerungen und
Lautstärkeveränderungen die Situation durchzurechnen, die sich für eine
definierte Schallquelle an verschiedenen Positionen im Raum ergibt und
dann dort virtuelle Mikrofone mitsamt ihrer Charakteristik zu nutzen,
wie man sie bei den verschiedenen Stereofonieverfahren einsetzen würde
(AB, Surround, ORTF, XY etc). Damit lassen sich künstliche Instrumente
in Mixes einfügen. Nach einer gehörmässigen Optimierung sind die
Parameter aber letztlich auch wieder etwas anders, als man es
mathematisch ansetzen würde.
So richtig hilft beim komplexen Stereoeindruck nur, manuell zu pegeln
und zu verschieben und die Wirkung akustisch zu überprüfen.