Also ich habe mal ein fprintf an der Stelle eingebaut und bei mir kommt es nie zu dieser Stelle.
Bei mir tritt der Underrun immer in "snd_pcm_wait" auf.
Johns
Also ich habe mal ein fprintf an der Stelle eingebaut und bei mir kommt es nie zu dieser Stelle.
Bei mir tritt der Underrun immer in "snd_pcm_wait" auf.
Johns
Dann hast du vermutlich auch keinen Softstart, wenn du nach der Pause weiterspielst, oder?
Ja, habe mich schon gewundert was das Problem sein sollte.
Johns
Probiere es mal mit einer Aufnahme von arteHD, da tritt das bei mir meistens auf. Vielleicht liegt es aber auch am Rechner.
Habe mit ARTE HD Aufnahme getestet. Schnell mehrmals Pause oder langsam. Kein Triggern des Effekts.
Kann an der Version der Alsalib oder Kernel liegen.
Johns
Ich habe Alsa 1.0.28 von opensuse 13.2 und Kernel 4.1.13.
Was hast du?
Wäre nett, wenn jeder, bei dem das auch auftritt, mal seine Versionen angibt.
Kann es sein, daß wir das neue Verhalten nur für AudioPaused brauchen?
Der Patch ist nur für Pause-Play und Sprünge in Aufnahmen gut getestet. Für's Zappen könnte er stören. Das müsste man genauer durchdenken.
Im Alsa Changelog weist anscheinend nichts auf einen hierfür relevaten Fehler hin.
http://www.alsa-project.org/ma….0.28_and_1.0.29_releases
http://www.alsa-project.org/ma…hp/Changes_v1.0.29_v1.1.0
Ein neuer Patch für die Fehlerbehandlung vom recover nach dem underrun in AlsaPlayRingbuffer().
Gelegentlich hat AudioUsedModule→FlushBuffers(); unerwünschte Nebenwirkungen.
Der Unterschied ist, für erfolgreichen recover mit return 0 raus zu gehen statt mit continue.
Das passt dann auch besser zu den Kommentaren.
Ich probiere gerne mit aus, aber jetzt werden die ganzen Patche langsam zuviel. Kann man das irgendwie zusammenfassen, deine und die von johns?
Der Übersicht halber.... damit funzt das Spulen und Springen sehr ordentlich:
0001-soft-start-v3.diff
mutex14.diff
pause_play_fix_v3.diff
Gruß
iNOB
Lieber mutex15.diff:
0001-soft-start-v3.diff
mutex15.diff
pause_play_fix_v3.diff
Ich probiere gerne mit aus, aber jetzt werden die ganzen Patche langsam zuviel. Kann man das irgendwie zusammenfassen, deine und die von johns?
0001-soft-start-v3.diff kommt bald ins GIT. Der ist ungefährlich und verbessert nur.
pause_play_fix_v3.diff ich weiß nicht, ich muß mir nochmal die neuste Version anschauen.
Im Prinzip wird nur ein Sonderfall verändert, der bei mir nicht passiert. Müssten halt noch ein paar probieren und dann sehen wir weiter.
mutex15.diff ist schwierig. Es sind mehrere Threads beteiligt. Es sind Threads vom VDR dabei, da weiß ich nicht wie die auf Verzögerungen reagieren. Insgesamt würde ich eine andere A/V Sync Korrektur, die "weicher" reagiert bevorzugen. Die würde dann bei einem Fehler hier nicht sofort reagieren.
Johns
Eine „weichere“ Lösung hatte ich schon ausprobiert. Der Nachteil der weicheren Lösung ist, dass sie nicht sofort reagieren kann. Sofortige Reaktion ist aber nach mehrmaligem Pause Play und grundsätzlich allem, was den Sync grob stört, wünschenswert.
Die Verzögerungen, deren Konsequenzen man schlecht abschätzen kann, finde ich auch suboptimal.
Andererseits scheinen sie ja bei denen, die getestet haben, gut zu funktionieren.
Wenn man um die Mutexe herum Zeitstempel setzt, sieht man, dass weniger als mit Millisekunden messbar verbraucht wird. Jedenfalls auf meinem Dualcore-Sempron 140.
Man könnte mal auf einem sehr langsamen Rechner testen.
Außer dem ab und an wegbleibendem Ton beim langsamen längeren Spulen und anschließendem Wechsel auf Normalgeschwindigkeit, ist mir nichts Negatives gegenüber der Original-Git-Version aufgefallen. Eventuell muss ich noch etwas am Audio-Puffer im Setup von softhddevice ändern... ? Kann das heute Abend mal testen.
Ja, für Tests ist eine hohe AudioBufferTime angesagt. Auch wenn man sie sonst möglichst niedrig haben will.
Ich habe es eben auf einem Pentium 3 ausprobiert.
Der hat nur DVB-T, ich habe durch die Sender gezappt und HD Aufnahmen von Satellit getestet.
Läuft perfekt.
Rückmeldung auf Arm/Allwinner A20:
Ich habe alle drei Patches angewandt und habe durch die engeren Werte jede Menge dup/drop Paare im Live-Betrieb, was man auch am Bild sieht. Bei Rücksetzen auf 25/55 stellt sich das vorherige (gute) Verhalten ein.
Audiobuffer war glaub ich auf 300, kein Soft-Start.
Pause/Play etc. habe ich (noch) nicht probiert.
Gruß
Andreas
Danke für's Testen. Bedeutet „Bei Rücksetzen auf 25/55“, dass du die 3 Patche drin gelassen hast und nur von -13 … 10 auf -25 … 55 geändert hast?
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!