Hallo,
ich plane im Moment eine Vorstufe für den Plattenspieler welche nicht
wie sonst üblich die Entzerrung mit Analogen Filtern erledigt sondern
per DSP. Das hat diverse Vorteile, man kann einfach Tiefpassfilter
(Subsonic) für wellige Platten (etc.) realisieren, alle
Schneidkennlinien die verwendet wurden mühelos nachstellen, Toleranzen
des Tonabnehmers ausgleichen etc. Moderne hochwertige Audiosysteme sind
sowieso immer häufiger Digital, eine Schnittstelle bietet sich hier
einfach an.
Da die Platte technisch bedingt auf ~50dB Dynamik limitiert ist und
moderne ADCs immer besser werden (SNR/Dynamik >120dB) sollte sich ein
sehr guter SNR des Gesamtsystems erreichen lassen.
Folgendes Konzept:
-> Eingangsstufe die optimal an die Abnehmer anpassbar ist (MM/MC) und
eine kleine Vorverstärkung macht. (Für MM +20dB, MC +40dB)
-> Einen IC wie der PGA2500, eigentlich ein Digital steuerbarer
Mikrofonvorverstärker, macht die Pegelanpassung für den ADC. Diese ICs
sind optimal dafür da sie trotz hoher Verstärkung noch breitbandig und
Verzerrungsarm sind.
-> Einen extrem hochwertigen ADC wie den AK5397 (im Mono-mode
unbewertete 123dB DR, mit A-Bewertungsfilter 130dB) Nach der Entzerrung
hat man immernoch >83dB DR, das schaffen die meisten Phono Vorverstärker
nicht. Die Platten schon garnicht.
Nun wollte ich die Entzerrung ursprünglich in einem DSP oder besser FPGA
realisieren in der Hoffnung die Filter in Quartus recht einfach zusammen
zu klicken, da ich einen Touchscreen zur Bedienung und diverse
Steuerungsaufgaben möchte ist die benötigte Rechenleistung nicht ohne.
Ganz zu schweigen davon das ich ein absoluter Neuling mit FPGAs bin.
Ich frage mich nun ob sich die Entzerrung, Steuerung sowie Verwaltung
des Touchscreens mit eigener GUI nicht viel einfacher auf einem
Raspberry-Pi realisieren lässt? Der hat über die GPIO schon eine I2S
Schnittstelle an die ich die ADCs anknüpfen kann sowie SPI zur Steuerung
diverser Relais und der PGAs. Günstiger als die meisten FPGA Eval Board
ist er auch, es gibt viele Informationen zur Programmierung dazu im
Netz.
Der Pi würde folgendes erledigen müssen:
-> GUI + Auswertung des Touchscreens
-> DSP Funktionen
-> Abfrage diverser Taster, Steuerung von etwa 40 Relais (Über SPI)
-> Echtzeitanalyse des Signals um Übersteuerungen des ADCs oder bei der
Signalwandlung zu finden und anzuzeigen, die Spitzenpegel sollen auf dem
Display angezeigt werden.
-> SRC sowie Konvertierung der Wortlänge auf 20 oder 16 Bit sodass man
wählen kann wie das digitale Ausgangssignal aussehen soll.
Mich würde Eure Meinung interessieren, ist der Raspberry ein guter Weg
sowas zu realisieren oder würdet Ihr das anders lösen?
Danke!
Jan schrieb:> Mich würde Eure Meinung interessieren, ist der Raspberry ein guter Weg> sowas zu realisieren oder würdet Ihr das anders lösen?
Die GUI brauchst du auf dem Smart Phone. Was soll die auf dem Raspberry?
Du kannst die komplette Schallplatte ja mit einem
Rasterelektronenmikroskop einscannen und die Soll-Töne digital aus dem
Verlauf der Spur herauslesen und dabei Kratzer ohne andere mechanische
Beschädigungen herausfiltern.
In der professionellen Audiotechnik gibt es bestimmt ein Gerät was die
gewünschte Entzerrung bereits kann. Wenn Du genug Geld hast, dann auch
mit einem DSP und ganz viel Bit und Khz. Speise das Audiosignal der
Schallplatte einfach dort ein und fertig.
Oder eine gute Soundkarte für den PC. Die Entzerrung schafft ein guter
PC dann in Software, vor allem wenn es nicht in Echtzeit sein muß.
Jan schrieb:> Ich frage mich nun ob sich die Entzerrung, Steuerung sowie Verwaltung> des Touchscreens mit eigener GUI nicht viel einfacher auf einem> Raspberry-Pi realisieren lässt?
Nein, das gibt es alles längst fertig.
Georg
>Warum aber so viele Relais?
40 waren übertrieben. Es gibt Relais zum auswählen MM/MC, Eingangswahl
und Lastkapazität / Lastwiderstand für die Abnehmersysteme.
>Die GUI brauchst du auf dem Smart Phone. Was soll die auf dem Raspberry?
Touchscreen, ist wie ich finde die schönste Möglichkeit viele
Bedienelemente in ein DIY Gerät zu integrieren.
>In der professionellen Audiotechnik gibt es bestimmt ein Gerät was die>gewünschte Entzerrung bereits kann. Wenn Du genug Geld hast, dann auch>mit einem DSP und ganz viel Bit und Khz. Speise das Audiosignal der>Schallplatte einfach dort ein und fertig.>>Oder eine gute Soundkarte für den PC. Die Entzerrung schafft ein guter>PC dann in Software, vor allem wenn es nicht in Echtzeit sein muß.
Sowas gibt es tatsächlich schon wenn auch selten:
https://www.linn.co.uk/sources/turntables/phono-stageshttps://www.transvinyl.com/https://www.devialet.com/de-de/expert-pro-ram-phono-preamplifiers/
Über ein Audio Interface + PC höre ich im Moment meine Platten, das geht
(auch in Echtzeit) perfekt. Nur will ich halt nicht immer den (recht
lauten) PC laufen lassen, alles in einer Box wäre mir lieber.
>Nein, das gibt es alles längst fertig.
Hast Du ein Beispiel? (Link)
Oder meinst Du solche Geräte wie ich oben verlinkt habe?
Jan schrieb:> Hast Du ein Beispiel? (Link)> Oder meinst Du solche Geräte wie ich oben verlinkt habe?
Z.B. MP3-Player?
Schallplatten kann man als MP3 digitalisieren und dann auf tausend Arten
weiterverwenden. Entzerren muss man nichts, das tut die Software
sowieso, aber man kann die Daten weiterbearbeiten, z.B. Kratzer löschen
usw.
Jan schrieb:> ich plane im Moment eine Vorstufe für den Plattenspieler welche nicht> wie sonst üblich die Entzerrung mit Analogen Filtern erledigt sondern> per DSP
Das war ein völlig anderes Thema. Vielleicht ist morgen ja wieder alles
ganz anders. Ich hol mir schon mal ein Handtuch (zum werfen).
Georg
Moin,
Das ist doch ein typische Beispiel, wo man die Gesamtsoftware ziemlich
leicht in 2 Teile teilen kann: Einen der Echtzeitanforderungen hat, und
einen der das nicht hat.
Alles was nicht Echtzeit ist, laeuft prima auf dem Raspi; fuers die
Echtzeit (Audio-Filter-Gedoens) nimmt man halt einen extra µController -
fuer's RIAA entzerren (als IIR) musses kein so besonders schneller DSP
sein. Irgendwas mit hardwareunterstuetzten I2S Ports; also z.b. was
entsprechendes aus der STM32 Familie oder so.
Vom Raspi aus kann der µC dann mit recht zeitunkritischen Signalen
gesteuert werden.
Gruss
WK
> Haben denn digitale RIAA Filter signifikante Vorteile gegenüber den> analogen?
Ja, man koennte so einen digitalen Filter in guter Qualitaet heute
vermutlich billiger bauen wie einen guten analogen Filter vor allem
natuerlich wenn sowieso irgendwo in der weiteren Verarbeitung ein
Rechner vorkommt. Da aber die Hifianbeter in ihrer Ahnungslosigkeit
alles mit maximalen Aufwand bewerfen relativiert sich das dann dort
schnell wieder.
Lustig aber, wenn man die vorteile digitaler Signalverarbeitung ernst
nimmt dann sollte man Schallplatten sowieso als erstes in den Klo
kippen. Einmal ordentlich samplen und dann weg damit. Noch besser das
ordentliche Samplen einem Profi ueberlassen wo dies moeglich ist (CD
kaufen) und nur dann selber machen wenn es keine Alternative gibt.
olaf
>Und warum nicht das gesampelte Audio mit z.b. Audacity bearbeiten?
Weil ich das in Echtzeit erledigen will, also nicht erst Daten Speichern
und dann anschließend entzerren.
>Alles was nicht Echtzeit ist, laeuft prima auf dem Raspi; fuers die>Echtzeit (Audio-Filter-Gedoens) nimmt man halt einen extra µController ->fuer's RIAA entzerren (als IIR) musses kein so besonders schneller DSP>sein.
Der Pi ist in der Anwendung sowieso total unterfordert, der sollte die
DSP Aufgaben doch nebenher erledigen können. Gibt ja schon so Sachen wie
BruteFIR die wesentlich aufwendiger sind und prima auf dem Pi rennen.
Mir geht es darum wie man so ein System am besten aufsetzen kann,
vielleicht hat sich hier ja schonmal jemand mit dem Pi als DSP
beschäftigt und hat Hinweise/Tipps.
>Haben denn digitale RIAA Filter signifikante Vorteile gegenüber den>analogen?
Zumindest keine hörbaren. Interessant ist das eher wegen
unterschiedlicher Entzerrkurven, Filter und Kompensation des TAs.
>Warum nicht gleich einen CD Player nehmen, wenn du eh das analoge >Signal digital
verpfuschst?
Warum verpfuschen? Digital ist von der technischen Seite um Welten
besser als das was die Analoge Rumpelplatte kann. Man kann das Signal
problemlos Digitalisieren und zurückwandeln ohne hörbaren
Qualitätsverlust, zumindest wenn man das Thema nicht religiös
betrachtet.
>Ja, man koennte so einen digitalen Filter in guter Qualitaet heute>vermutlich billiger bauen wie einen guten analogen Filter vor allem>natuerlich wenn sowieso irgendwo in der weiteren Verarbeitung ein>Rechner vorkommt.
Im Gegenteil. Die Anforderung an den Analogteil steigen extrem. Mit
einem Mittelklasse ADC die Entzerrung zu erledigen kann nur schief
gehen, alleine für die Entzerrung gehen 40dB Dynamik verloren. Und eine
Schaltung die ~60-80dB linear und Verzerrungsarm bis 20kHz verstärkt ist
auch nicht ohne.
> Mir geht es darum wie man so ein System am besten aufsetzen kann,> vielleicht hat sich hier ja schonmal jemand mit dem Pi als DSP> beschäftigt und hat Hinweise/Tipps.
Vergiss einfach diese Anbetung dreier Buchstaben "DSP". Ein DSP
unterscheidet sich in absolut nicht von einem normalen Mikrocontroler
ausser das er darauf optimiert wurde bestimmte Berechnungen schneller zu
erledigen. Wenn du aber ein Problem mit soviel Rechenleistung bewirfst
wie eben da ist und das ist ja in dem Falle ein Raspberry, dann
berechnest du das einfach vollkommen ohne nachzudenken in Plain-C und es
wird gehen.
Es ist technisch moeglich, also oeffne einfach main.c im Editor deiner
Wahl und lege los.
Olaf
Moin,
Jan schrieb:> Der Pi ist in der Anwendung sowieso total unterfordert, der sollte die> DSP Aufgaben doch nebenher erledigen können. Gibt ja schon so Sachen wie> BruteFIR die wesentlich aufwendiger sind und prima auf dem Pi rennen.
Ja, stimmt schon; die meiste Zeit wird dabei die CPU vor sich hinidlen.
ABER es ist halt nicht sichergestellt, dass es nicht doch irgendwann mal
zu einem Bufferover/underrun kommen kann, weil gleichzeitig irgendwer
grad' am Display rumdaddelt, auf der SD-Card grad irgendwelche
Operationen laenger dauern, und auf'm USB auch grad irgendwie viel los
ist und sonst noch ein Erdbeben und eine Flutwelle auftreten.
Natuerlich kannst du auch unter Linux hergehen und dein komplettes
Filtergedoens + saemtlichen I/O dafuer in die obere Haelfte eines
entsprechenden Interrupthandlers schreiben - dann sollte das schon
klappen, auch wenn der Rest des Systems auf 100% CPU Last haengt. Aber
ich hab' da leise Zweifel, ob das die Raspi Hardware mitmacht und ob du
das dann gebacken kriegst.
Waehrend die Raspi+µC Loesung da halt ziemlich entspannt ist, weils auf
einem µC deutlich simpler ist, genau die Anzahl von CPU-Zyklen fuer
deine Algorithmen zu bestimmen und der sich um sonst nix
unvorhergesehenes kuemmern muss.
Gruss
WK
Jan schrieb:> Weil ich das in Echtzeit erledigen will, also nicht erst Daten Speichern> und dann anschließend entzerren.
Pi und Echtzeit geht sowieso eher nicht. Es sei denn Du willst Dich mit
Echtzeit-Betriebssystemen befassen.
Also werden die Daten eh zwischengespeichert.
Jan schrieb:> Interessant ist das eher wegen> unterschiedlicher Entzerrkurven, Filter und Kompensation des TAs.
Aber gerade für RIAA gibt es nun klare Vorgaben, wie der Filter
auszusehen hat. Was willst Du da für unterschiedliche Kurven haben?
Also sooo schlecht finde ich die DSP-Audiotechnik nicht.
Ich habe ein Mischpult, was intern mit einem DSP arbeitet, das Signal
muß also durch drei Einheiten durch und ich merke dabei jedenfalls keine
Qualitätseinbußen.
Die großen PA-Verleiher gehen auch immer mehr den Weg zur
Digitaltechnik, da geht das Signal von der Bühne digital zum FOH, wird
dort digital abgemischt und geht digital bis zu den Endstufen zurück.
Keine riesen Multicore-Kabel mehr, kein Dimmer-Geschnarre (solange das
nicht bereits vor den AD-Wandlern einstreut)... bei manchen Mischpulten
gibts eine App über WLAN, damit macht man den Sound ganz easy auf einem
Tablet von der Würstchenbude aus.
Ich verstehe nur nicht, warum man den Aufwand zum Entzerren von
Schallplatten betreiben sollte.
Jan schrieb:> Weil ich das in Echtzeit erledigen will, also nicht erst Daten Speichern> und dann anschließend entzerren.
Echtzeit wäre es wenn das während der Aufnahme der Platte stattfindet,
das Abspielen einer Platte findet ja Tage, Monate, Jahre nach der
Aufnahme statt.
> Aber ich hab' da leise Zweifel, ob das die Raspi Hardware mitmacht> und ob du das dann gebacken kriegst.
Tja, der Weg ist das Ziel. Wuerde es um die Loesung gehen koennte er
sich ja einfach was fertig kaufen. Also warum soll er nicht im Rahmen
des Projekts auch noch Linuxkenntnisse auf Gurulevel erwerben? Sowas
schadet nicht. :)
> Also werden die Daten eh zwischengespeichert.
Das werden sie bei Digitalfiltern ja sowieso in irgendeiner Weise.
Stellt sich halt nur die Frage ob man zulassen moechte nur 1Word zu
speichern oder 1s abpielzeit. Im letzteren Falle koennten vermutlich
auch gute Linuxuser sowas hinbekommen.
> Aber gerade für RIAA gibt es nun klare Vorgaben, wie der Filter> auszusehen hat. Was willst Du da für unterschiedliche Kurven haben?
Also jetzt fang hier bitte nicht an logisch und korrekt zu
argumentieren! Wo soll der Sinn von Highend-Hifi sein weil man alles
nach Norm macht? Wenn da Vinci auch noch die ganzen Pickel von Fraeulein
Lisa gemalt haette, waere er ja vielleicht auch nicht so beruehmt
geworden. :-D
Olaf
Dergute W. schrieb:> Ja, stimmt schon; die meiste Zeit wird dabei die CPU vor sich hinidlen.> ABER es ist halt nicht sichergestellt, dass es nicht doch irgendwann mal> zu einem Bufferover/underrun kommen kann, weil gleichzeitig irgendwer> grad' am Display rumdaddelt, auf der SD-Card grad irgendwelche> Operationen laenger dauern, und auf'm USB auch grad irgendwie viel los> ist
Da die Quelle auch ein Probleme mit Overruns und Underruns hat (Sprung
in der Platte) spielt das Rolle.
Stefanus F. schrieb:> Haben denn digitale RIAA Filter signifikante Vorteile gegenüber den> analogen?
man könnte die per SW verändern, IMHO wurden die Schneidkennlinien mal
verändert, ich weiss nur nicht genau wann und bei welchen Platten.
wiki weiss es
https://de.wikipedia.org/wiki/Schneidkennlinie
Die Schneidkennlinie gilt in Deutschland für alle produzierten
Schallplatten. Ausländische Tonträger auf Vinyl besitzen oft andere
Schneidkurven, auf die die Schneidkurvenentzerrer umgeschaltet werden
können (NAB, RIAA: 3180/318/50 µs, BBC: 3180/318/25 µs, FLAT: 3180/319/0
µs). Die verschiedenen Schneidkurven sind nur oberhalb 1 kHz
unterschiedlich.
Joachim B. schrieb:> man könnte die per SW verändern, IMHO wurden die Schneidkennlinien mal> verändert, ich weiss nur nicht genau wann und bei welchen Platten.
Wenn man es nicht raus hört ist es nicht wichtig.
Ulf schrieb:> Wenn man es nicht raus hört ist es nicht wichtig.
das heisst,
wenn du altersbedingt schlechter hörst schmeisst du deine guten LS weg?
So weit würde ich nicht gehen wollen :)
Karl K. schrieb:> Pi und Echtzeit geht sowieso eher nicht. Es sei denn Du willst Dich mit> Echtzeit-Betriebssystemen befassen.
Video und MP3 abspielen sind Echtzeit. Du musst allerdings Echtzeit in
der Unterhaltungsindustrie und Echtzeit bei Safety relevanten Industrie
Automatisierungsanlagen unterscheiden.
Bei der Unterhaltungsindustrie passiert nichts außer einem
Ruckler/Knackser wenn die Echtzeit Bedinungen 1x pro Woche nicht
eingehalten werden, daher ist das normalerweise gut genug.
Michael
Jan schrieb:> Mich würde Eure Meinung interessieren, ist der Raspberry ein guter Weg> sowas zu realisieren oder würdet Ihr das anders lösen?
Ich würde mir kurz überlegen, ob der Grundgedanke sinnvoll ist.
Trenne Eingabe, Verarbeitung und Ausgabe und überlege dir für jeden
Einzelteil, was die Anforderungen und Randbedingungen sind.
Platten nutzen sich bei jedem Abspielvorgang ab, daher wäre es sinnvoll,
die Plattensammlung einmal in maximaler Qualität zu digitalisieren.
Vielleicht auch dreimal, öfter nicht. Das ist tatsächlich ein
Echtzeitvorgang, also ist ein Raspberry dafür schonmal ungeeignet. Er
kann aber die Daten von einem spezialisiertem Controller mit ADC zügig
übernehmen.
Die gesamte Analyse, Nachbearbeitung und sonstige Spielerei ist nicht
zeitkritisch. Ein Raspberry kann das ohne Probleme. Das macht man einmal
und erfreut sich dann jahrelang an der Musik. Oder man macht es alle
paar Monate erneut, mit anderen Parametern und erfreut sich dann an den
regelmäßig auftauchenden Neuerungen.
Sollte der Raspberry im Mittel schnell genug sein, dann kann man das
ganze auch als live aufbauen. Aber es ist dann trotzdem kein
Echtzeitsystem. Ist dein Smartphone mit Youtube drin aber auch nicht.
> Platten nutzen sich bei jedem Abspielvorgang ab, daher wäre es sinnvoll,> die Plattensammlung einmal in maximaler Qualität zu digitalisieren.
Du hast etwas wesentlicher nicht verstanden. Platten sind in fast jeder
Beziehung digitalen Daten unterlegen, sei es als CD oder Plattenkopie.
Allerdings in einem Punkt sind sie besser. In der imaginaeren
Ausstrahlung von Ambiente. Dem andaechtigen knien vor dem
Plattenspieler. Da ist dann ein neuer Kratzer beim abspielen wie das
darbringen eines Opfers vor dem Hifi-Gott.
Deshalb kommt natuerlich nur echtes Abspielen in Betracht! Sonst koennte
man ja auch einmal den Gottesdienst im Koelner Dom filmen und danach die
Bude abreissen und da einen Appleshop mit einer neuen Religion
hinstellen. :-)
Olaf
Olaf schrieb:> Platten sind in fast jeder> Beziehung digitalen Daten unterlegen,
nicht wenn die Digitalisierung mit miesen Masterbändern erzeugt wurde!
Beispiel: "Mensch Maschine Kraftwerk" die CDs waren unbrauchbar!
Olaf schrieb:> Sonst koennte man ja auch einmal den Gottesdienst im Koelner Dom> filmen und danach die Bude abreissen und da einen Appleshop mit> einer neuen Religion hinstellen. :-)
Bitte trenne zwischen dem Bauwerk und dem, was dadrin stattfindet.
Nicht alles ist erhaltenswert. :-)
Müssen wir wirklich über "Echtzeit" diskutieren?
Solange man es nicht deutlich als Verzögerung bemerkt ist es in Ordnung,
es soll sich halt wie die üblichen analogen Systeme anfühlen (Nadel auf
der Platte -> sofort ein Geräusch)
Mein Rechner kann das, mein erstes Smartphone konnte das auch. (EQ im
Audioplayer) Und das war deutlich langsamer als der heutige Raspberry.
Ja, Platten nutzen sich natürlich ab, wenn man sowieso schon
digitalisiert hat kann man wenn man möchte auch gleich nebenher
speichern. Dennoch höre ich gerne Platten, seht es einfach als Hobby.
;-)
>man könnte die per SW verändern, IMHO wurden die Schneidkennlinien mal>verändert, ich weiss nur nicht genau wann und bei welchen Platten.
Ab den 50ern hat man sich an der auch heute noch gängigen RIAA
Schneidekennlinie orientiert, davor gab es deutliche Unterschiede je
nach Label. Viel interessanter ist es Defekte Platten (Höhenschlag,
viele Störgeräusche...) oder Fehler des Tonabnehmers zu kompensieren.
>Du hast etwas wesentlicher nicht verstanden. Platten sind in fast jeder>Beziehung digitalen Daten unterlegen, sei es als CD oder Plattenkopie.>Allerdings in einem Punkt sind sie besser. In der imaginaeren>Ausstrahlung von Ambiente. Dem andaechtigen knien vor dem>Plattenspieler.
Jetzt verstehen wir uns! :-)
Mittlerweile ist es (leider) in vielen Fällen außerdem so das die Platte
anders gemastert wird als die CD. Erstens funktioniert Lautheitskrieg
nicht so gut auf Vinyl, (macht man zu laut fliegt der Tonabnehmer aus
der Rille)
zweitens geht man wohl davon aus das die Leute sich Platten bewusster
anhören und mehr auf Qualität achten.
Beispiel eines deutlich unterschiedlichen masterings CD <-> Vinyl:
http://dr.loudness-war.info/album/list?artist=&album=Rockferry
Zum Thema:
http://pelmazosblog.blogspot.com/2010/07/high-end-mastering.html
Jan schrieb:> Müssen wir wirklich über "Echtzeit" diskutieren?
Wie gesagt, trenne einfach die Systeme. Ein STM32 ist echtzeitfähig für
die Digitalisierung, ein Raspberry leistungsfähig genug für die
Verarbeitung.
Und zur Not entwickelst du die Software auf dem PC und schaust, was
"geht".
Jan schrieb:> Da die Platte technisch bedingt auf ~50dB Dynamik limitiert ist und> moderne ADCs immer besser werden (SNR/Dynamik >120dB) sollte sich ein> sehr guter SNR des Gesamtsystems erreichen lassen.
Dynamik und Rauschabstand sind bei Schallplatten der Faktor, der die
Qualität der Aufnahme und damit der Wiedergabe bestimmt - wenn man mal
verwellte und stark gekratzte Platten herausnimmt. Wenn du also eine
digitalisierte Plattenaufnahme so bearbeiten willst, dass du dann das an
Werten herausbekommtst, von dem du träumst, dann ist Echtzeit eh dahin!
Es gibt im Netz jede Menge Infos zur Digitalisierung von Schallplatten,
z.B. mit Audacity, und ich bezweifle, dass dein Programm auf dem Raspi
auch nur annähernd etwas zustande bringt, was vergleichbar wäre! (Würde
Audacity auf einem Raspi laufen??, dann vielleicht :-)
In den Anfängen der Digitalisierung gabs schon Programme, die eine
Schallplatten- oder Tonbandaufnahme von Knacken, Knistern oder Rauschen
befreien konnten. Die Ergebnisse waren allerdings gruselig! Das mag
heute sicher besser sein, aber ob das Ergebnis das ist, was i c h
wollte, wage ich zu bezweifeln.
Gruß Rainer
S. R. schrieb:> Wie gesagt, trenne einfach die Systeme. Ein STM32 ist echtzeitfähig für> die Digitalisierung, ein Raspberry leistungsfähig genug für die> Verarbeitung.
Wozu??? Der RasPi ist in der Lage Audio per DMA von I2S aufzuzeichnen.
Ob die Daten dann 20ms oder 2000ms im RAM liegen bevor sie entzerrt
werden, ist völlig egal. Hauptsache man findet irgendwann eine
Puffergröße mit der es beim Abspielen keinen Underrun gibt.
2000ms verzögerte Ausgabe ist aber etwas ganz anderes als Echtzeit.
Erzähle mal einem Musiker, dass sein Effekt-pedal "nur" 2000ms einbaut.
Der hustet Dir was.
Wir reden hier von einem Plattenspieler der die Daten liefert. Es gibt
nichts was mit den Audiodaten synchronisiert werden muss. Selbst der
Benutzer weiß beim Auflegen der Nadel nicht genau wie lange es dauert,
bis sie den Anfang des Lieds erreicht.
Echtzeit ist ein dehnbarer Begriff. Auch ein Zugführer der regelmäßig
einen Taster drücken muss damit der Zug nicht von selbst anhält, muss
damit harte Echtzeitanforderungen erfüllen.
Daniel schrieb:> Wir reden hier von einem Plattenspieler der die Daten liefert.
Und wir reden von jemandem, der hören möchte, wenn er die Nadel auf
die Platte setzt. Als Teil des Feelings. Das ist mit "200 ms delay"
nicht drin.
He Leute, eine Schallplatte in Echtzeit zu digitalisieren und die
Bearbeitung der Aufnahme dann in Echtzeit zu machen, sind zwei so
verschiedene Schuhe, wie Mokassins und Pumps.
Stefanus F. schrieb:> Erzähle mal einem Musiker, dass sein Effekt-pedal "nur" 2000ms einbaut.> Der hustet Dir was.
Habe keine Ahnung, was das Effekt-Pedal im konkreten Fall leisten
muß/soll, aber wenn du Samples im µS-Takt einliest und meinetwegen etwas
Multiplizierst oder Addierst, dann ist das ein paar µS später fertig und
es tritt keine hörbare Verzögerung ein... wenn du einen Song von einigen
Minuten aufbrezeln willst, dann kannst du erst anfangen, wenn der ganze
Song "drin" ist! Also nach Minuten.
Gruß Rainer
Nur kann der Raspberry Pi keine kontinuierliche Signalverarbeitung im µs
Bereich. Das ist mit Linux und Windows ohne spezial-Hardware (z.B.
Soundkarte mit DSP) schlicht unmöglich.
Stefanus F. schrieb:> Nur kann der Raspberry Pi keine kontinuierliche Signalverarbeitung im µs> Bereich.
Muss er für Audio auch nicht können. Signal über I2S einlesen bekommt er
hin. Das gesammpelte Signal in einen Buffer schreiben. Dieser Buffer
wird von der Signalverarbeitung gelesen und die Ergebnisse wieder in
einen zweiten Buffer schreiben. Von hier gibt es eine Task, die das dann
in eine Datei schreibt oder per I2S in einen DAC. 3 Threads und fertig.
Einen 4. noch für das GUI.
Da ist je nach Buffergröße natürlich eine Verzögerung im Signal. Aber
ich denke, die ist im 2-stelligen ms Bereich, wenn überhaupt. Man könnte
noch ein Realtime-Linux nutzen damit die Latenzen kleiner werden. Dann
kann man die Buffer kleiner halten und die Verzögerung ist dann auch
kleiner.
Ich fürchte das funktioniert gut :)
S. R. schrieb:> Und wir reden von jemandem, der hören möchte, wenn er die Nadel auf> die Platte setzt.
Lassen wir doch lieber Jan entscheiden wieviel Verzögerung für ihn
erträglich ist.
900ss D. schrieb:> Signal über I2S einlesen bekommt er> hin. Das gesammpelte Signal in einen Buffer schreiben. Dieser Buffer> wird von der Signalverarbeitung gelesen und die Ergebnisse wieder in> einen zweiten Buffer schreiben. Von hier gibt es eine Task, die das dann> in eine Datei schreibt oder per I2S in einen DAC.
Bei ALSA gibt es normalerweise Ringpuffer die beim Aufnehmen per DMA
gefüllt und beim Abspielen per DMA ausgelesen werden. D.h. in der
Applikation reicht ein Thread für die Audioverarbeitung. Man sollte sich
aber bewusst sein, dass die Ringpuffer uncached sind und sampleweiser
Zugriff deshalb nicht performant ist.
Wenn man will, kann man die GUI in einem anderen Thread mit niedrigerer
Priorität abhandeln, aber wirklich notwendig ist es nicht.
> Da ist je nach Buffergröße natürlich eine Verzögerung im Signal. Aber> ich denke, die ist im 2-stelligen ms Bereich, wenn überhaupt. Man könnte> noch ein Realtime-Linux nutzen damit die Latenzen kleiner werden.https://youtu.be/dcupw4Z99Ls
Gähn.... Eine halbe Stunde Video schauen für ein paar Latenzen. ;)
Das Video zeigt wahrscheinlich die Latenzen auf Systemereignisse (IRQ
z.B.). Die meinte ich nicht sondern die Latenz für das Audiosignal vom
Eingang bis Ausgang.
Latenzen auf IRQ z.B. kann man mit einer Suchmaschine finden und ist in
3-4 Minuten informiert.
Der Rest den du beschreibst sind Feinheiten zum Tuning die aber
wahrscheinlich nicht notwendig sind. Und wenn es DMA schon gibt für die
Audiosignale, um so besser. Ich fürchte, der RPi langweilt sich bei dem
Job.
900ss D. schrieb:> Das Video zeigt wahrscheinlich die Latenzen auf Systemereignisse (IRQ> z.B.). Die meinte ich nicht sondern die Latenz für das Audiosignal vom> Eingang bis Ausgang.
Das Video zeigt die Latenz für Ping Pong von UDP Paketen zwischen zwei
Cortex-A53 Systemen mit Preempt RT Patch. Die Daten gehen also hoch bis
in eine Applikation.
Wenn man Wert auf sehr geringe Audiolatenz legt, fragt man mit
snd_pcm_avail ab wo sich die DMA Engine gerade befindet (und verringert
die Anzahl Interrupts durch große Periods, weil man sie nicht mehr
braucht). Oder man nimmt einfach gleich JACK, statt die ALSA API von
Hand anzusprechen.
Daniel schrieb:> Wenn man Wert auf sehr geringe Audiolatenz legt, fragt man mit> snd_pcm_avail ab
Du solltest dich mit dem TO kurzschließen. Der könnte dein Wissen über
das Audio-API sicher gut gebrauchen ;)
Interessant ist es sicher.
OK, dann werde ich es mit de Pi Versuchen. Falls es Probleme mit der
Latenz geben sollte kann ich immernoch um ein (low cost) DSP Chip der
über die GPIO Schnittstelle angesteuert wird erweitern.
Vielen Dank!
Jan schrieb:> Falls es Probleme mit der> Latenz geben sollte
Dann kannst du erst den Kernel neu konfigurieren mit der PREEMPTIV
option. Dadurch reagiert er schon deutlich besser. In der
Kernel-Konfiguration:
1
>Kernel Features
2
-> Preemption Model (<choice> [=y])
Kann man mit cyclictest dann messen, dass es besser wird.
Die Beschreibung der Option:
1
This option reduces the latency of the kernel by making all kernel code (that is not executing in a critical section) preemptible. This allows reaction to interactive events by permitting a low priority process to be preempted involuntarily even if it is in kernel mode executing a system call and would otherwise not be about to reach a natural preemption point. This allows applications to run more 'smoothly' even when the system is under load, at the cost of slightly lower throughput and a slight runtime overhead to kernel code.
2
3
Select this if you are building a kernel for a desktop or embedded system with latency requirements in the milliseconds range.
Wenn das auch nicht reicht, dann gibt es noch den RT-Patch, dadurch wird
es noch besser. Aber ich vermute, du kommst mit dem "normalem" Kernel
hin.
Stefanus F. schrieb:> Jan schrieb:>> Weil ich das in Echtzeit erledigen will>> Dazu ist der Raspberry Pi schon nicht geeignet. Ende im Gelände.
Was sind denn das für Tipps ...
Man wird es nicht glauben, aber Audio ist auch Echtzeit und das schafft
der Pi Problemlos.
Außerdem sollte man nicht glauben, dass das, was von einer Schallplatte
kommt, ebenfalls Audio ist.
Auch mit IIR-Filtern wird der Raspi kein Problem haben - ich hatte mal
einen 7Band IIR Equalizer auf einem STM32F4 laufen und da klappte das
auch ... Und der Clock war nur ein zehntel.
Manchmal hab ich das Gefühl, ihr trollt nur rum ohne sinnvollen Inhalt.
Das bisserl Schallplatte entzerren und nebenbei eine Gui noch bedienen
ist keine Herausforderung für einen Pi.
Mampf F. schrieb:>> Dazu ist der Raspberry Pi schon nicht geeignet. Ende im Gelände.> Was sind denn das für Tipps ...
Warum wird dann schon in zwei Threads so lange diskutiert, ohne
zufriedenstellende Lösung?
Stefanus F. schrieb:> Mampf F. schrieb:>>> Dazu ist der Raspberry Pi schon nicht geeignet. Ende im Gelände.>> Was sind denn das für Tipps ...>> Warum wird dann schon in zwei Threads so lange diskutiert, ohne> zufriedenstellende Lösung?
Vlt habt ihr alle keine Ahnung? :troll-face:
Google spuckte mir bei der suche nach BiQuad IIR RIAA folgende Seite
aus:
https://grrrr.org/2017/07/17/riaa-reproduction-filter/
Der schreibt, er würde einen Raspi verwenden ... So unmöglich wird es
dann wohl nicht sein.
Allerdings hab ich auf der Seite keine weiteren Links geklickt.
Mampf F. schrieb:> Der schreibt, er würde einen Raspi verwenden ... So unmöglich wird es> dann wohl nicht sein.
Mit einer zusätzlichen aktiven Soundkarte - da sind wir schon weit vom
Raspberry Pi Prinzip entfernt. Zum Thema "Echtzeit" sagt das gar nichts
aus. Ich gehe immer noch davon aus, dass der TO die Verarbeitung ohne
hörbare Verzögerung erledigen will.
Zur Erinnerung hier die Anforderung von Jan:
> Solange man es nicht deutlich als Verzögerung bemerkt ist es in Ordnung,> es soll sich halt wie die üblichen analogen Systeme anfühlen
Bevor ich hunderte Stunden darin versenke, das auf einem Computer ans
Laufen zu bringen, der für diese Art Anwendung weder die nötige Hardware
noch das richtige Betriebssystem hat, schaue ich mich lieber nach
geeigneten Geräten um. Es ist ja nicht so, dass es keine gäbe.
Ich gehe ja auch nicht hin und baue einen Trabant so um, das man damit
Baggern kann. Da wäre ein dedizierter Bagger oder ein Unimog sehr viel
besser geeignet.
Dieses Cirrus logic Audio Board kostet übrigens mehr als der Raspberry
Pi. Beide Board zusammen sind erst Recht unsinnig teuer und dann
technisch gesehen immer noch nicht das gelbe vom Ei.
Stefanus F. schrieb:> Mampf F. schrieb:>> Der schreibt, er würde einen Raspi verwenden ... So unmöglich wird es>> dann wohl nicht sein.>> Mit einer zusätzlichen aktiven Soundkarte - da sind wir schon weit vom> Raspberry Pi Prinzip entfernt. Zum Thema "Echtzeit" sagt das gar nichts> aus. Ich gehe immer noch davon aus, dass der TO die Verarbeitung ohne> hörbare Verzögerung erledigen will.
Keine hörbare Verzögerung wäre tatsächlich eine Anforderung, die nicht
einzuhalten ist.
Wenn es Video + Audio wäre, würde ich das ja noch verstehen, dass man
beides im Sync haben will - dann würde man halt das Video entsprechend
verzögern.
Bei einer Schallplatte macht das aber tatsächlich überhaupt keinen Sinn.
Stefanus F. schrieb:> Zur Erinnerung hier die Anforderung von Jan:>> Solange man es nicht deutlich als Verzögerung bemerkt ist es in Ordnung,>> es soll sich halt wie die üblichen analogen Systeme anfühlen
Ahja, "deutliche" Verzögerungen sind imho im Sekundenbereich ... Wenn es
300ms sind, wird sich da niemand daran stören.
> Bevor ich hunderte Stunden darin versenke, das auf einem Computer ans> Laufen zu bringen, der für diese Art Anwendung weder die nötige Hardware> noch das richtige Betriebssystem hat, schaue ich mich lieber nach> geeigneten Geräten um. Es ist ja nicht so, dass es keine gäbe.
Ja kannst du ja machen - niemand sagt, du sollte die Arbeit für den OP
erledigen.
DU würdest ein Gerät kaufen - prima ... Deine Sichtweise jemandem
anderen aufzuoktruieren ist eine Art der Bevormundung.
Vielleicht würde er mit sinnvollen Tipps schon weiter kommen, anstatt
mit "Echtzeit geht nicht. Punkt".
> Ich gehe ja auch nicht hin und baue einen Trabant so um, das man damit> Baggern kann. Da wäre ein dedizierter Bagger oder ein Unimog sehr viel> besser geeignet.
WTF, was ist denn das für ein Vergleich ...
Hast du mit Raspis und/oder DSP-Algorithmen überhaupt schonmal
gearbeitet?
Oder entzieht sich das deinem Verständnis und deshalb ist es böse?
Stefanus F. schrieb:> Mampf F. schrieb:>> Hast du mit Raspis und/oder DSP-Algorithmen überhaupt schonmal>> gearbeitet?>> Ja und Ja
Dann solltest du eigentlich wissen, dass ein biquad iir so gut wie keine
Rechenleistung auf einem Pi braucht - nicht mal in float-Genauigkeit.
Ich lese mir beide Threads nochmal durch - sicherlich gibt es ein
anderes Problem, das ich nicht mitbekommen habe ... An der
Rechenleistung kann es zumindest nicht liegen.
Mampf F. schrieb:>>> Hast du mit Raspis und/oder DSP-Algorithmen überhaupt schonmal>>> gearbeitet?>> Ja und Ja> Dann solltest du eigentlich wissen, dass ein biquad iir so gut wie keine> Rechenleistung auf einem Pi braucht - nicht mal in float-Genauigkeit.
Es geht mir auch überhaupt nicht um die Rechenleistung, sondern darum,
dass der Raspberry Pi wegen seiner ungepufferten Schnittstellen und dem
Betriebssystem nicht imstande ist, analoges Audio ohne Aussetzer
kontinuierlich einzulesen und wieder auszugeben.
Joachim B. schrieb:> Ulf schrieb:>> Wenn man es nicht raus hört ist es nicht wichtig.>> das heisst,> wenn du altersbedingt schlechter hörst schmeisst du deine guten LS weg?
Dann holst Du Dir wieder so ne Nußbaumholz-Musiktruhe wie Dein Großvater
eine hatte, nur diesmal bist Du der Großvater, und der Kreis schließt
sich.
Stefanus F. schrieb:> ohne Aussetzer kontinuierlich einzulesen und wieder auszugeben
Das ist nun wirklich dummes Zeug!
Ich kann ja auch Mp3 streamen von meinem Streamingserver und mit dem RPi
wiedergeben, ohne dass ich Aussetzer habe.
Zugegeben, da ist sicher ein größerer Buffer dazwischen der für Latenz
sorgt.
Es kann vielleicht nicht jeder, aber jemand der von Linux, von
Echtzeitsystemen etwas versteht, bekommt das sicher bin.
Ich denke, für den Raspi ist das eine fast lächerliche Aufgabe. Richtig
aufgesetzt vorausgesetzt.
Überleg mal die Menge an Daten, die pro Sekunde zu verarbeiten sind. Die
Aussetzer bekommt man mit dem richtigen Design auch in den Griff.
Es gibt da das PiSound Board von Blokas, welches einen 24Bit Input sowie
auch Output besitzt und mit max. 192kHz samplen kann
(https://blokas.io/pisound). Zur Software-Entwicklung kann dann PureData
genutzt werden, wobei sich damit Filter ziemlich einfach umsetzen lassen
(https://de.wikipedia.org/wiki/Pure_Data).
Stefanus F. schrieb:> Mampf F. schrieb:>>>> Hast du mit Raspis und/oder DSP-Algorithmen überhaupt schonmal>>>> gearbeitet?>>> Ja und Ja>> Dann solltest du eigentlich wissen, dass ein biquad iir so gut wie keine>> Rechenleistung auf einem Pi braucht - nicht mal in float-Genauigkeit.>> Es geht mir auch überhaupt nicht um die Rechenleistung, sondern darum,> dass der Raspberry Pi wegen seiner ungepufferten Schnittstellen und dem> Betriebssystem nicht imstande ist, analoges Audio ohne Aussetzer> kontinuierlich einzulesen und wieder auszugeben.
Die bcm2835-Library kann I2S mit DMA.
In der Library liest man auch öfters was von einem FIFO.
Also so ganz würde ich nicht ausschließen, dass es nicht funktioniert
... Trotzdem - einen guten Audio-Ausgang bräuchte man trotzdem noch, da
der PWM-DAC wirklich nicht gut ist.
USB-Soundkarte mit Line-In verwenden xD
Meine persönlichen Erkenntnisse zum Thema Raspberry Pi und Low-Latency
Audio:
1) es ist definitiv möglich!
2) Mit Realtime-Linux gehen die Latenzen bis auf 100µs runter
3) Wenn du einen Kern in Linux für deine Audioanwendung reservierst und
alle anderen Prozesse und Interrupts davon runter bekommst, gehört der
Kern deiner Anwendung ganz alleine und sie wird nie "preemted" (vom
Linux-Kernel unterbrochen). Du kannst dann jede Audiosample sofort
bearbeiten wenn sie ankommt und hast fast Null Latenz.
4) Das selbe Ergebnis bekommst du mit asymmetric multiprocessing, d.h.
Linux bekommt nur drei Kerne, den vierten hast du komplett unter
Kontrolle. Das ist dann das Selbe wie ein Drei-Kern-Linux und ein
separater 1,4GHz-Mikrocontroller, die sich einen Speicher teilen. Also
wie alle anderen Lösungen mit externen Mikrocontrollern, nur deutlich
mächtiger und billiger. An so was arbeite ich gerade und hoffe es in den
nächsten Wochen/Monaten als Projekt veröffentliche zu können.
5) die Latenz desdigitalen Systems kann man auf jeden Fall auf so
geringe Werte bekommen, dass die Verzögerung (Group delay) der ADCs und
DACs stärker ins Gewicht fällt.
Zu 2: deinen Kernel mit den PREEMPT_RT-Patches patchen, siehe
https://lemariva.com/blog/2018/07/raspberry-pi-preempt-rt-patching-tutorial-for-kernel-4-14-y
Zu 3: mit "isolcpus" einen oder zwei Kerne für deine
Audioverarbeitungskette reservieren. Das Problem dabei ist ist dass der
Kernel dann zwar keine anderen Prozesse auf deinem Kern laufen lässt die
deine Anwendung unterbrechen, aber manche Soft-Interrupt-Handler,
kworker oder Timer laufen trotzdem noch auf allen Kernen. Kann man sich
ansehen wenn man auf Linux "top" aufmacht und die "last used CPU"
anzeigen lässt ("F" -> zur Zeile "P = Last used CPU" gehen, Leertaste,
"q"). Da zeigt sich dann welche Prozesse trotz isolcpus noch auf deinen
für Audio reservierten Kernen laufen.
Infos wie man die verbleibenden kworker weg bekommt, findest du hier:
https://github.com/raspberrypi/linux/blob/rpi-4.14.y-rt/Documentation/kernel-per-CPU-kthreads.txt
Hier kann PREEMPT_RT oder CONFIG_NO_HZ_FULL helfen, da bin ich mir nicht
sicher. Ein anderer Trick ist, den Kernel mit CONFIG_HOTPLUG_CPU zu
kompilieren, dann im Betrieb eine CPU zu "kill"en und wieder online zu
bringen - angeblich wird sie dann nicht mehr für Kerneltimer etc.
verwendet. Wenns doof läuft musst du händisch am Linux-Scheduler
rumpfuschen :-(
Zu 4: siehe
http://telmomoya.blogspot.com/2016/10/asymmetric-multi-processing-amp-with.html,
da macht das jemand dass er Linux auf drei Kernen und 512MB RAM laufen
lässt, und auf dem vierten Kern und den anderen 512MB RAM läuft ein
6502-Emulator.
zu 5: Die Gruppenlaufzeiten von ADCs und DACs liegt im Bereich 40
Samples bei 48kHz bis hin zu 4,5 Samples bei 192kHz, also zwischen 800us
und 26us - beides Werte die weit unterhalb jeglicher Wahrnehmungsgrenzen
für Echtzeitaudio liegen.
Nachtrag: selbstredend muss man dann eine I2S-Soundkarte verwenden und
nicht eine USB-Soundkarte mit ihren deutlich größeren Puffern und
Latenzen. Ich verwende dazu auch die von Trembel verlinkte Pisound
(meines Wissens die einzige qualitativ hochwertige I2S-Soundkarte fürs
Pi mit einem analogen Eingang.
Nebenbei: das I2S im Pi hat (wimre) ein 16-Sample-FIFO für Eingang und
Ausgang, d.h. wenn man doch mal ein oder zwei Samples hinterherhinkt ist
nix kaputt.
Trembel schrieb:> Es gibt da das PiSound Board von Blokas
Geil, es wird immer teurer. Dieses Board kostet 99 Euro!
Ein richtiges DSP Entwicklungs-Kit ist letztendlich billiger zu haben -
und besser.
Bernd K. schrieb:> Joachim B. schrieb:>> Ulf schrieb:>>> Wenn man es nicht raus hört ist es nicht wichtig.>>>> das heisst,>> wenn du altersbedingt schlechter hörst schmeisst du deine guten LS weg?>> Dann holst Du Dir wieder so ne Nußbaumholz-Musiktruhe wie Dein Großvater> eine hatte, nur diesmal bist Du der Großvater, und der Kreis schließt> sich.
ach du sprichst von dir :)
mein Großvater hatte so eine Truhe nicht.
Stefanus F. schrieb:> Joachim B. schrieb:>> mein Großvater hatte so eine Truhe nicht.>> Dann ist er kein richtiger Großvater :-)
vielleicht deswegen, er hatte 1934 als alleinverdiener Maurer ein Haus
gebaut , drei eigene und 2 aufgenommene vertriebene Kinder durch schwere
Zeiten gebracht und großgezogen. Alle bekamen Essen Unterkunft, Kleidung
und eine Ausbildung.
Ich habe immer noch höchste Hochachtung vor dieser Leistung.
Allerdings steht hinter jedem starken Mann die noch stärkere Frau, meine
Oma die fast rund um die Uhr geschuftet hat im Sommer um Gemüse und Obst
zu ernten einzuwecken damit die Familie über den Winter kommt, sie starb
viel zu früh mit nicht mal 60 Jahren.
Stefanus F. schrieb:> Ein richtiges DSP Entwicklungs-Kit ist letztendlich billiger zu haben -
Bitte um Quelle eines geeigneten DSP-Boards mit gutem Audio ADC / DAC.
> und besser.
Hmmm.... Das ist deine persönliche Meinung ;)
Und auf dem DSP musst du erstmal eine Basis haben, also OS, Treiber z.B.
Macht auch viel Arbeit.
900ss D. schrieb:> Stefanus F. schrieb:>> Ein richtiges DSP Entwicklungs-Kit ist letztendlich billiger zu haben ->> Bitte um Quelle eines geeigneten DSP-Boards mit gutem Audio ADC / DAC.
ich könnte Dir jetzt aktuelle produkte heraus suchen, mit denen habe ich
allerdings keine Erfahrung. kann also nicht sagen, ob sie gut sind.
Den Plunder der Raspbery Pi Zubehör Ecke zu toppen ist allerdings
vermutlich nicht schwer.
> Und auf dem DSP musst du erstmal eine Basis haben, also OS, Treiber z.B.> Macht auch viel Arbeit.
Das sollte bei einem namhaften Entwicklungs-Kit dabei sein (bzw.
downloadbar).
Schau Dir mal dieses an:
https://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/eval-bf706-mini.html
Stefanus F. schrieb:> ich könnte Dir jetzt aktuelle produkte heraus suchen, mit denen habe ich> allerdings keine Erfahrung. kann also nicht sagen, ob sie gut sind.>> Den Plunder der Raspbery Pi Zubehör Ecke zu toppen ist allerdings> vermutlich nicht schwer.
Laber Rhabarber. Zeig mir bitte ein DSP-Board das einen hochwertigen
ADC und DAC onboard hat und <100€ zu bekommen ist, samt Ein- und
Ausgangsbeschaltung. Und der ADAU1761 auf deinem Analog-Devkit ist kein
Vergleich zu einem PCM1804/PCM5102A, von den geforderten 120dB Dynamik
im Eingangspost auch meilenweit entfernt. Klar gibt's für bessere ADCs
und DACs auch Devkits, aber nicht in dem Preisbereich. Aber ich würde
mich wirklich sehr, sehr, sehr gerne vom Gegenteil überzeugen lassen, da
ich in den letzten Jahren trotz intensiver Suche nichts gleichzeitig
high-end und günstiges gefunden habe.
Zusätzlich musst du dein ach-so-tolles billigeres Devkit wie auch immer
mit deinem Pi verheiraten, und dann entweder in einem obskuren
Assemblerdialekt programmieren, grafisch mit SigmaStudio unflexible
Filter zusammenklicken oder sonstwie die Daten ins Pi und zurück
bekommen. Arbeitszeit und zusätzliche Hardware müssen aber weniger wert
sein als die gesparten 30€ gegenüber dem Plug-and-play-"Plunder".
Aber gerne, zeig her was es an besseren Lösungen gibt und ich werde sie
dir gerne abnehmen, weil dann muss ich nämlich nicht selber solch ein
Board entwerfen das meine Probleme mit dem Pisound löst
(Mehrkanalbetrieb). Ansonsten ist das Pisound Preis-Leistungstechnisch
super.
Stefanus F. schrieb:> Den Plunder der Raspbery Pi Zubehör Ecke zu toppen ist allerdings> vermutlich nicht schwer.
"Allerdings vermutlich nicht schwer". Geht's noch unkonkreter
konjunktiver? Klar ist eine selbstgeroutete selbstbestückte SMD-Platine
mit ordentlichem Massekonzept, sauberer getrennter Spannungsversorgung
für Analogteil + Digitalteil, geeigneten ADC-Eingangsfiltern und
-treibern im Einzelteileeinkauf billiger, braucht aber Jahre an
Erfahrung im Analogdesign und Layouting.
Philipp M. schrieb:> Laber Rhabarber. Zeig mir bitte ein DSP-Board das einen hochwertigen> ADC und DAC onboard hat und <100€ zu bekommen ist, samt Ein- und> Ausgangsbeschaltung.> Und der ADAU1761 auf deinem Analog-Devkit ist kein> Vergleich zu einem PCM1804/PCM5102A, von den geforderten 120dB Dynamik> im Eingangspost auch meilenweit entfernt.
Ich habe dieses DSP Board als günstigere und bessere Alternative zu
Raspberry Pi + Cirrus Logic Audio Board genannt. Schlechter als dieses
wird der ADAU1761 Chip wohl nicht sein.
Die 120dB waren im Übrigen keine Anforderung. Wir reden hier von
Schallplatten, schon vergessen?
> Zusätzlich musst du dein ach-so-tolles billigeres Devkit wie auch immer> mit deinem Pi verheiraten
Nein, das war als Standalone Lösung gedacht. Analog Audio rein, filtern,
analog Audio raus. Fertig.
> Arbeitszeit und zusätzliche Hardware müssen aber weniger wert> sein als die gesparten 30€ gegenüber dem Plug-and-play-"Plunder".
Dieser "Plunder" muss nicht nur programmiert werden sondern man muss
auch noch mit einem speziellen Kernel herum fummeln, um die
Echtzeitanforderung zu erfüllen. Da der Jan auch davon noch keinen Plan
hat, muss er sich so oder so intensiv beschäftigen.
> Aber gerne, zeig her was es an besseren Lösungen gibt und ich werde sie> dir gerne abnehmen, weil dann muss ich nämlich nicht selber solch ein> Board entwerfen das meine Probleme mit dem Pisound löst
Bist du Jan oder Philipp M?
Ich versuche gerade dem Jan zu helfen. Mach für dein Projekt bitte einen
eigenen Thread auf, da kannst du dann deine Anforderungen benennen.
> "Allerdings vermutlich nicht schwer". Geht's noch unkonkreter> konjunktiver? Klar ist eine selbstgeroutete selbstbestückte SMD-Platine> mit ordentlichem Massekonzept, sauberer getrennter Spannungsversorgung> für Analogteil + Digitalteil, geeigneten ADC-Eingangsfiltern und> -treibern im Einzelteileeinkauf billiger, braucht aber Jahre an> Erfahrung im Analogdesign und Layouting.
Du kommst ziemlich unglaubwürdig herüber wenn du zuerst den ADAU1761 als
unzureichend hinstellst das er eine 120dB kann, aber im selben Atemzug
das Cirrus Logic Audio Board als Lösung empfiehlst.
Stefanus F. schrieb:> Die 120dB waren im Übrigen keine Anforderung. Wir reden hier von> Schallplatten, schon vergessen?Jan schrieb:> Folgendes Konzept: [...]> -> Einen extrem hochwertigen ADC wie den AK5397 (im Mono-mode> unbewertete 123dB DR, mit A-Bewertungsfilter 130dB) Nach der Entzerrung> hat man immernoch >83dB DR, das schaffen die meisten Phono Vorverstärker> nicht. Die Platten schon garnicht.
Die 120+dB Dynamic range stammen vom OP, nicht von mir. Über die
Sinnhaftigkeit dieser Anforderung für Schallplatten im Speziellen oder
für Audio im Allgemeinen kann man streiten, tun wir hier aber nicht.
Stefanus F. schrieb:> Nein, das war als Standalone Lösung gedacht. Analog Audio rein, filtern,> analog Audio raus. Fertig.
Ja, das ist eine einfache Lösung, die in vielen Fällen auch ausreichen
kann. Von den Zielen "[...]Entzerrung, Steuerung sowie Verwaltung des
Touchscreens mit eigener GUI[...]" ist damit aber nur die Entzerrung
einfach gemacht, Steuerung und User I/O braucht aber mehr
Aufwand/Hardware. Mit einem Pi ist das einfacher, dafür ist Audio nicht
so einfach.
Nebenbei nochmal den Threadtitel: "Raspberry Pi als DSP zur
Schallplatten Entzerrung". Der Op fragt "Mich würde Eure Meinung
interessieren, ist der Raspberry ein guter Weg sowas zu realisieren oder
würdet Ihr das anders lösen?" Ich finde "ja", du "nein", und das ist
völlig in Ordung. Schade finde ich, dass du aber durch Falschaussagen
das Pi runterziehst und halt nicht zwischen Betriebssystem und Hardware
unterscheidest (die Hardware Raspberry Pi/BCM2837 kann das auf jeden
Fall, das Betriebssystem Linux kann das im unveränderten Zustand nur mit
erhöher Latenz).
Stefanus F. schrieb:> Bist du Jan oder Philipp M?> Ich versuche gerade dem Jan zu helfen. Mach für dein Projekt bitte einen> eigenen Thread auf, da kannst du dann deine Anforderungen benennen.> [...]> Du kommst ziemlich unglaubwürdig herüber wenn du zuerst den ADAU1761 als> unzureichend hinstellst das er eine 120dB kann, aber im selben Atemzug> das Cirrus Logic Audio Board als Lösung empfiehlst.
Von welchem Cirrus-Board redest du überhaupt? Das hast du irgendwann
erwähnt, ich finde aber keine Links oder sonstige Hinweise von dir oder
anderen zu "dem Cirrus Logic Audio Board". Du erzählst aber "Ein
richtiges DSP Entwicklungs-Kit ist letztendlich billiger zu haben -
und besser.", und ich nehme dich beim Wort. Wenn es so etwas wirklich
gibt, dann zeig es her! Versteh das aber bitte nicht falsch als
"Anforderung".
Bei genauem Lesen des Threads wirst du merken, dass ich a) keine
Anforderungen stelle, da ich mein Projekt aktuell keine fremde Hilfe
benötigt, und ich b) nie über irgendein Cirrus-Board rede, ich verwende
das Pisound von Blokas. Hier findest du Infos dazu bzgl. Tonqualität und
Latenz: https://blokas.io/pisound/docs/Audio/
Ich weiß dass du in vielen Threads gleichzeitig schreibst und vielen
Fragestellern gute Tipps gibst. Es wäre aber schade wenn du dadurch den
Überblick verlierst und Behauptungen aufstellst die einfach falsch sind.
>Keine hörbare Verzögerung wäre tatsächlich eine Anforderung, die nicht>einzuhalten ist.
Wie groß die Latenz sein darf kann ich nicht einschätzen, >100ms denke
ich würde man aber deutlich bemerken. Mein Windoof PC ist auch nicht
Echtzeitfähig und schafft es schnell genug das ich davon nichts
mitbekomme. Kann natürlich auch sein das ich langsamer als die meisten
anderen bin :-)
Die ADC Chips geben das digitalisierte Audio über I2S weiter, der
Broadcom Chip des Pi hat die entsprechende Schnittstelle. (Eingang und
Ausgang) Beide sind 32Bit/192kHz fähig, das ist insofern wichtig das der
tolle (Ironie, Ti macht das besser!) ADC von AKM die Daten nur in 32Bit
ausgibt. Was Blödsinn ist, er schaft im Bestfall sowieso nur echte
~21Bit. Eine externe Soundkarte mit S/PDIF Wandlung zusätzlich ist nicht
so toll. Und Die Umrechnung 32Bit in 24Bit oder 16Bit + SRC schafft der
Pi sicher auch nebenher.
>Die 120dB waren im Übrigen keine Anforderung. Wir reden hier von>Schallplatten, schon vergessen?
Die 120dB DR stammen wirklich von mir, das Problem ist das man 40dB
Reserve für die Entzerrung braucht. Davon ausgehend das die Platte
gerade so 50dB DR schafft würde ein guter 16Bit ADC reichen, dann aber
schon mit hörbarem Rauschen wenn die Nadel nicht auf der Platte liegt.
Ich möchte mit den hochwertigen analogen System mithalten, es soll
niemand anhand von Rauschen etc. merken das anders als üblich entzerrt
wird.
Jan schrieb:> Mein Windoof PC ist auch nicht Echtzeitfähig und schafft es schnell> genug das ich davon nichts mitbekomme.
Wenn genug Idle-Time da ist, dann kann man auch ohne Garantien
rechtzeitig auf Ereignisse reagieren. Echtzeitfähigkeit ist für den
"worst case" notwendig, nicht für den "average case".
Jan schrieb:> Die ADC Chips geben das digitalisierte Audio über I2S weiter, der> Broadcom Chip des Pi hat die entsprechende Schnittstelle.
Dann nimm die und schaue dir an, wie weit du damit kommst.
Ein Raspberry Pi (oder jedes andere mehr oder weniger vergleichbare
Embedded Board) hat gewisse Eigenschaften, die für deinen Anwendungsfall
ungeeignet sind. Ob sie deine Anwendung aber auf "jeden dritten Neumond
knackst es mal" oder "das ist insgesamt unbenutzbar" reduzieren, kannst
nur du einschätzen - es ist deine Anwendung.
Ich bleibe dabei, dass mit "viel Aufwand digitalisieren" und
"nachträglich in aller Ruhe verarbeiten" (d.h. ohne harte
Echtzeitgarantien) besser wären. Aber das hat nichts mehr mit
"Schallplatte abspielen" zu tun, sondern ist ein vollkommen anderer
Anwendungsfall.
Mach einfach - und bitte berichte.
