Auf einigen Sendern mit 2Kanal Ton (kein AC3) habe ich in den ersten Minuten kleine Audiodrops in Verbindung mit einem Onkyo Receiver. Dieser ist direkt am HDMI des Pi angeschlossen.
Bei einer direkten Verbindung mit einem Panasonic Plasma gibt es keine Drops. Angeschlossen an einem Grundig LCD wiederum dropt es auch.
Im Log mit aktiviertem debug im rpihddevice ist im Moment des Aussetzen nichts zu sehen. Dann habe ich den rpi3 gegen einen rpi2 getauscht ohne erfolg. Über den analogen Ausgang gibt es keine Probleme.
Die Drops sind nach ca. 2 Minuten nach dem Umschalten verschwunden, manchmal schon nach ca. 30s.
Auch nach einer kompletten Neuinstallation von Raspbian, vdr 2.2.0 und rpihddevice 1.0.3 aus dem git es Aussetzer.
Thomas, kann ich evtl. an irgendeiner Schraube am rpihddevice drehen um das in den Griff zu kriegen??
[gelöst]Audiodrops über HDMI mit rpihddevice
-
-
Hallo Asta
Thomas, kann ich evtl. an irgendeiner Schraube am rpihddevice drehen um das in den Griff zu kriegen??
Das Problem, so wie es du beschreibst, kann ich nicht nachvollziehen. Aber ich habe den ähnlichen Effekt bei Radiokanälen, also bei Streams ohne Video. Ich werde mal versuchen dieses Problem zu lösen, vielleicht bringt dir das auch was.
Gruss
Thomas -
Hallo Thomas. Ich habe nochmal das ganze Wochenende getestet und festgestellt das auch 2Kanal AC3 aussetzt. Um irgendwelche Hardwareprobleme auszuschließen habe ich mal Softhddevice installiert. Das läuft komplett ohne Audiodrops.
Vielleicht hängt das irgendwie zusammen: Ich habe über rpihddevice keinen Ton auf dem Sender Euronews mit DVB-S . Mit softhddevice ist Ton vorhanden. -
Kannst du bitte mal folgende Änderung testen:
Diff
Alles anzeigendiff --git a/omx.c b/omx.c index eaba662..aeee988 100644 --- a/omx.c +++ b/omx.c @@ -32,7 +32,7 @@ extern "C" { #include "bcm_host.h" -#define OMX_PRE_ROLL 0 +#define OMX_PRE_ROLL 500 // default: 20x 81920 bytes, now 128x 64k (8M) #define OMX_VIDEO_BUFFERS 128
Das Problem mit Euronews ist wahrscheinlich ein anderes - ich vermute, der Ton funktioniert auch bei Aufnahmen nicht? Kannst du mal den channels.conf-Eintrag posten, oder ein mir eine kurze Aufnahme hochladen?Gruss
Thomas -
Hallo,
Bei Euronews habe ich ebenfalls über HDMI keinen Ton, Analog-Ton funktioniert aber. Dürfte an den x Sprachen in "Mono" liegen, die Euronews sendet, was RPiHDD als 16 Bit PCM weitergibt und das TV-Gerät dann nicht "versteht".
42.
-
Sorry für die späte Antwort. Dein Patch hat leider nichts gebracht. Der Ton setzt immer noch kurz aus.
Hier der channels.conf eintrag für Euronews:CodeEuroNews;Globecast:12226:HC34M2S0:S19.2E:27500:2432=2:2433=deu@3,2434=eng@3,2435=fra@3,2436=ita@3,2437=esl@3,2438=por@3,2439=rus@3,2440=ara@3,2441=tur@3,2442=per@3:0:0:31220:1:1091:0
Eine kurze Aufnahme habe ich per PN gesendet.
-
Sorry für die späte Antwort. Dein Patch hat leider nichts gebracht. Der Ton setzt immer noch kurz aus.
Danke fürs Testen. Hmm, schade... in dem Fall handelt es sich nicht um einen Buffer-Underrun. Vielleicht ist die Clock-Dehnung im Live-Mode schuld, es soll Receiver geben, die da etwas empfindlich reagieren. Kannst du bitte mal versuchen, diese auszuschalten:
Diff
Alles anzeigendiff --git a/omxdevice.c b/omxdevice.c index a1da64f..57336df 100644 --- a/omxdevice.c +++ b/omxdevice.c @@ -634,6 +634,7 @@ bool cOmxDevice::HasIBPTrickSpeed(void) void cOmxDevice::AdjustLiveSpeed(void) { + return; if (m_timer->TimedOut()) { int usedBuffers, usedAudioBuffers, usedVideoBuffers;
Eine kurze Aufnahme habe ich per PN gesendet.
Danke für die Aufnahme - hier sprechen wir vom selben Problem, wie es auch Fourty2 beobachtet. Bei mir funktioniert der Ton über HDMI: Der Audio-Codec ist Mono-MPEG, was weder von meinem Receiver noch vom HDMI-Audiosplitter als Pass-Through akzeptiert wird. Deshalb decodiert das Plugin den Ton mittels ffmpeg und sorgt dafür, dass gleich auf Stereo umgesampled wird:
CodeSep 26 08:15:57 192.168.3.3 vdr[6295]: [6323] rpihddevice: new audio codec: 1ch MPEG Sep 26 08:15:57 192.168.3.3 vdr[6295]: [6323] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
Kannst du bitte mal die Log-Ausgabe bei dir posten?
Gruss
Thomas -
Aussetzer sind leider immer noch da. Hier der Logeintrag für das Umschalten auf Euronews:
Code
Alles anzeigenSep 26 17:32:28 raspiwz vdr: [17128] switching to channel 13 (EuroNews) Sep 26 17:32:28 raspiwz vdr: [17367] device 1 TS buffer thread ended (pid=17128, tid=17367) Sep 26 17:32:28 raspiwz vdr: [17366] buffer stats: 90428 (1%) used Sep 26 17:32:28 raspiwz vdr: [17366] device 1 receiver thread ended (pid=17128, tid=17366) Sep 26 17:32:28 raspiwz vdr: [17412] device 1 receiver thread started (pid=17128, tid=17412, prio=high) Sep 26 17:32:28 raspiwz vdr: [17413] device 1 TS buffer thread started (pid=17128, tid=17413, prio=high) Sep 26 17:32:28 raspiwz vdr: [17403] animator thread thread ended (pid=17128, tid=17403) Sep 26 17:32:28 raspiwz vdr: [17414] animator thread thread started (pid=17128, tid=17414, prio=high) Sep 26 17:32:29 raspiwz vdr: [17142] rpihddevice: new audio codec: 1ch MPEG Sep 26 17:32:29 raspiwz vdr: [17142] rpihddevice: set HDMI audio output format to 1ch PCM, 48.0kHz Sep 26 17:32:29 raspiwz vdr: [17412] rpihddevice: set video codec to MPEG2 Sep 26 17:32:29 raspiwz vdr: [17141] rpihddevice: video stream started 720x576@50i, PAR=64/45 Sep 26 17:32:29 raspiwz vdr: [17141] rpihddevice: display PAR=1,000, setting video render PAR=64/45
-
Aussetzer sind leider immer noch da.
Ok, danke fürs Testen. Verstehe ich dich richtig, dass die Audiodrops ausschliesslich bei der Ausgabe als PCM auftreten? Ich muss da mal ein wenig rechechieren, was hier sonst noch falsch laufen könnte...
Hier der Logeintrag für das Umschalten auf Euronews:
Ok, dein Receiver akzeptiert also 1-Kanal-Ton - ich dachte bis anhin, dass dies gar nicht erlaubt sei. Als Workaround sollte dieser Patch in einem solchen Fall einen Stereo-Upmix erzwingen (ungetestet):
Diff
Alles anzeigendiff --git a/setup.c b/setup.c index 2f84219..1ad488b 100644 --- a/setup.c +++ b/setup.c @@ -235,6 +235,9 @@ bool cRpiSetup::IsAudioFormatSupported(cAudioCodec::eCodec codec, if (codec == cAudioCodec::eMPG || codec == cAudioCodec::eAAC) return false; + if (channels < 2 || channels > 6) + return false; + switch (GetAudioFormat()) { case cAudioFormat::ePassThrough:
Gruss
Thomas -
Die Audiodrops passieren nur wenn ich im Setup des Plugins auf Passtrough stelle. Dann aber bei PCM und bei 2Kanal AC3. Irgendwas bringt den Onkyo Receiver komplett aus dem Tritt. Es geht sogar soweit das ab und zu das komplett Bild ausfällt und der Receiver den HDMI Eingang neu synct. Wie gesagt, mit Softhhdevice und Kodi gibt es diese Probleme nicht. Den letzten Patch teste ich nachher.
Da es, wie es scheint nur bei mir, in der Konstellation Receiver und RPI und Grundig LCD und RPI auftritt mach dir nicht soviel Arbeit. Wäre zwar schön wenn es geht, aber wenn nicht, geht die Welt nicht unter. -
Hallo,
ich teste immer mal wieder im Wohnzimmer mit einen pi2 bzw. pi3 an einem Onkyo Receiver --> SamsungTV. Dabei kommt es oft zu Audiodrops.... Nicht immer, aber so oft, dass es nervt.
Am WE werde ich mal die verschiedenen Patches testen und Logs dazu posten. Warum das nur bei Onkyo Receivern so ist....?
Der pi2/3 direkt am SamsungTV oder PhilipsTV funktioniert dagegen ohne Probleme.Gruß, Uwe
-
Hallo Thomas,
"Mono" Patch funktioniert technisch, läßt sich aber nicht anwenden - im GIT war noch ein Kommentar mehr.
Grüße,
42 -
Warum das nur bei Onkyo Receivern so ist....?
Nun Ja, es ist nicht nur bei Onkyo Receivern so. Bei meinem Grundig LCD setzt auch der Ton aus.
Es scheint aber nicht so viele Leute zu betreffen. -
-
Hallo Miteinander,
Auch bei mir kommen die Audiodrops vor, auch ich hab einen Onkyo Receiver.
Bei ARD HD ist es mir letztens besonders aufgefallen.Keine showstopper aber störend.
Gozar
-
Könnte mal jemand der auch AudioDrops hat diesen Wert in der config.txt testen?
Wobei der Wert zwischen 0 und 175 liegen kann.
Aber zwischen 10 und 40 sollte zum testen ok sein.
Vielleicht gibt's ein Feedback ob die Drops damit zu tun haben.Viele Grüße
Andy
Hallo Andy,habe auch einen Onkyo Receiver und auch diese kurzen Aussetzer.
Ich habe gestern mal jeweils eine Stunde ohne und mit dem Eintrag in der config.txt probiert.
Mit dem Eintrag hatte ich keinen einzigen Aussetzer mehr. Ich werde das mal weiter testen.VG,
Frank -
Leider setzt es bei mir trotzdem aus. Ich habe nur das Gefühl das es mit dem Eintrag weniger wird.
-
Ich möchte dieses Thema für mich als gelöst betrachten. Nach vielen, vielen Versuchen hat sich nun herausgestellt das der Fehler eine Kombination aus 2 Dingen war.
Dieser Wert: "hdmi_clock_change_limit=xx" in der config.txt ist für einige AV-Receiver wichtig um bei Verwendung des omxdevice (Kodi oder rpihddevice) Audiodrops zu vermeiden.
Der Wert scheint abhängig zu sein welchen AV-Receiver man benutzt. Die Kombination von "hdmi_clock_change_limit=20" und :Diff
Alles anzeigendiff --git a/omx.c b/omx.c index eaba662..aeee988 100644 --- a/omx.c +++ b/omx.c @@ -32,7 +32,7 @@ extern "C" { #include "bcm_host.h" -#define OMX_PRE_ROLL 0 +#define OMX_PRE_ROLL 500 // default: 20x 81920 bytes, now 128x 64k (8M) #define OMX_VIDEO_BUFFERS 128
hat letztendlich den Erfolg gebracht.
Wichtig für mich war, diesen Patch:Diff
Alles anzeigendiff --git a/omxdevice.c b/omxdevice.c index a1da64f..57336df 100644 --- a/omxdevice.c +++ b/omxdevice.c @@ -634,6 +634,7 @@ bool cOmxDevice::HasIBPTrickSpeed(void) void cOmxDevice::AdjustLiveSpeed(void) { + return; if (m_timer->TimedOut()) { int usedBuffers, usedAudioBuffers, usedVideoBuffers;
nicht zu verwenden.
Ich habe mal ein bischen mit dem Wert "define OMX_PRE_ROLL" gespielt und bin bei 128 gelandet. Damit sind die Umschaltzeiten gefühlt etwas besser als bei "500".
Vielen Dank an Thomas. Und sorry, dein erster Patch hat letztendlich funktioniert, aber nur in Verbindung mit der Änderung an der config.txt. Deswegen hatte ich es nicht hinbekommen.
Achso: Der patch für Ton bei Euronews funktioniert. Vielleicht gibt es Rückmeldungen der anderen betroffenen. Dann könntest du evtl. die beiden Patches ins git übernehmen. -
Danke für die Rückmeldung. Grundsätzlich gibt es bei der Wiedergabe von Livestreams zwei Probleme: 1) Den Zeitpunkt abzuwarten, bei dem genügend Audio- und Videoframes vorhanden sind um mit der synchronen Wiederhabe zu beginnen und 2) das Nachführen der Wiedergabegeschwindigkeit um Bufferunter- und Überläufe zu verhindern.
Das erste Problem lässt sich mit dem OMX_PRE_ROLL-Wert lösen, indem der Clock x-ms vorgestellt und damit bis zur eigentlichen Wiedergabe gewartet wird. Das geht natürlich zu Lasten der Umschaltgeschwindigkeit, weshalb ich den Wert auf sportlichen 0 belassen und mich auf die Lösung von Problem 2, der Taktnachführung verlassen habe. Diese lässt momentan die Livewiedergabe mit reduzierter Geschwindigkeit anlaufen und sorgt so dafür, dass die Buffer nach und nach gefüllt werden. Leider mit dem Nebeneffekt, dass es scheinbar vereinzelt zu Audiodrops kommen kann.
Ich habe mal ein bischen mit dem Wert "define OMX_PRE_ROLL" gespielt und bin bei 128 gelandet. Damit sind die Umschaltzeiten gefühlt etwas besser als bei "500".
Ungefühlt wohl 372ms schneller.
Ich werde deinen Wert mal als Input nehmen und es so implementieren, dass bei der Live-Wiedergabe der Wert gesetzt und bei Aufnahmen bei Null belassen wird. Denn beim Abspielen von Aufnahmen macht dieser Vorlauf keinen Sinn und verzögert nur den Start der Wiedergabe, so auch z.B. beim Springen.
Gruss
Thomas -
Ich habe den Mode-abhängigen Wert für die Clock-Vorlaufzeit mal implementiert und eingecheckt. Bei Live-TV dauert es nun somit 250ms länger, bis die Wiedergabe anläuft - damit sollten die eingangs beschriebenen Probleme gelöst sein.
Gruss
Thomas
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!