Beiträge von jack-itb

Mein Problem mit den falschen Kanalzuordnungen bei Wechsel zu 5.0 Sound besteht immer noch wenn ich nicht den Workaround einbaue der den Ringbuffer bei Audiokanaländerung komplett neu anlegt. Hast du da noch was rausgefunden? Spricht was dagegen den Buffer einfach neu anzulegen?

Zitat von johns

Die sollte eigentich leer sein. AudioFlushBuffers macht dies, die Audioausgabe läuft im eigenen Thread, deshalb kümmert sich der Thread darum.

Kannst ja in AlsaSetup nach dem flush:

Code

Debug(3, "audio: %dms flush\n", (AudioUsedBytes() * 1000)
            / (!AudioSampleRate + !AudioChannels +
                AudioSampleRate * AudioChannels * AudioBytesProSample));

einbauen.

Johns

Alles anzeigen

0ms
Dann weiss ichs auch nicht. Das komplette Neuanlegen des Buffers hilft aber definitiv...

Zitat von jack-itb

Am Anfang von CodecAudioUpdateFormat? Hilft leider auch nicht.

Vermutlich verschieben sich alle Kanäle. Es fällt eben immer stark beim Center auf, wenn der Kommentar-Ton auf einmal von hinten kommt. Aber müsste das dann nicht auch bei jedem anderen Wechsel (z.B. 2.0->5.1) auftreten wenns an Resten im Buffer liegt?

Es sind wohl doch die Buffer.
Wenn ich die Buffer am Anfang von AlsaSetup neu initialisiere klappts mit 5.0:

if (AlsaRingBuffer) {
RingBufferDel(AlsaRingBuffer);
AlsaRingBuffer = NULL;
}
AlsaRingBuffer = RingBufferNew(48000 * 8 * 2);    // ~1s 8ch 16bit

Zitat von johns

Der Ringbuffer sollte leer sein, das habe ich schon mehrmals überprüft.

Und wenn der noch einen Rest enthält sollten sich alle Kanäle verschieben.
Wenn also alle Kanäle vertaucht sind, dann wäre dies die Ursache.

Einmal mehr AudioSetup? bzw. Alsa arbeitet nur bei 2 -> 6 richtig.

Code

freq = 48000;
    chan = 2;
    if (AudioSetup(&freq, &chan, 0)) {  // set default parameters
        Error(_("audio: can't do initial setup\n"));
    }

Johns

Alles anzeigen

Am Anfang von CodecAudioUpdateFormat? Hilft leider auch nicht.

Vermutlich verschieben sich alle Kanäle. Es fällt eben immer stark beim Center auf, wenn der Kommentar-Ton auf einmal von hinten kommt. Aber müsste das dann nicht auch bei jedem anderen Wechsel (z.B. 2.0->5.1) auftreten wenns an Resten im Buffer liegt?

Zitat von johns

Das ist aber komisch. CodecAudioUpdateFormat -> AudioSetup -> AlsaSetup.

AlsaSetup macht ein close/open, weil ohne dies war HDMI mit Alsa von Anfang an im Arsch.
Vielmehr macht AudioInit/AudioExit auch nicht.
Vielleicht zweimal open/close in AlsaSetup oder ein usleep zwischen close und open, daß Alsa seinen Scheiß auf die Reihe bekommt.

Johns

Zweimal open/close oder ein usleep(1000) helfen nicht. Ich werde bei Gelegenheit nochmal weitertesten. Bleiben ja eigentlich nur noch der Mixer und der Buffer.

Ich nochmal mit meinem Channel-Mapping Problem bei 5.0 Sound.

Ich habe weiter recherchiert und getestet. Dabei rausgekommen ist:
- Über HDMI werden 3/5/7 Kanäle nicht unterstützt. Wenn ich direkt auf hw:0,7 gehe habe ich bei 5.0 Sound keinen Ton und die Ausgabe "audio/alsa: set params error: Das Argument ist ungültig".
- Wenn ich das plug-Alsa-Plugin benutze wird aus 5.0 5.1. Bei speaker-test funktioniert alles. Beim Start vom softhddevice anscheinend auch. Nur beim Umschalten von 2.0 auf 5.0 wechseln die Mappings (immer unterschiedlich: mal passts, mal liegt der Center auf Left-Front, mal auf Left-Rear, ...)
- Wenn ich im CodecAudioUpdateFormat zuerst ein AudioExit() und dann ein AudioInit() ausführe scheint das Mapping in Ordnung zu bleiben. Es verzögert das Umschalten der Tonspur auch nicht spürbar. Falls sich nicht noch ein Speicherleak oder sowas zeigt bleibe ich erstmal dabei. Vielleicht hast du aber auch noch eine bessere Lösung.

Zitat von jack-itb

Was mir allerdings gerade noch aufgefallen ist: Beim betroffenen Kanal liegen laut Log "5 Channels" an. Bei den meisten anderen Sendern mit Surround-Ton liegen 6 Channels an. Dort kann ich den Fehler auch momentan nicht reproduzieren.

Ich habe gerade mal in xine nachgeschaut und dort werden wenn ich das richtig sehe aus 5 Kanälen 6 gemacht. Anscheinend gibt es Probleme mit 5-Kanal Sound in alsa. Nur merkwürdig, dass außer mir niemand Probleme damit hat...

Zitat von johns

Also 2 Kanal wird als 2 Kanal ausgeben und 5.1 Kanal als 6 Kanäle. Damit spielt das Plugin und ffmpeg/libav nicht groß am Ton herum.
Ich könnte mich irgendwo beim Audiodrift verrechnet habe, also kein USE_AUDIO_DRIFT_CORRECTION verwenden.
Den Aufruf "CodecReorderAudioFrame()" ist zweimal drin, rausnehmen.

Hat der Receiver eine Anzeige ob er nun 2 Kanal oder 5.1 erkennt?

Johns

Ich habs jetzt nochmal direkt mit plughw:0,3 getestet: Selbes Ergebnis.
Das Problem ist wie gesagt gar nicht, dass 2-Kanal erkannt wird obwohl 6-Kanal-Ton anliegt oder andersrum. Der Surround-Ton wird vom Plugin und vom Receiver (Anzeige MULTI IN) korrekt erkannt. Allerdings sind eben Kanäle vertauscht. Aus allen Lautsprechern kommt Ton, aber der Ton der eigentlich nur aus Front/Center kommen dürfte kommt auch aus den hinteren Lautsprechern. Und das nur gelegentlich (aber mindestens ca. jedes 5. mal bei den betroffenen Sendern)

Was mir allerdings gerade noch aufgefallen ist: Beim betroffenen Kanal liegen laut Log "5 Channels" an. Bei den meisten anderen Sendern mit Surround-Ton liegen 6 Channels an. Dort kann ich den Fehler auch momentan nicht reproduzieren.

Zitat von johns

Leider sagt er in der Normalen Version nicht, wieviele Kanäle das Plugin ausgibt. Wenn möglich mal eine Version mit -DDEBUG verwenden, dann sieht man im Syslog wieviele Kanäle das Plugin ausgibt.
Es gibt vier mögliche Fehlerquellen Plugin -> Libav/ffmpeg -> Alsa -> Receiver.
Libav/ffmpeg hat größere Probleme beim Umwandeln der Kanäle, je nach Version und ob libav oder ffmpeg gibt es unterschiedliche Ergebnisse.
Gehe mal mit -a plughw:NVidia,7 (oder was du hier brauchst) direkt auf die Hardware. Im Setup SoftHDDevice Downmix einschalten, das sollte immer klappen.
Dann Downmix ausschalten, wenn dies klappt sollte es an libav/ffmpeg oder alsa liegen.

Im Debug sind keine Unterschiede zwischen korrektem und kaputtem Ton zu sehen:

kaputter Ton:

Mar 13 19:41:55 htpc vdr: codec/audio: format change 48000Hz 5 channels
Mar 13 19:41:55 htpc vdr: audio: channels 5 frequency 48000 hz pcm
Mar 13 19:41:55 htpc vdr: audio/alsa: flushing buffers
Mar 13 19:41:55 htpc vdr: audio/alsa: flush state RUNNING
Mar 13 19:41:55 htpc vdr: audio: wait on start condition
Mar 13 19:41:55 htpc vdr: audio/alsa: using device 'default'
Mar 13 19:41:55 htpc vdr: audio/alsa: buffer size 4096 85ms, period size 1024 21ms
Mar 13 19:41:55 htpc vdr: audio/alsa: state PREPARED
Mar 13 19:41:55 htpc vdr: audio/alsa: delay 264ms
Mar 13 19:41:56 htpc vdr: audio/alsa: enqueue state PREPARED
Mar 13 19:41:56 htpc vdr: audio: ----> 544ms start
Mar 13 19:41:59 htpc vdr: codec/audio: drift( -1120)  53ms reset
Mar 13 19:41:59 htpc vdr: codec/audio: drift( -1120)	53866us  1120
Mar 13 19:41:59 htpc vdr: codec/audio: inital delay 569 ms

Anderer Ton-Kanal (2 Kanal)

Mar 13 19:41:59 htpc vdr: codec/audio: format change 48000Hz 2 channels
Mar 13 19:41:59 htpc vdr: audio: channels 2 frequency 48000 hz pcm
Mar 13 19:41:59 htpc vdr: audio/alsa: flushing buffers
Mar 13 19:41:59 htpc vdr: audio/alsa: flush state RUNNING
Mar 13 19:41:59 htpc vdr: audio: wait on start condition
Mar 13 19:41:59 htpc vdr: audio/alsa: using device 'default'
Mar 13 19:42:00 htpc vdr: audio/alsa: buffer size 4096 85ms, period size 1024 21ms
Mar 13 19:42:00 htpc vdr: audio/alsa: state PREPARED
Mar 13 19:42:00 htpc vdr: audio/alsa: delay 264ms
Mar 13 19:42:00 htpc vdr: audio/alsa: enqueue state PREPARED
Mar 13 19:42:00 htpc vdr: audio: ----> 544ms start

Wieder 5.1 - diesmal kommt der Ton aus den richtigen Lautsprechern:

Mar 13 19:42:02 htpc vdr: codec/audio: format change 48000Hz 5 channels
Mar 13 19:42:02 htpc vdr: audio: channels 5 frequency 48000 hz pcm
Mar 13 19:42:02 htpc vdr: audio/alsa: flushing buffers
Mar 13 19:42:02 htpc vdr: audio/alsa: flush state RUNNING
Mar 13 19:42:02 htpc vdr: audio: wait on start condition
Mar 13 19:42:02 htpc vdr: audio/alsa: using device 'default'
Mar 13 19:42:02 htpc vdr: audio/alsa: buffer size 4096 85ms, period size 1024 21ms
Mar 13 19:42:02 htpc vdr: audio/alsa: state PREPARED
Mar 13 19:42:02 htpc vdr: audio/alsa: delay 264ms
Mar 13 19:42:02 htpc vdr: audio/alsa: enqueue state PREPARED
Mar 13 19:42:02 htpc vdr: audio: ----> 544ms start

Wenn ich mich recht erinnere gab es keinen Unterschied ob ich direkt auf das Hardware-Device gehe oder per plug/dmix über Umwege. Aber ich teste das nochmal, sobald die aktuellen Aufnahmen beendet sind und Frau mich lässt

Mit Downmix wird es sicherlich korrekt funktionieren (aber dann habe ich ja keinen Surround-Sound). Meistens klappts ja auch ohne Downmix. Nur manchmal kommt eben der falsche Kanal hinten an.

Läuft das xine-Plugin denn eigentlich nicht mit ffmpeg/libav? Dort scheint das Problem ja nicht aufzutreten.

Zitat von johns

Also über HDMI geht auch 5.1 da ist genug Bandbreite vorhanden, die Frage ist nur wie erkennt der Receiver das es mal 2 Kanal oder 6 Kanal ist.
Irgendwie muß dies ja der Receiver/TV erkennen.

Kennt sich hier jemand aus?

Wenn nicht muß ich mal suchen.

Liegt am Zusammenspiel Plugin und Receiver.

Alles anzeigen

Eigentlich funktioniert die Erkennung. In meinem speziellen Fall möchte ich sowieso jeden Kanal als 6 Kanal PCM an den Receiver schicken. Wenn nur auf zwei Kanälen Ton vorhanden ist kommt der Ton eben nur aus zwei Lautsprechern. Dafür gebe ich in der asound.conf einfach fix 6 Kanäle vor.

Ich habe das jetzt nochmal mit xine gestestet und nicht reproduzieren können. Mit softhddevice habe ich es gerade am einfachsten reproduziert indem ich auf Sky Sport HD bei einem Fussballspiel per Audio-Menü zwischen der ersten (DD 2.0) und der zweiten (DD 5.1) Tonspur hin- und hergeschaltet habe. Nach ein paar mal umschalten kommt auf einmal auf der 5.1-Spur der Kommentar und andere laute Geräusche aus (mindestens?) einem der Rear-Speaker. Beim weiter hin- und herschalten ist der falsche Kanal manchmal vorhanden und manchmal nicht. Im Moment des Umschaltens scheint immer alles in Ordnung zu sein, der falsche Kanal kommt eine knappe Sekunde nach Umschalten.

Tut mir leid dich jetzt mit solch merkwürdigen Phänomenen zu belästigen die anscheinend nur bei mir auftreten. Irgendein Zusammenhang zum softhddevice scheint aber gegeben zu sein. Falls du nichts findest oder keine Zeit dafür hast kann ich auch damit leben doch erstmal weiterhin Passthrough zu benutzen oder notfalls beim "Bug" einfach hin- und herzuschalten bis der Ton passt

Achja: Ich benutze die Version aus dem yavdr-unstable ppa, also vom 5.3. (Sehe gerade, dass nun eine neue Version von heute vorhanden ist. Werde ich auch nochmal testen wenn mein Backup durch ist)

Und bevor ichs vergesse: Vielen Dank für die tolle Arbeit. Die (für mich) übrig gebliebenen Probleme sind schon weitaus kleiner als die mit denen ich vorher mit xine und xinelibout gekämpft habe!

edit: Mit der aktuellen Version von heute dasselbe Problem.

Zitat von johns

Also ich kann nichts finden, was die Ursache ist.
Was ich gemeint habe, das noch alte Daten vom vorherigen Kanal ankommen,
passiert aber der Parser erkennt 2 bzw. 6 Kanal und löscht die Puffer
.
Also du hast 6 Lautsprecher über Analog angeschlossen?
Weil nur darüber funktioniert 6 Kanal ohne Passthrough.
Ansonsten im Setup Downmix anschalten.

Johns

Alles anzeigen

Meine GT520 hängt per HDMI am Denon Receiver mit angeschlossenem 5.1 Set. Passthrough funktioniert wie gesagt problemlos. Die PCM Einstellung funktioniert zu 50% genau so wie sie soll (Alle Lautsprecher empfangen den korrekten Kanal) und zu 50% falsch (Center oder Front-Ton kommt dauerhaft aus einem der Rear-Speaker). Reproduzieren kann ich das indem ich schnell von einem Stereo-Kanal zu einem 5.1 Kanal und zurück schalte. Irgendwann kommt es immer zu dem Problem.

Könnte natürlich sein, dass das Problem überhaupt nicht mit dem Plugin zusammenhängt. Sobald ich Zeit habe und die Familie mir den TV überlässt teste ich das nochmal mit xine. Mit speaker-test konnte ich das Verhalten nicht reproduzieren. Wollte nur mal anfragen ob jemandem das Problem bekannt vorkommt bevor ich da unnötig Zeit ins testen stecke.

Kennt noch jemand das Phänomen, dass bei Nicht-Passthrough manchmal der Ton der Front-Speaker/Center-Speaker bei 5.1-Ton-Kanälen auch aus den Rear-Speakern kommt? Wenn ich immer wieder zwischen einem beliebigen Kanal und einem 5.1-Ton-Kanal hin- und herschalte passiert das mindestens jedes zweite mal. Dabei kommt der Ton mal aus der linken hinteren Box und mal aus der rechten. Ob es der Ton der Front-Speaker oder nur des Centers ist kann ich nicht genau sagen. Auf jeden Fall kommt z.B. der Kommentar beim Fussball auch von hinten. Bei Passthrough gibt es keine Probleme. Ich kann mich nicht erinnern das Problem bei xine/xinelibout schonmal gesehen zu haben. Dort hatte ich aber auch meistens Passthrough eingeschaltet.
Änderungen an der asound.conf haben da keinen Einfluss drauf. Selbst wenn ich direkt auf hw:0,3 gehe tritt das Problem auf.
Mein VDR läuft mit Alsa 1.0.24/Oneiric

Nochmal zum Audio Delay: Bin ich denn der einzige bei dem der Ton bei +0ms völlig asynchron läuft? Bei +50ms gehts ja einigermaßen, aber eben abhängig vom Sender mal besser und mal schlechter. Bei xine war es immer völlig synchron, ohne Einstellung eines Delays.

Zitat von johns

Die 240ms sind die PTS Schwankungen die ffmpeg/libav rauswirft. Die sind normal.
Stell im Setup Menu den Audio Delay wie du brauchst. Solltest du dann bei 0/\ms einen anderen Wert brauchen, kann ich daran die Sender unterscheiden.

Johns

bei +50ms sind momentan merkwürdigerweise SD- und HD-Sender einigermaßen synchron. Verstehe zwar nicht, warum die HD-Sender synchron bleiben, aber wenns funktioniert solls mir auch Recht sein

Hallo,

ich teste auch gerade das Plugin (mit den yavdr Paketen für oneiric) und stelle leider noch starke A/V Sync Probleme fest, allerdings merkwürdigerweise nur bei SD-Sendern und egal ob Passthrough oder PCM.

Die +/- Angaben im Log sehen überall gleich gut aus.

Beispiel SD Sender:
Feb 15 22:42:57 htpc vdr: video: 6:24:01.375 +4 378 240/\ms 13 v-buf

Die 240ms tauchen durchgehend bei allen SD-Sendern auf, bei HD-Sendern ist der Wert immer 0. Liegt da das Problem? Oder ist das normal?

Ja das ist so, wenn das epgsearch den normalen EPG ersetzt und das Verhalten der OK Taste geändert wurde (Info-Taste ist ein Shortcut für EPG+OK-Taste und das führt dann eben zum erneuten Umschalten auf den aktuellen Kanal)
Ich habe das gelöst indem ich epgsearch nicht das normale EPG ersetzen lasse sondern meine "Guide" Taste auf der Fernbedienung als User1 Taste definiert habe und auf die User1-Taste das epgsearch Plugin gelegt habe (per keymacros.conf).

Habs nun nochmal nachgelesen und bin nun der Meinung, dass es keinen Unterschied macht ob ich Passthrough ("Bitstream") oder Surround 5.1 ("PCM") nehme. Der Unterschied liegt nur darin wer die DD/DTS Spur dekodiert. Qualitätsunterschiede kann es dabei nicht geben. Digital bleibt es ja eh bis zum Receiver.

Ah, der DA Wandler! OK, dann ists klar. Danke

edit: Grad nochmal etwas nachgelesen. Der DA-Wandler ist es ja anscheinend doch eher nicht (Signal wird ja weiterhin digital, aber halt unkomprimiert übertragen), dafür aber möglicherweise der entsprechende DD/DTS-Decoder. Die Frage bleibt dann aber ob es Qualitätsunterschiede zwischen verschiedenen Decodern gibt. Normalerweise würde ich ja meinen, dass es nur einen definierten Algorithmus für die Dekodierung geben dürfte.

Wo ist eigentlich der Vorteil von Passthrough gegenüber dem Dekodieren der DD/DTS Spur auf dem PC? Macht es einen klanglichen Unterschied ob ich im xine-Plugin "Passthrough" oder "Surround 5.1" einstelle wenn ich den Ton per HDMI an einen AV-Receiver weiterleite? Funktionieren tut bei mir beides, aber die Passthrough Variante führt zu sporadischen Tonaussetzern. Was wäre der Nachteil an der "Surround 5.1" Einstellung, außer dass im Receiver-Display nicht mehr Dolby/DTS steht?

ok, ich habs nun per rsyslog, at und sudo hinbekommen. Das Script wird zwar drei mal nacheinander ausgeführt aber funktioniert jedenfalls.
Bei den Tests um das Problem zu reproduzieren habe ich dann aber wohl vermutlich den eigentlichen Grund für den Fehler gefunden: Wenn der VDR irgendwie beim suspend hängt, kann der Treiber nicht entladen und nach dem Resume daher auch nicht neu geladen werden. Und genau in dem Fall treten die Fehler auf. Wenns der VDR ist kann ich den vorm Standby ja notfalls nochmal killen, aber was wenn es irgend etwas anderes ist? Reproduzieren kann ich das z.B. indem ich femon laufen lasse während ich in den Standby fahre.