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!
Beitrag #5624241 wurde von einem Moderator gelöscht.
Ich würde sagen alles eine Frage der Filterlänge. Warum aber so viele Relais?
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-stages https://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
Wenn Du einem Audiophilen mit MP3 kommst, wirst Du zwei Sekunden später vom kompletten Magazin einer AK-47 durchsiebt.
Und warum nicht das gesampelte Audio mit z.b. Audacity bearbeiten?
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?
Warum nicht gleich einen CD Player nehmen, wenn du eh das analoge Signal digital verpfuschst?
> 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.
Jan schrieb: > Weil ich das in Echtzeit erledigen will Dazu ist der Raspberry Pi schon nicht geeignet. Ende im Gelände.
> 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.
Jan schrieb: > Nur will ich halt nicht immer den (recht > lauten) PC laufen lassen, alles in einer Box wäre mir lieber. Nutzen sich die Platten nicht bei jedem Abspielen etwas ab? Welchen Vorteil soll dieses "Echtzeit" bringen? Einmal digitalisieren und wunschgemäß bearbeiten und abspeichern. Dann ist "alles in einer Box", der PC muss nicht laufen und man muss nicht mit den unhandlichen Platten herum jonglieren. Und das böse MP3-Format muss auch nicht sein. https://www.amazon.de/FiiO-portabler-Definition-Player-192Khz/dp/B01M1KSUJX/ref=sr_1_1?ie=UTF8&qid=1542456521&sr=8-1&keywords=high+res+audio+player https://www.amazon.de/FiiO-portabler-Definition-Audio-Player/dp/B0743CYBH2/ref=sr_1_3?ie=UTF8&qid=1542456521&sr=8-3&keywords=high+res+audio+player https://www.amazon.de/FiiO-X5-portabler-Definition-Player/dp/B01N9K6CYV/ref=sr_1_11?ie=UTF8&qid=1542456521&sr=8-11&keywords=high+res+audio+player
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 :)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Zur Latenz: Ich würde grob schätzen das alles <10ms egal, unter vielleicht 30ms akzeptabel ist. Ich hatte oben ein Gerät verlinkt das praktisch genau so arbeitet wie ich mir das vorstelle. Es gibt hier Bilder vom offenen Gehäuse wo man den Aufbau gut erkennt: https://www.hifitest.de/images/testbilder/big/transvinyl-tvl1-hifi-sonstiges-41946.jpg Wenn man sich die Aufteilung der Rückseite ansieht stellt man fest das darin auch ein RasPi arbeitet. Ist im Text dazu auch irgendwo beschrieben. Es geht also :) https://www.hifitest.de/images/testbilder/big/transvinyl-tvl1-hifi-sonstiges-41944.jpg
Jan schrieb: > Es geht also :) Hab ich auch wenig bis keine Zweifel dran. 4 Kerne a. 1.2GHz.... Die solltest das schaffen.
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.
:
Bearbeitet durch User
Gerade entdeckt, hier macht auch jemand was mit Audio und möchte niedrige Latenzen. Ist zwar eine andere Anwendung aber Gemeinsamkeiten gibt es. Beitrag "Übergang LInux Consolen-Programm -> Daemon"
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.
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
Mampf F. schrieb: > Hast du mit Raspis und/oder DSP-Algorithmen überhaupt schonmal > gearbeitet? Ja und Ja
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Joachim B. schrieb: > mein Großvater hatte so eine Truhe nicht. Dann ist er kein richtiger Großvater :-)
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.
Philipp M. lass gut sein, wir haben damit begonnen, das Thema zu zerreden, das hilft dem Jan nicht.
>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.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.