[gelöst]Audiodrops über HDMI mit rpihddevice

Hallo Asta

Zitat von 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

Kannst du bitte mal folgende Änderung testen:

diff --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.

Zitat von Asta

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 --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;

Zitat von Asta

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:

Sep 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

Zitat von Asta

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...

Zitat von Asta

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 --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

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

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

Zitat von Asta

Könnte mal jemand der auch AudioDrops hat diesen Wert in der config.txt testen?

Code

hdmi_clock_change_limit=10

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

Alles anzeigen

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

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.

Zitat von Asta

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