Happy new year @all!
Neues von der Forschungsgruppe "Syncverlust beim Surfen mit Firefox".
Grundsätzlich ist es so, dass das Phänomen nicht nur beim Firefox auftritt, sondern immer, wenn gerade etwas "Ramba-Zamba" im System ist. Das kann also auch ein ein zäher Programmstart sein. Permanent hohe Taktfrequenzen der CPU verschleiern das Problem nur etwas: Oft merkt man nichts, weil das Timing gerade noch so hinhaut. Das kann aber nicht die Lösung sein und ich sehe obendrein nicht ein, meinen Lappi mit 3,2 GHz laufen zu lassen. Nur wenn ich mal ein Video rendere läuft das Ding im Freilauf. Üblicherweise (auch bei QIRX) werkelt das Teil mit gemütlichen 1,2 GHz und gönnt sich dabei rund 12-15 Watt.
Die originale rtltcp arbeitet mit einer Puffergrösse von 32kB und 15 Puffern in der rtlsdr.dll. Daneben gibt es noch einen Zusatzpuffer (Linked-List), der sich kurzzeitig in 32kB - Schritten füllt, wenn das Senden über TCP blockt. 500 Puffer sind dafür vorgesehen. Alles soweit bekannt.
Für meine "Spielereien" habe ich die CPU auf 1,8 GHz fixiert. Das ist absolut ausreichend - muss fehlerfrei funktionieren!
Gestartet habe ich die rtltcp mit dem Parameter "-vv", damit man den Status der "Linked-List-Buffer" sieht. Im Normalfall sieht das so aus:
ll+, now 1
ll-, now 0
ll+, now 1
ll-, now 0
Es kommt also immer mal zu einer kleinen Reaktion dieser "Linked List", beispielsweise schon beim Vergrössern von Fenstern. Das ist also absolut nicht tragisch.
Um es kurz zu machen: Öffnet oder aktualisiert man eine relativ "schwere" Website (Beispiele: das Nachbarforum, SPON oder lustigerweise besonders heise.de), verliert rtltcp massiv Puffer. Man sieht das sofort im IQ-Data Window von QIRX: Das Nullsymbol "springt weg" - Sync weg. Der ganze Spass beruhigt sich erst, nachdem wieder Ruhe im Firefox eingekehrt ist. (Wenn man die Taktfrequenz erhöht, kann man bei dieser Aktion auch ein IQ-Recording anfertigen. Das ist hinterher fehlerhaft, da Daten fehlen.)
Interessant: Die "Linked List" zuckt dabei kaum an. Der Maximalwert lag bei mir bei 15, oft nur bei 10 oder 7. Mit 32 kB pro Puffer kommt man natürlich nicht weit. Aber wenn die "Linked List" meint, nicht mehr Puffer zu benötigen, dann war das Senden über TCP offenbar nicht das (Haupt-)Problem für den Pufferverlust!
Und so ist es wohl auch. Die 15 Puffer in der rtlsdr.dll werden "überrollt" (neu beschrieben), bevor sie bei System-Stress überhaupt umkopiert werden können. Dann stimmt natürlich gar nix mehr. Ich habe jetzt die originale rtltcp mit 64 Puffern a 128 KB laufen, also
rtl_tcp -b 64 -l 256
und siehe da: Selbst bei 1,2 GHz (!) kommt es nur zu kurzen Tonaussetzern während Firefox "wilder Mann" spielt, der Sync steht! Je höher der "-l" Wert ist, umso unempfindlicher wird das Ganze. Vorsicht - der DAB-Player mag keine Puffer über 384 kB (96ms : Abstand Nullsymbol - TII).
Es gibt aber trotzdem seltene Fälle, bei denen QIRX "aus heiterem Himmel" den Sync verliert. Zwei konnte ich mehr oder weniger dokumentieren, da ich gerade selbst an meiner Version der rtltcp gespielt habe.
In einem Fall verlor QIRX den Sync und beruhigte sich auch nicht wieder. Geistesgegenwärtig habe ich auf IQ-Aufnahme gedrückt und eine Minute lang Bundesmux 1 aufgezeichnet. Dann BuMu 2 nochmals für eine Minute. Ich wollte ja wissen, ob die Daten korrupt sind. Tja, was soll ich sagen: Beide Files liefen nach dem Öffnen im QIRX völlig problemlos.
Im anderen Fall hatte ich gerade eine "Langzeitmessung" wegen der ppm-Genauigkeit gestartet. Nach ca. 360 Sekunden war kurz der Sync weg, obwohl zuvor rein gar nichts passiert ist. Die SNR war top und das Nullsymbol hat sich nicht ein Byte weit bewegt.
BTW: Die Zahl hinter QPC im Bild ist der Fehler von QueryPerfomanceCounter gegenüber dem aktuellen Frequenzfehler des Sticks über das Nullsymbol gemessen. "rtl_test.exe -p" zeigt also immer falsche Werte an.
EDIT:
Ich hab noch einen "Screener", damit man sieht von was ich hier rede. Man achte bei etwa 14 Sekunden auf das IQ-Data Fenster. Da kommt ein kurzes Stück Nullsysmbol "vorbeigeschwommen".
@Regie: Kann evt. *.avi für den Upload freigeschaltet werden?