Universeller Sender für AM, FM, DAB(+), DVB-x, GPS für 20 Euro.

[Recv24]

Vielleicht gehts noch sparsamer so wie in Post #161.

Ich bin da überhaupt nicht sattelfest, aber wenn ich mit den 3 Trägern im Basisband durch Überabtastung und Mischung später das 9 kHz Kanalraster, sagen wir bei 648, 684 und 720 kHz  treffen will, müssen diese Trägerfrequenzen doch schon im Basisband in einem (krummen) Verhältnis zueinander stehen, was ich in den ganzzahligen Multiplikatoren nicht abbilden kann. 
Ich hatte dies dann als Grund interpretiert, daß Semir in #127 die Sampleraten ca. 6-fach zur mittleren Sendefrequenz festgelegt hat. Mit 3-fach (ca. 2,2 MHz) habe ich es auch noch hinbekommen.

Gruß  Micha

[OttoBerger]

aber wenn ich mit den 3 Trägern im Basisband durch Überabtastung und Mischung später das 9 kHz Kanalraster, sagen wir bei 648, 684 und 720 kHz  treffen will, müssen diese Trägerfrequenzen doch schon im Basisband in einem (krummen) Verhältnis zueinander stehen

Das können sie ja auch. Wenn dein Bandausschnitt mit den Seitenbändern (sagen wir 5 kHz) von 643 bis 725 kHz geht, also nur 82 kHz breit ist, kannst du die Berechnung also weit unterhalb von 2.2 MSPS machen ohne das Abtasttheorem zu verletzen und der Trägerabstand bleibt erhalten.

, was ich in den ganzzahligen Multiplikatoren nicht abbilden kann. 

sie müssen nicht ganzzahlig sein,

[Raphael_S]

Hallo,

bei mir klappt es inzwischen auch - ich habe die Bitraten unangetastet gelassen und ffmpeg mit -re noch etwas zügle. Das mit -re habe ich irgendwo gelesen und noch nicht so ganz verstanden was das eigentlich macht. Laut Dokumentation sorgt es dafür, dass der Stream mit seiner nativen Framerate eingelesen wird. Aber warum das sonst nicht passiert, keine Ahnung. Jedenfalls klappt es damit.

Die Option mit der Berechnung auf einer niedrigeren Frequenz und dann hochmultiplizieren funktioniert auch ganz gut. Nur das ich oft eine "Underflow! Skipped 1 buffers" Meldung bekomme. Das wird wohl daher kommen, dass die eingestellte Samplerate des fl2k etwas schwankt oder ich die in GNU nicht genau genug spezifiziert habe. Jedenfalls habe ich dieses Problem sowohl unter Windows als auch unter Ubuntu Mate auf einem Odroid XU4.

Ich werde weiter probieren.

Viele Grüße und vielen Dank für alle Hinweise in diesem Thread!
Raphael

[janosch79]

Hallo, 
da es sich dort leichter teilen lässt, habe ich mal versucht meine Fortschritte in ein GitHub zu packen:

https://github.com/janosch79/fl2k_am_multi_noGUI/

Im Grunde habe ich versucht alle Vorschläge von Otto aufzugreifen:
- Verzicht auf GUI
- Upsampling des RX erst vor der Übertragung.
- Verzicht auf VSC und Einsatz von UDP feeds
- ffmpeg als transcoder und netcat als UDP Server

- Script für die Quellen-Aufbereitung

Getestet nur unter Linux

Da ist natürlich noch viel Luft nach oben... oder unten..   Ist mein erstes GitHub. Also seit gnädig zu mir.

[OttoBerger]

Hallo Janosch,

ich würde das Audio vorerst in einem einzelnen LPF mit Eingangssamplerate filtern, dann über einen Rational Resampler an die Samplerate eines ausreichend großen Basisbandes anpassen. Bei der europäischen Mittelwelle liegt der kleinste Träger auf 531 kHz, du musst sonst und machst es auch mit viel Rechenaufwand ein halbes MHz an nichts erzeugen oder bearbeiten, in jedem Filter, in jedem Signalgenerator, jede Multiplikation, alles macht zusätzlich 1/2 MHz an Frequenzspektrum ohne Nutzen, also selbst fast eine halbe Mittelwellenbreite.
Vgl. Probleme oben auf kleinen oder älteren Systemen. Erst dann das Basisband (Summensignal) in die Endlage verschieben (mit Upsampling).
Die Amplituden würde ich nochmal durchrechnen (Gain 250? , Amplitude >> 1, ...) damit man beim Summensignal nicht über die DAC-Grenzen geht beziehungsweise das dabei kein Clipping entsteht und der Dynamicbereich optimal ausgenutzt wird.

Um auf kleinen Rechnern wie Rasberry noch mehr zu sparen GNU Radio nur einmalig zur Erzeugung des ausführbaren Programms nutzen. Gnu Radio erzeugt im Arbeitsverzeichnis eine py - Datei. Das ist genau das Progamm was läuft wenn man auf den Start-Knopf in GNU Radio drückt. Man kann es wenn es einmalig erzeugt wurde aber ohne GNU Radio Entwicklungsumgebung aufrufen, aus einem Script heraus zum Beispiel. Bei dem ffmpeg Starter würde ich ein passendes Shebang einfügen und dort dann auch das py Programm starten was aus dem Flowgraphen erstellt wurde und zusätzlich auch noch das fl2k Transferprogramm.  Damit braucht man nur noch die URL's der Sender editieren und eine Startdatei aufrufen oder für Standalonelösungen über rc.local oder einem anderen Startmanager des OS starten lassen.

Editierung:

Mit meinem mittelalterlichen Netbook erziele ich das beste Live-Ergebnis nach Janoschs Prinzip so.

UDP-Source -> LPF4.5 (Samplerate 22kHz, Gain=1, no Upscaling) -> Upsampling -> AM Modulation mit 1.024 MSPS* -> Summensignal IF auf 4.096 MSPS -> Verschieben um 500 kHz -> UP 8.092 MSPS -> Scaling auf 0..1 auf 0..127 -> TCP Sink

* max 500 kHz breites Basisband, Trägerbereitstellung nach 9 kHz Raster; Beispiel 58kHz -> 558 kHz, 112kHz -> 612 kHz ...

alles 6x = 6 Stationen in Live-Sendebetrieb mit guter Audioqualität in ffmpeg Zuspielung bei mir noch möglich, ab 7 Stationen "Skipped Buffers".

[OttoBerger]

Editierung:

Mit meinem mittelalterlichen Netbook erziele ich das beste Live-Ergebnis nach Janoschs Prinzip so.

UDP-Source -> LPF4.5 (Samplerate 22kHz, Gain=1, no Upscaling) -> Upsampling -> AM Modulation mit 1.024 MSPS* ->  Summensignal IF  auf 4.096 MSPS -> Verschieben um 500 kHz ->  UP 8.092 MSPS -> Scaling auf 0..1 auf 0..127 -> TCP Sink

* max 500 kHz breites Basisband, Trägerbereitstellung nach 9 kHz Raster; Beispiel 58kHz -> 558 kHz, 112kHz -> 612 kHz ...

alles 6x = 6 Stationen in Live-Sendebetrieb mit guter Audioqualität in ffmpeg Zuspielung bei mir noch möglich, ab 7 Stationen "Skipped Buffers".

+

Hallo,

bei mir klappt es inzwischen auch - ich habe die Bitraten unangetastet gelassen und ffmpeg mit -re noch etwas zügle. Das mit -re habe ich irgendwo gelesen und noch nicht so ganz verstanden was das eigentlich macht. Laut Dokumentation sorgt es dafür, dass der Stream mit seiner nativen Framerate eingelesen wird. Aber warum das sonst nicht passiert, keine Ahnung. Jedenfalls klappt es damit.

=   mit dem -re Parameter bei ffmpeg habe ich im durchgeführten Beispiel eine etwas schlechtere Performance und 6 Live-Kanäle werden kritisch, es reicht eine Mausbewegung um ein Stottern in den Sendungen zu hören, ohne -re geht es flüssig. -re scheint ffmpeg also etwas mehr zu fordern.

[OttoBerger]

^- Laptop war im Batteriebetrieb! Da gibt er nicht Vollgas um länger durchzuhalten. Jetzt mit Netzteil 7 Live-Sender (ohne -re) in Echtzeit kein Problem, ab 8 kritisch.

89-92% Auslastung mit 620 MB Ram unter Lubuntu mit LXQT-Desktop.

@Dem der das auf einem Raspi laufen lassen will > ja und ich sehe noch zwei einfache Optimierungen. Ich habe auch noch nicht ausprobiert ob vlc in aktueller version noch ressourcenschonender transcodieren kann


VIele Grüße
Otto

[OttoBerger]

Ich habe jetzt noch folgende Reduzierung/Optimierung gemacht,

UDP-Source -> LPF4.5 (Samplerate 22kHz, Gain=1, no Upscaling) -> Upsampling -> AM Modulation mit 1.024 MSPS* ->

Da ffmpeg beim Resampling selbst ein LPF nutzt gibt es keinen Grund den Zwischenschritt über 22 kHz in GNU Radio zu gehen und einen LPF in GNU Radio nachzuschalten. Man kann  also direkt mit ffmpeg auf die AM-Sendebandbreite reduzieren. Eine spürbare und relevante Einsparung an CPU und Speicher kann ich hier nicht messen. Bei 22kHz Samplerate bringt eine weitere Reduzierung nicht mehr großartigen Zugewinn. Das mag auf kleineren Systemen relevant sein. Vielleicht. Also auf AM-Sendebandbreite in ffmpeg und dann in GNU Radio nach UDP ein Upsampling auf Modulatorsamplerate.

[janosch79]

Hallo Otto,
ich hab in dem GitHub noch mal nach deinen Vorschlägen nachgebessert.
Das ffmpeg Script ist jetzt besser strukturiert. Eigentlich hab ich auch versucht fl2k_tcp mit zu starten. Das klappt auch, nur beim Beenden mit ctrl-C kackt die Verbindung ab und das Terminal hängt.

Das GRC "am_xmit_multi_noGUI_fl2kUDP2.grc"
File arbeitet jetzt mit einer RF SR von 2.048M.  Zum Schluss wird dann um 4 hochgesampelt und mit 531k gemischt. Die RFs sind jetzt auch mathematisch sortiert. (90khz Abstand). Nur im "Europaband" wird es bei 14 Streams mit 45khz Abstand etwas enger..

Was ich nicht ganz verstanden habe, wie ich durch ffmpeg auf den LPF verzichten kann. 

Die CPU Last bei meinem i5 (6.Gen) ist bei 14 Streams jetzt von 314 auf ~ 221% gesunken. Das ist ja schon mal was...   Ohne die LPFs wirds vielleicht noch besser...

[OttoBerger]

Zum Schluss wird dann um 4 hochgesampelt und mit 531k gemischt.

ungünstig! Mischen ist rechnerisch aufwendiger (mehr Takte nötig) als auffüllen einer Zahlenreihe. Pro Sekunde Millionen von CPU Takten verschenkt.
Besser Operationen tauschen und die aufwendigere Rechnung mit weniger Zahlen pro Sekunde durchführen.

Was ich nicht ganz verstanden habe, wie ich durch ffmpeg auf den LPF verzichten kann. 

Da ffmpeg beim Resampling selbst ein LPF nutzt gibt es keinen Grund den Zwischenschritt über 22 kHz in GNU Radio zu gehen und einen LPF in GNU Radio nachzuschalten. Man kann  also direkt mit ffmpeg auf die AM-Sendebandbreite reduzieren.

Die Internetradiostationen kommen nicht in Mono und 4.5 kHz an, sondern werden erst durch den Resampler von ffmpeg zu Mono und (bei dir) 22 kHz SR resampled.  Dadurch wird das Signal aber vorher auch mit einem Filtermodel auf die neue SR tiefpassgefiltert. 
6dB cutoff Punkt bei 0.97 im Standardmodell.  Also nicht in zwei Schritten auf 22kHz/11kHz und dann auf 22kHz/4.5kHz, sondern direkt in ffmpeg auf AM-Seitenbandbreite 9kHz/4.5kHz resamplen. Die TP können dann in GNU Radio entfallen. Der höhere Interpolationsfaktor (Auffüllen) ist wieder einfacher zu verkraften als die nötigen Multiplikationen im zweiten Filter. Wie geschrieben nur ein bisschen eingespart da die SR sowieso schon so niedrig ist. aber spare in der Zeit, dann hast du in der Not.

[janosch79]

Hab es direkt probiert. Die LPFs an den AF Eingängen gebypassed, die AF Sampling Rate im ffmpg script auf 2048000 (entspricht der RF SR, mit 1024000 schaffe ich ja laut Abtastheorem nur ~500kHz und somit nicht die volle MW Bandbreite).
Nur macht ffmpeg da leider nicht so mit. Die CPU Last sinkt natürlich auf sensationelle 42%, nur wird das Audio ganz schnell und zerhackt in 0,5ms Schnipsel wiederholt...
Laut dieser Stackoverflow Aussage "https://stackoverflow.com/questions/52119489/ffmpeg-limit-audio-sample-rate" ist bei 48kHz ar schulz im Schacht.... Aber ja, ich habs noch nicht verifiziert und auch nicht comitted, weil eben defekt....

[OttoBerger]

Hab es direkt probiert. Die LPFs an den AF Eingängen gebypassed, die AF Sampling Rate im ffmpg script auf 2048000 (entspricht der RF SR, mit 1024000 schaffe ich ja laut Abtastheorem nur ~500kHz und somit nicht die volle MW Bandbreite).
Nur macht ffmpeg da leider nicht so mit.

Das wundert mich nicht, du machst genau das Gegenteil vom vorgeschlagenen in ffmpeg! Audiosamplerate auf 2.048 M für 4.5 kHz Audiobandbreite in der Transcodierung! Also ein Upsampling und kein Downsampling mit LPF auf AM Audiobandbreite. Du bemerkst den Fehler bestimmt selbst. ffmpeg soll doch nur ein gefiltertes Audio mit 4.5 kHz Audiobandbreite an GNU Radio liefern und keine IF/RF Signallage. Anpassen der Samplerate für den Modulator macht GNU Radio das die 48kHz Grenze nicht hat, die LPF fallen dort aber weg, weil man das in ffmpeg schon machen kann.

Bisher dein Konzept, zweimal LPF/Resampling.

Internetradio mit 32/44,1/48 kHz -> 22 kHz (LPF11) -> UDP -> LPF(4.5)[GNU RADIO] -> UPSAMPLING[GNU RADIO] ...

Neu/Ziel nur ein Resampler/Filter

Internetradio mit 32/44,1/48 kHz -> 9 kHz (LPF4.5) -> UDP -> UPSAMPLING[GNU RADIO] ...

Der höhere Interpolationsfaktor (Auffüllen) ist wieder einfacher zu verkraften als die nötigen Multiplikationen im zweiten Filter.

Die Einsparungen sind nach meinen Benchmarkmessungen nur minimal da von 22kHz auf 9 kHz SR und nicht so massiv wie beim Operationstausch im RF Bereich (Upsampling <-> Mischung) wo man leicht mehrere Mio Rechenoperationen einsparen kann (#210)

[OttoBerger]

wenn du an den 22 kHz SR im Audioteil von GNU Radio festhalten willst, weil dein anderes Upscaling vielleicht gut drauf aufbauen kann (weniger krumme Faktoren (Interpolation/Dezimierung), dann kannst du die Tiefpassfilterung nicht nur durch den ffmpeg Resampler machen lassen, sondern direkt als Filter vor jeglicher Änderung einer SR. Du könntest so mit der nativen SR des Internetradiostreams arbeiten oder Eingang von CD mit 44.1 kHz. Die SR bleibt erhalten, die Audiobandbreite kannst du aber für den AM Modulator begrenzen.

https://ffmpeg.org/ffmpeg-filters.html

[janosch79]

Das wundert mich nicht, du machst genau das Gegenteil vom vorgeschlagenen in ffmpeg!

Das hätte von meiner Frau stammen können....    

OK. Ich verstehe glaube ich was ich falsch gemacht habe. Die LPFs habe ich jetzt durch Rational Resampler ersetzt. Ich muss ja irgendwie auf die SR der RF kommen. Aber jetzt habe ich den Effekt, je weiter ich mit der SR im ffmpeg herunter herunter gehe, je mehr bekommt das Audio Schluckauf. Bei 16000 geht es noch, bei 12000 ist es komplett zerhackt, bei 9600 sind es nur noch Fetzen, die sich wiederholen. Die Tonhöhe passt aber, somit auch die Verhältnissrechnung..  Die CPU last sinkt bei <12000 tatsächlich unter 100%.. Aber ohne flüssige Wiedergabe natürlich nutzlos.

Code:

ffmpeg -i "${urls[$i]}" -ar $audio_rate -ac $audio_channels -f f32le -filter:a "volume=${volume[$i]}, lowpass=4800" - | nc -u $localhost_address $((2601 + $i)) &

Also ich halte nicht mit Absicht an 22000 fest, aber da geht es bis jetzt bis jetzt am flüssigten.
Der screenshot zeigt die Situation mit einer Audio SR von 12000:

   

[OttoBerger]

Wenn ffmpeg so bei dir  bestens arbeitet, belasse es! Für einen i5 ist das was man an der Stelle noch gewinnen kann nicht relevant.

Eine Sache habe ich noch. Übersteuern die Amplitudenwerte deines Flowgraphen im Summensignal nicht den DAC? Dein erster Flowgraph aus dem gh hat das bei mir furchtbar gemacht. Da kam nicht sauberes raus.
Ein *0.15 hat  nicht ausgereicht um die Sache einzufangen und um den Datentypenüberlauf und DAC Clipping zu verhinden.  Ich würde hier auch einen Fast Multipy Baustein nehmen https://wiki.gnuradio.org/index.php/Fast_Multiply_Const  weil Note: This block uses VOLK (Vector-Optimized Library of Kernels) to improve execution speed.

grundsätzlich versuche ich Float-Summenwerte immer entweder zwischen 0 und 2 oder -1 und 1 zu halten!
0 bis 2 für eine unsigned Ansteuerung,  -1 bis 1 für eine signed Ansteuerung.
Vorher überschlage ich alle Signalwege und überlege wie weit die ausgesteuert werden sollen.
Danach kann man mit einer einmaligen Skalierung den Wertebereich des DAC optimal ausnutzen.

signed/unsigned Ansteuerung. Kann man bei fl2k auch ändern
https://github.com/tedyapo/osmo-fl2k/blo...file.c#L86
https://github.com/tedyapo/osmo-fl2k/blo...tcp.c#L110
https://github.com/tedyapo/osmo-fl2k/blo...l2k.c#L885

[OttoBerger]

und deshalb war die kleine Codezeile und beispielhafte .grc von Otto wie FFMPEG in Verbindung mit der Linux Netcat Funktion eine Internet Radiostation per UDP mit Hilfe von Netcat an ein GNU Radio Projekt Daten liefern kann sehr hilfreich. Es sind manchmal diese kleinen Hilfestellungen die einen weiter bringen,,,Danke Otto!

Wenn es die kleinen Hilfestellungen wie in Post#191 https://radio-bastler.de/forum/showthrea...#pid271139 sind , ist das folgende vielleicht auch hilfreich.

Oben wird der Weg rein in GNU Radio gezeigt, die Ausgabe ist aber auch sehr flexible. In den bisherigen Flowgraphen wird ein TCP-Sink Block in GNU Radio benutzt um die erzeugte HF zu einem DAC-Transferprogramm zu transportieren. Glücklicherweise bietet das FL2K SDR für TCP ein eigenes Transferprogramm an fl2k_tcp

Aber eigentlich ist das gar nicht nötig, man kann auch das Transferprogramm  fl2k_file benutzen um ein TCP-Sink Block aus- und dann wieder einzulesen.


GNU Radio mit zum Beispiel mehreren AM Sendern wie oben gezeigt, wird gestartet und streamt die erzeugte HF in ein TCP-Sink Block auf Port 25000 (so im Beispiel ausgewählt)

mit dem Kommando

nc 127.0.0.1 25000 | fl2k_file -s 8192000 -

erreiche ich das gleiche wie mit dem Transferprogramm fl2k_tcp.
Anders ausgedrückt, die _tcp Version ist nett, hätte aber für unseren Zweck nicht extra programmiert werden müssen. Es zeigt aber wie flexibel alles um TCP/IP, nc und pipes ist. Programme die für Datei I/O und stdin/out programmiert sind können leicht netzwerktauglich gemacht werden!
Bei komplexeren Sachen kann man die Aufgaben auf mehrere Programme verteilen die entweder fest an bestimmte CPU-Kerne gebunden sind oder die auf verschiedenen Rechnern laufen.
Man kann ein zentrales SDR (Fl2k-Dongle) im Ausstellungraum hinter einem Raspberry fest installiert haben und mit den unterschiedlichen DAC-Kanälen unterschiedliche Frequenzräume abdecken.

Was über was gesendet wird, kann auf einem entferten Programmierrechner mit GNU Radio (oder anderen Umgebungen) berechnet werden und zum entfernten Sender gestreamt werden.
Einmal werden AM Radios versorgt oder UKW, DAB, DSR, ADR dann wird auf einem weiteren DAC Kanal ein PAL oder NTSC Signal für alte Fernseher erzeugt und ausgegeben.

Otto

[OttoBerger]

Bei manchen GNU Radio Blöcken kann man auswählen ob sie als Server oder Client arbeiten. Das habt ihr bestimmt gemerkt, hier TCP Sink

https://wiki.gnuradio.org/index.php/TCP_Sink


Das ist für uns bei den einfachen Sachen egal. nc kann ebenfalls Server oder Client sein https://de.wikipedia.org/wiki/Netcat Hauptsache es trifft immer aufs passende Gegenstück.
Die Verbindungen sind keine Einbahnstraßen. Die Verbindungsdaten IP / Port müssen stimmen zwischen den richtigen Programmteilen, da über die Verbindungen mit unterschiedlichen Sampleraten gestreamt wird.

[Recv24]

Hier mal ein kleiner Zwischenstand zur Installation auf einem Raspberry 4B:
Im ersten Anlauf sollte es auf dem Raspberry Pi OS in der Debian 12 (bookworm) Version sein. Trotz aller Versuche und maximalem Wert für usbfs_memory_mb kam immer wieder die Fehlermeldung beim Test des FL2K, den Speicher zu erhöhen, so daß ich schließlich auf die Version Debian 11 (bullseye) zurückgegangen bin.
Im Raspi OS gibt es ja keinen Bootmanager Grub, hier müssen Kernelparameter über die Datei cmdline.txt übergeben werden. Diese befindet sich im Verzeichnis /boot (bei bookworm: /boot/firmware) und kann mit sudo-Rechten editiert werden. Der Parameter 

Code:

usbcore.usbfs_memory_mb=1000 

kann einfach an den vorhandenen String angehängt werden.
Damit ist erst einmal die grundsätzliche Funktion des FL2K analog zu dem weiter vorn im Thread beschriebenen Vorgehen auf dem Raspi gegeben.
Der Raspi 4B ist ja bekannt für seine empfindliche WLAN-Verbindung, die leicht durch angeschlossene USB 3-Geräte aus dem Takt gebracht werden kann. So auch bei mir, trotz USB-Verlängerungskabel. Außerdem war die CPU-Last selbst im Headless-Betrieb mit nur einem Sender (cvlc-Stream -> UDP -> GnuRadio-py-Script -> TCP -> fl2k_tcp-Treiber) recht hoch. Die Wiedergabe erfolgte daher bis jetzt nur stotternd. Als nächstes werde ich ihn also mal über die LAN-Schnittstelle anbinden und dann weiter berichten.

Gruß Micha

[OttoBerger]

Zur weiteren Motivation für Micha .

RPi3 hat hier bei Nutzern bereits AM und FM Modulation mit GR von mehreren Internetradios störungfrei geschaft und DAB DVB Signale erzeugt und über SDRs gesendet oder ein 30 MHz breites Frequenzband an mehrere Nutzer verteilt. Ganze Mobilfunksysteme wurden damit simuliert. Experimente mit DF und BF mit synchronisierten Rx und Tx gemacht.
Ich bestätige und versichere dir das diese kleinen Rechner das können. Aber es gibt viele Sachen die dabei beachtet werden müssen beginnend von Netzteilauswahl, Kühlung zur Vermeidung von Thermal Throttling, Speichermedium, Ethernetbetrieb beim Streamen, Compilieren der Radioentwicklungsumgebungen mit maximaler Optimierungstufe, minimales OS, festbinden der einzelnen Stufen des Senders an einzelne CPU - Kerne (Unix Befehle dazu einlesen), GPU Unterstützung wo machbar und noch einiges mehr.

Der neue Pi ist schneller als mein oben genutzes Netbook auf dem ich die letzten Versuche gemacht habe, hat auch USB3 dafür hat der Pi doppelt so viele Kerne und bis zu doppelt soviel RAM wie man oben sieht. Der Pi ist aber im Gegensatz zu einem Laptop oder PC ein Bastelrechner was Hardware und oft auch Software angeht  und man muss um volle Leistung für eine Aufgabe abzurufen viel basteln und lesen. Bestes Beispiel die Skalensimulationen im iRadio. War lange nichts für einen Zero, aber mit immer besseren Treibern und angepassten Bibliotheken konnten die kleinen Varianten das zum Schluss des iRadio-Projekt so flüsssig wie vorher nur viel größere Rpis. DAB Empfang war lange Zeit nichts für einen Pi, heute machen das mit angepasster Software ältere Exemplare und sogar unter Android.

Du solltest für deine Arbeit dennoch einen eigenen Thread aufmachen damit Neue die einen Fl2k haben und vor dem Problem der Inbetriebnahme stehen nicht mit Raspberryinternas erschlagen werden welche jetzt zweifellos folgen werden. Die meisten kommen auf einem PC mit einem FL2k in Erstkontakt, manchmal sogar mit Windows drauf.
So wie Semir das macht oder wie die vorgeschlagen Threads unter dem Schnellantwortfenster (Möglicherweise verwandte Themen...) wo DRM, HDRadio, DSR ... mit FL2k-Grafikkarte vorgeschlagen werden ist es gut.  Hier in diesem Thread gehts schon ziemlich durcheinander zu und vieles hat nichts mehr mit FL2k-Sender für 20 Euro zu tun, sondern mit GNU Radio, ffmpeg, vlc Hinweisen. Denn die ganzen Flowgraphen zu AM, DSR die auf eine Datei oder in ein TCP-Sink schreiben sind zwar Anwendungen, aber nicht an FL2k gebunden. Sie funktionieren auf jedem sendetauglichen SDR der sich treiberseitig in ein Betriebssystem einbinden lässt und die Rahmenbedingungen wie Bandbreite erfüllt. Von daher fände ich  eine Trennung in FL2k und SDR Anwendungen sinnvoll. Oben habe ich zwar meine Hinweise gegeben, aber nur weil hier oft Leute hilflos vor einem nicht exklusiven Fl2k-Anwendungsfall standen und fest behauptet haben das ginge gar nicht zu lösen mit der oder der Software.

[Recv24]

Danke für die Motivation und Anregungen, werde ich so machen.  
Gruß Micha