Soft-Start bei softhddevice

  • Anbei ein Überarbeiteter Patch.


    Es wird der Ton nur gestartet wenn, nicht mehr genug Platz im Puffer ist.
    Es dauert bis zu 8s bis auf Radiosendern ein Ton kommt.


    Der Wert sollte groß genug sein, daß es bei Aufnahmen kein Start erfolgt.
    Kann mal jemand mit Aufnahmen auf SSD und schnellen Rechner testen.


    Einer eine Idee wie ich Radiosender im Plugin erkenne?


    Johns

    Files

    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

  • Es scheint mit ffmpeg 2.9 im Griff zu sein.

    Empfiehlst du auf 2.9 umzusteigen?


    Ein paar Ruckler danach solten normal sein.

    Ja schon, aber der Punkt ist, dass es manchmal geht, und manchmal nicht, und ich versuche heraus zu bekommen, was den Unterschied macht.

  • Schneller Ton und schnelles Umschalten bei Radio erreicht man mit angehängtem Patch (fkt. prinzipiell auch ohne den softstart-diff)

    Files

    vdr-2.4.6
    softhddevice,, dbus2vdr, dvd, epgsearch, femon, graphtftng, hbbtv, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.6 ,AsRock J4105, CIne CT-V7 DVB-C

  • Empfiehlst du auf 2.9 umzusteigen?


    Ja schon, aber der Punkt ist, dass es manchmal geht, und manchmal nicht, und ich versuche heraus zu bekommen, was den Unterschied macht.


    Ich wollte über deinen Patch meckern und wollte wissen was der /\ (Delta) Wert ist.
    Und da ist mir aufgefallen, daß mit der aktuellen ffmpeg Version keine Schwankung mehr war. Kann auch schon länger weg sein.
    ffmpeg 2.9 wird noch ein paar Patche an SoftHdDevice brauchen, bevor es funktioniert.


    Ich vermute es liegt an der Threadkommunikation. Mal kommt Start und Stop richtig an, mal nicht.


    Schneller Ton und schnelles Umschalten bei Radio erreicht man mit angehängtem Patch (fkt. prinzipiell auch ohne den softstart-diff)


    Vielen Dank. Es fehlt noch die zweite Stelle, wenn ich es eingebaut habe, kommt es dann so ins GIT.


    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 wollte über deinen Patch meckern und wollte wissen was der /\ (Delta) Wert ist.
    Und da ist mir aufgefallen, daß mit der aktuellen ffmpeg Version keine Schwankung mehr war. Kann auch schon länger weg sein.

    Ich habe ffmpeg 2.7.2 und immer 0/\ms.
    Was ist mit "FIXME: not aligned for ffmpeg" in softhddev.c gemeint? Eben diese Schwankungen oder was anderes?

  • Wie man sieht, ist eine Zeit lang nach dem Start nach der Pause die AudioPts völlig aus der Spur.
    Sie erholen sich erst, nachdem es einen großen Sprung gibt (zwischen den DUPEs und DROPs).

    Mittlerweile habe ich herausgefunden, dass das durch einen langsamen Anstieg und plötzlichen Abfall von RingBufferUsedBytes(AudioRing[AudioRingRead].RingBuffer) verursacht wird.
    Woran könnte das liegen?

  • Der Fehler tritt auf, wenn AlsaPlayRingbuffer() schreiben will, bevor er leer gelaufen ist.
    Dann läuft Video und wird gedoppelt, obwohl Alsa nichts spielt, und die Ringbufferbelegung steigt immer mehr.
    Bis Alsa los läuft, und die Ringbufferbelegung fällt und Video gedropt wird, bis er wieder synchron ist.


    Die Lösung: beim Pausieren den Alsa Buffer leeren.



    Anbei noch alle zusammen.

  • Ich habe ffmpeg 2.7.2 und immer 0/\ms.
    Was ist mit "FIXME: not aligned for ffmpeg" in softhddev.c gemeint? Eben diese Schwankungen oder was anderes?


    ffmpeg braucht für das Dekodieren "aligned" Puffer, mit extra Arbeitsbereich.
    Dies ist hier nicht gegeben.


    Code
    1. void CodecAudioDecode(AudioDecoder * audio_decoder, const AVPacket * avpkt)
    2. {
    3. int16_t buf[(AVCODEC_MAX_AUDIO_FRAME_SIZE * 3) / 4 +
    4. FF_INPUT_BUFFER_PADDING_SIZE] __attribute__ ((aligned(16)));


    Hier wird dann die Daten in buf umkopiert. Dieses kopieren kann man sparen, wenn der Aufrufer die Daten schon richtig übergibt.


    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

  • Der Fehler tritt auf, wenn AlsaPlayRingbuffer() schreiben will, bevor er leer gelaufen ist.
    Dann läuft Video und wird gedoppelt, obwohl Alsa nichts spielt, und die Ringbufferbelegung steigt immer mehr.
    Bis Alsa los läuft, und die Ringbufferbelegung fällt und Video gedropt wird, bis er wieder synchron ist.


    Dies behebt nur den Fehler und nicht die Ursache.


    Beim Pausieren sollte nicht verlohren gehen. Mit dem Flush werden die Tonpuffer gelöscht und es erfolgt eine neu Synchronisation, wie bei Sprüngen.


    Code
    1. AudioPaused


    Wenn ich es richtig sehe, dann fülle ich nur den Kernelpuffer nicht mehr, was noch im Kernel ist wird abgespielt.
    Da gehen auf jedenfall ca. 96ms verloren.
    Es müsste nach einer Pause auf jedenfall "wait underrun error" im Log kommen.


    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 nun die finale Version des Fixes für kein Softstart bei Sprüngen.


    Bei Aufnahmen und bei VDR Geräte die einen eigenen Puffer haben (satip) sollte Bild und Ton sofort loslaufen.
    Sollte der ungewöhnliche Fall auftreten, daß keine Zeitstempel kommen, dann löuft der Ton los bevor der VDR wegen Puffer voll stoppt.
    Bei Radiosendern läuft nun der Ton los, sobald genug gepuffert ist.


    Was mir noch gerade einfällt, was passiert beim Radio Plugin, das ein mpeg abspielt?


    Johns

    Files

    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

  • radioplugin macht keine Probleme, das mpeg kommt jetzt später als der Ton. Mich stört das nicht.

    vdr-2.4.6
    softhddevice,, dbus2vdr, dvd, epgsearch, femon, graphtftng, hbbtv, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.6 ,AsRock J4105, CIne CT-V7 DVB-C

  • Mit dem Flush werden die Tonpuffer gelöscht

    Nur die von Alsa, nicht die von softhddevice.


    und es erfolgt eine neu Synchronisation, wie bei Sprüngen

    Nein.


    Es müsste nach einer Pause auf jedenfall "wait underrun error" im Log kommen.

    Nicht mit dem Fix.


    Dies behebt nur den Fehler und nicht die Ursache.

    Da bin ich mir auch nicht sicher.
    Beim googlen nach dem EPIPE habe ich das als Lösung gefunden.
    Die eigentliche Ursache ist aber, dass vor dem underrun geschrieben wird, statt danach. Fragt sich, ob und wie man das besser lösen kann.

  • Hier noch zwei Logs, einmal wenn es geht und einmal wenn es nicht geht.


    Gut:

    Hier ist der underrun zufälligerweise zuerst, und dann wird in Alsa geschrieben und gut ist.


    Schlecht:

    Hier wird zufälligerweise vor dem Underrrun versucht zu schreiben, das geht schief, Video spielt los, da kein Ton kommt, ist Video vorraus und wird gedoppelt, die Audiopuffer laufen immer voller, bis Alsa sich erholt und zu schreiben beginnt. Mit einem Schlag geht der Audiopuffer auf normal, Audio spielt und Video wird gedropt bis zum Sync.


    Die Frage ist, ob/wie man vor dem Schreibversuch wissen kann, dass der Underrun schon vorbei ist.
    Gibt es da eine Alsa-Abfrage? Dann könnte man den Underrun abwarten und danach schreiben.
    Was für einen Vorteil bringt das aber?


    Ist es überhaupt sinnvoll, den Alsapuffer „aufzuheben“ und ihn nach der Pause weiter zu spielen?
    Zur Zeit spielt Alsa nach einer Pause weiter, bis der Alsapuffer (fast) leer ist. Insofern gibt es beim jetzigen Verhalten nichts aufzuheben.
    Video macht beim Losspielen immer einen Sprung von 60ms/3Frames vorwärts (wieso eigentlich?), stört da ein minimaler Audioverlust?


    Insofern müsste mein Fix, selbst wenn es möglicherweise oder auch nicht eine bessere Lösung gibt, bereits ziemlich nahe dran am Optimum sein.

  • Das mit dem Flush habe ich falsch gelesen.


    Code
    1. AudioUsedModule->FlushBuffers();


    Diese F'unktion flushed wirklich nur die Kernelpuffer. Aber der Aufruf an dieser Stelle, kann problematisch sein.
    AudioPause(); wird aus dem VDR Thread aufgerufen. Es arbeitet aber noch der Audiothread.
    Beim Umschalten wird deshalb über den Ringpuffer mit dem Audiothread kommuniziert.


    Quote


    Ist es überhaupt sinnvoll, den Alsapuffer „aufzuheben“ und ihn nach der Pause weiter zu spielen?
    Zur Zeit spielt Alsa nach einer Pause weiter, bis der Alsapuffer (fast) leer ist. Insofern gibt es beim jetzigen Verhalten nichts aufzuheben.


    Das ist falsch und ein Hack von mir. Wobei etwas ähnliches auch beim Video passiert. Das Video spielt auch noch die gepufferten Frames ab.


    Ich stoppe nur das "Füttern" und nicht das abspielen.


    Quote


    Die Frage ist, ob/wie man vor dem Schreibversuch wissen kann, dass der Underrun schon vorbei ist.
    Gibt es da eine Alsa-Abfrage? Dann könnte man den Underrun abwarten und danach schreiben.
    Was für einen Vorteil bringt das aber?


    Dies scheint der eigentliche Fehler zusein.


    Code
    1. audio/alsa: wrote -32/122354 frames


    Entweder habe ich diesen Fall falsch abgefangen oder es lliegt an 'ALSA.
    Ich danke man kann Underruns auch extra abfragen, aber der Recover in dem Write sollte auch einwandfrei funktionieren.
    Der Recover sollte ein paar ms kosten und nicht den A/V total aus dem Takt bringen.


    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

  • Aber der Aufruf an dieser Stelle, kann problematisch sein.

    Bei meinen Tests hat das tadellos funktioniert. Einmal ist noch Video kurz nachgelaufen.


    aber der Recover in dem Write sollte auch einwandfrei funktionieren.

    Daran habe ich auch schon gedacht.
    Edit: Soweit ich das überblicke, macht dein Code das bereits, und es hilft nicht.
    Edit2: Dass es nicht hilft, liegt soweit ich mich erinnere an Alsa, man müsste vorher drain oder drop machen, da ist flush einfacher.
    Theoretisch könnte man auch Nullen ins Audio füttern.

  • Aber der Aufruf an dieser Stelle, kann problematisch sein.
    AudioPause(); wird aus dem VDR Thread aufgerufen. Es arbeitet aber noch der Audiothread.
    Beim Umschalten wird deshalb über den Ringpuffer mit dem Audiothread kommuniziert.

    Kannst du mal ein Beispiel geben, was genau da bei Pause schief gehen könnte?


    Beim Warten auf den Underrun könnte aber auch etwas schief gehen (z.B. wenn man mehrmals ganz schnell zwischen Pause und Play wechselt).
    Deshalb halte ich den

    Code
    1. AudioUsedModule->FlushBuffers();

    immer noch für die beste Lösung.

  • Es ist schwierig sowas zutesten. Es sind mehrere Threads, der eine Thread schreibt die Tondaten.
    Jetzt flushed du die vom zweiten Thread,


    Sauber aber auch nicht viel besser, wäre ein "volatile" Flag und der AudioThread macht dies.


    Die komplizierte Lösung wäre entweder Locks oder ein zweiter Ringbuffer für Befehle.


    Quote


    Daran habe ich auch schon gedacht.
    Edit: Soweit ich das überblicke, macht dein Code das bereits, und es hilft nicht.
    Edit2: Dass es nicht hilft, liegt soweit ich mich erinnere an Alsa, man müsste vorher drain oder drop machen, da ist flush einfacher.
    Theoretisch könnte man auch Nullen ins Audio füttern.


    Das Problem sollten doch alle Alsaprogramme haben?
    Mal geguckt wie mpv, xine, vlc dieses Problem löst?


    Es passieren ja auch Underruns im normalen Betrieb und da kann man nicht einfach ein Flush machen.


    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

  • Man könnte in AlsaFlushBuffers() SND_PCM_STATE_RUNNING abfragen, würde das helfen?


    Man könnte in AlsaFlushBuffers() falls (AudioPaused == 1) snd_pcm_drain statt snd_pcm_drop machen, dann würde der Alsabuffer aufgehoben.


    Vor AlsaFlushBuffers(); könnte man vorsichtshalber noch einen usleep von ein paar ms machen.


    Ich komme erst in ein paar Tagen wieder dazu, dann probiere ich das mal aus und mache einen neuen Patch.

  • Ich habe es jetzt in AlsaPlayRingbuffer() gefixt. Da war die Fehlerbehandlung vom underrun nicht ganz optimal.
    Der Unterschied ist, auch für erfolgreichen recover mit return -1 raus zu gehen statt mit continue.


    Dem entsprechend könnte man auch diverse Kommentare ändern und AudioPlayHandlerThread() aufräumen.


  • Danke,


    Ich schau es mir an. Es hat hier einen Effekt über mehrere Ebenen.
    audio/alsa: writei underrun error
    Kann es sein, daß wir das neue Verhalten nur für AudioPaused brauchen?


    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