softhddevice: unnötiges dropping / duping frames – die Ursache?!

  • Wenn man den Syncbereich (-25 … 55) in VdpauSyncDecoder() verkleinert, gibt es unnütze dupes und drops.
    Deshalb wurde der ja mal vergrössert.
    Wenn es die nicht gäbe, könnte man besser synchronisieren.


    So sieht das aus:

    Man sieht, das der völlig überflüssige dupe/drop vom kaputten Audio Pts kommt.
    Wieso ist der kaputt?


    Mit mehr debug Ausgaben sieht man, wie die RingBufferWrites das AudioDelay (welches zum RingBufferFüllstand proportional ist) erhöhen, und die alsa: wrote es vermindern.

    Wie kommt die Erhöhung von AudioD(elay) 436 -> 438 zustande???
    Irgendwas läuft da schief, aber was?
    Jedenfalls ist das der Grund für den negativen AudioPtsUnterschied, der den unnötigen dupe verursacht.


    Anbei der Patch, der den debug erzeugt hat.

  • Linux ist nun mal kein Realtime Betriebssystem.


    Es wird an Hand des Kernelpuffers und des Ringpuffers berechnet, welcher Audiozeitstempel gerade ist.
    Beim experimentellen Audiodrift, habe ich versucht noch die Systemzeit mit einzubeziehen.


    Es kommen noch zusätzliche Puffer im Alsa Library dazu, vermutlich auch noch mehrere Threads.


    AlsaGetDelay berechnet dies für Alsalib und Kernel.


    Ich vermute durch Taskwechsel usw. entstehen die Schwankungen.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Ich habe noch mehr debug Ausgaben eingebaut.
    Wenn zum selben Zeitpunkt, zu dem in video diff ausgerechnet wird, in den Ringbuffer hinein geschrieben oder herausgenommen wird, ist diff falsch.
    Beides kommt vor.
    Das ist die Ursache der Fehler.


    Ich kenne mich da nicht aus, liegt das an fehlendem locking?

  • Beim Herausnehmen und Befüllen kann es kurze Sorünge geben.


    Bei AudioEnqueue wird erst in den Ringbuffer geschrieben und dann die PTS aktualisiert.
    Aber es sind immer nur kleine Packete, iirc 32ms.


    Bei AlsaPlayRingbuffer ist ein Packet kurze Zeit im Kernel und im Ringpuffer, es ist wiederum nur kurze Zeit.
    Auch irgendwas im Bereich 20 - 30 ms.


    Wenn dies die Ursache ist, dann müssten es mehr Leute sehen. Ich kann den Fehler nirgents nach vollziehen.


    Edit: Kannst ja mal ein Mutex rumsetzten: AudioRing[AudioRingWrite].PTS ist der Zeitstempel.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • johns wrote:

    Wenn dies die Ursache ist, dann müssten es mehr Leute sehen. Ich kann den Fehler nirgents nach vollziehen.

    Das tritt bei mir auf, wenn ich das Sync-Fenster von -25 … 55 auf 33 … 55 reduziere.


    johns wrote:

    Kannst ja mal ein Mutex rumsetzten: AudioRing[AudioRingWrite].PTS ist der Zeitstempel.

    Ok, probiere ich mal.

  • Anbei ein Patch der Mutexe benutzt. Scheint soweit gut zu funktionieren.
    Etwas merkwürdig, dass ich dass timeout vom snd_pcm_wait raus nehmen musste.
    Auf einem bestimmten verschlüsseltem Sender bekomme ich manchmal einen underrun, das war aber auch schon vor dem Patch so.
    Im Patch sind auch noch der Flush für Pausen und Debug Ausgaben drin.


    Das Schöne ist, dass damit das Sync Fenster auf -13 … 10 reduziert ist.


    Falls es auf irgendwelchen Sendern doch noch zu dupe/drops kommt, müsste man -13 noch absenken auf -14 oder kleiner. Ich habe hauptsächlich auf ÖR HD getestet.


    Beim Zappen macht das keinen grossen Unterschied, für mehrfach Pause Play ist das wichtig.


    -13 ... 10 deswegen, weil dann diff von -10 bis 10 ansteigt, und wieder von -10 ..., die Mitte ist 0, so wie es dem Default AudioDelay entspricht.

  • Wobei laut Standard der A/V Sync von x .. y erlaubt ist. So ein scharfes A/V Sync wird nicht verlangt und ist nicht feststellbar.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • So ein scharfes A/V Sync ... ist nicht feststellbar.

    Das hängt wohl vom Betrachter ab ;) . Xine u.a. syncen noch viel schärfer, und insbesondere nach mehrmaligem Pause Play sieht man den Unterschied auch ohne ihn sehen zu wollen. Die Debugausgaben bestätigen das.


    Jedenfalls auf meinem Rechner. Und ich glaube nicht, dass das am Softwarestand liegt, denn andere Programme haben mit dem Softwarestand keine Probleme.
    Dass auf einem schnellerem Rechner manche der Probleme nicht auftreten, kann ich mir gut vorstellen.

  • Was bewirkt der Patch?


    In AudioEnqueue() wird mit RingBufferWrite() in den Ringbuffer geschrieben, und mit AudioRing[AudioRingWrite].PTS += ... die PTS entsprechend angepaßt.
    Dazwischen passt die PTS nicht, und der lock verhindert, dass sich VdpauSyncDecoder() über AudioGetClock() eine falsche PTS holt.


    In AlsaPlayRingbuffer() wird mit snd_pcm_writei() vom Ringbuffer in den Alsabuffer geschrieben, und mit RingBufferReadAdvance() der Readpointer und damit auch der Füllstand des Ringbuffers angepaßt. Dieser Füllstand wird in AudioGetDelay() ausgewertet, und AudioGetDelay() wiederum in AudioGetClock().
    Zwischen snd_pcm_writei() und RingBufferReadAdvance() passen Readpointer und Füllstand nicht, und der lock verhindert, dass sich VdpauSyncDecoder() über AudioGetClock() eine dadurch verfälschte PTS holt.


    Dasselbe wäre auch in OssPlayRingbuffer() angebracht.


    Eventuell wären zwei mutexe besser, damit sich AudioEnqueue() und AlsaPlayRingbuffer() nicht gegenseitig behindern. Das mache ich, sobald ich wieder Zeit habe.

  • Bei mir läuft das inkl. Patch von johns in Verbindung mit dem satip-plugin + softhddevice schon recht gut. Umschaltzeiten/-verhalten und Spulen (ob schnell oder langsam) ist definitiv besser als ohne die beiden Patche.


    Gruß
    iNOB

  • Jetzt brauchen wir noch eine Lockfreie Lösung.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Beim langsamen Spulen ist mir aufgefallen, dass manchmal der Ton wegbleibt, wenn man auf Normalgeschwindigkeit zurückwechselt. Kurzes Vor- oder Zurück (FB Steuerkreuz L+R) behebt meist das Problem. Eventuell findet sich dafür auch noch eine Lösung :)


    Gruß
    iNOB

  • Ja.


    Mal so rein aus Interesse gefragt: Warum wäre das wichtig?


    Grüße, Peter


    PS: mutex10.diff läuft hier jetzt seit einiger Zeit problemlos

    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein

  • Bis zur Lösung ohne Locking hier noch ein Patch mit zwei separaten Mutexen.
    Der Flush für Pausen ist auch drin. Zusätzlich ein Patch für Debug Ausgaben.

  • Wegen des neuen Patches im anderem Thread (pause_play_fix_v3.diff), hier noch der Patch mit zwei separaten Mutexen ohne Flush.
    Es werden dann pause_play_fix_v3.diff und mutex15.diff angewandt (und eventuell auch debug.2.diff).

  • Auf zwei Sendern bekomme ich mit -13 … 10 drop/dupe, das sind Nickelodeon und Rai (hotbird 13 Grad). Da kommen dann abwechselnd decoder buffer empty, duping frame und dropping frame.
    Mit -25 … 55 geht Nickelodeon ohne drop/dupe, Rai aber immer noch nicht. Da muss auf -35 … 75 erhöht werden, weniger tut es nicht.


    Möglicherweise gibt es eine bessere Lösung, als den Sync Bereich zu erhöhen. Damit wird vielleicht nur das Symptom kuriert.
    Was ist die eigentliche Ursache für den leeren Decoder? Hat jemand eine Idee?

  • Es gibt zwei verschiedene Fälle von dropping / duping frames, beim Ersten ist diff nicht im Syncbereich, beim Zweiten ist der decoder buffer leer.


    Die Ursache für den Ersten wird durch den mutex Patch behoben, die Ursache für den Zweiten ist noch unbekannt.


    Da der mutex Patch, wenn man den Syncbereich unverändert läßt, bei rell sogar auf Allwiner sunxi funktioniert (und bei mir auf Pentium 3), ist er meiner Meinung nach reif für die Übernahme in git.


    Nächste Woche mache ich einen entsprechenden Patch.

  • AudioBufferTime sorgt nicht nur dafür, dass genug Audio gepuffert wird, so dass Audio keine Aussetzer hat. Da Video erst los läuft, wenn Audio gestartet ist, sorgt AudioBufferTime auch indirekt dafür, dass der Decoder Buffer nicht leer wird.
    Oder anders herum, Decoder Buffer underruns wird man durch heraufsetzen von AudioBufferTime los. Dadurch sind die „decoder buffer empty“ auf Nickelodeon und Rai jetzt bei mir weg (mit -13 … 10).


    Interessant, dass man das Syncfenster zum Kompensieren von anderen Fehlern „mißbrauchen“ kann.


    Solange mir keiner einen Log mit Fehlern durch den Mutex Patch, die nicht durch zu kleine AudioBufferTime entstanden sind, zeigt, ist für mich bezüglich des Mutex Patches hier fertig :) .