Forum: Mikrocontroller und Digitale Elektronik Raspberry Pi als DSP zur Schallplatten Entzerrung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.
von Daniel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich würde sagen alles eine Frage der Filterlänge.

Warum aber so viele Relais?

von Wolfgang (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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?

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
-2 lesenswert
nicht lesenswert
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ß.

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jan (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
>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.

von Jan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>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?

von georg (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
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

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
3 lesenswert
nicht lesenswert
Wenn Du einem Audiophilen mit MP3 kommst, wirst Du zwei Sekunden später
vom kompletten Magazin einer AK-47 durchsiebt.

von Auder (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Und warum nicht das gesampelte Audio mit z.b. Audacity bearbeiten?

von Dergute W. (derguteweka)


Bewertung
1 lesenswert
nicht lesenswert
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

von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
Haben denn digitale RIAA Filter signifikante Vorteile gegenüber den 
analogen?

von Mein Senf (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Warum nicht gleich einen CD Player nehmen, wenn du eh das analoge Signal 
digital verpfuschst?

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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

von Jan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>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.

von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
Jan schrieb:
> Weil ich das in Echtzeit erledigen will

Dazu ist der Raspberry Pi schon nicht geeignet. Ende im Gelände.

: Bearbeitet durch User
von Olaf (Gast)


Bewertung
1 lesenswert
nicht lesenswert
> 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

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Karl K. (karl2go)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Echte Zeit (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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.

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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

von Echte Zeit (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von John (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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

von Ulf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von Michael D. (nospam2000)


Bewertung
1 lesenswert
nicht lesenswert
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

von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Olaf (Gast)


Bewertung
1 lesenswert
nicht lesenswert
> 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

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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!

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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. :-)

von Jan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>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

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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".

von Rainer V. (a_zip)


Bewertung
0 lesenswert
nicht lesenswert
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

von Daniel (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Daniel (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rainer V. (a_zip)


Bewertung
0 lesenswert
nicht lesenswert
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

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von 900ss D. (900ss)


Bewertung
0 lesenswert
nicht lesenswert
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
von Daniel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von 900ss D. (900ss)


Bewertung
0 lesenswert
nicht lesenswert
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
von Daniel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von 900ss D. (900ss)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von 900ss D. (900ss)


Bewertung
0 lesenswert
nicht lesenswert
Jan schrieb:
> Es geht also :)

Hab ich auch wenig bis keine Zweifel dran.
4 Kerne a. 1.2GHz....  Die solltest das schaffen.

von Jan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!

von 900ss D. (900ss)


Bewertung
0 lesenswert
nicht lesenswert
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
von 900ss D. (900ss)


Bewertung
0 lesenswert
nicht lesenswert
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"

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
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?

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Hast du mit Raspis und/oder DSP-Algorithmen überhaupt schonmal
> gearbeitet?

Ja und Ja

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von 900ss D. (900ss)


Bewertung
0 lesenswert
nicht lesenswert
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
von Trembel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

von Phil E. (aktiver_mitleser)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Phil E. (aktiver_mitleser)


Bewertung
0 lesenswert
nicht lesenswert
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
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> mein Großvater hatte so eine Truhe nicht.

Dann ist er kein richtiger Großvater :-)

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von 900ss D. (900ss)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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

von Phil E. (aktiver_mitleser)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Phil E. (aktiver_mitleser)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Philipp M. lass gut sein, wir haben damit begonnen, das Thema zu 
zerreden, das hilft dem Jan nicht.

von Jan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.