softhddevice - Software VDPAU/VA-API/CPU Decoder und Ausgabe Plugin

Zitat von johns

Alsa Version. Ich denke im Moment ist mal wieder jede Version <1.0.24 Schrott.

sind die standardpakete von [siehe sig]

alsa-base                        	1.0.22.1+dfsg-0ubuntu3                            	ALSA driver configuration files
alsa-utils                       	1.0.22-0ubuntu5                                   	ALSA utilities

ich bin zurück auf "Revision b2cab005: Remove AVDictionary." - die läuft hier sehr sauber (alsa "default"/keine plug audio-startoptionen/direkt zum TV analog/cinch/ac3-downmix)

mit

CONFIG := -DDEBUG
CONFIG += -DAV_INFO -DAV_INFO_TIME=3000 # debug a/v sync
#CONFIG += -DHAVE_PTHREAD_NAME      	# supports new pthread_setname_np
CONFIG += -DUSE_TS_AUDIO            	# build new ts audio parser
CONFIG += $(shell pkg-config --exists vdpau && echo "-DUSE_VDPAU")
#CONFIG += $(shell pkg-config --exists libva && echo "-DUSE_VAAPI")
CONFIG += $(shell pkg-config --exists alsa && echo "-DUSE_ALSA")
#CONFIG += -DUSE_OSS

ciax

johns

jetzt läuft was ganz komisch. wenn ich nun das böse plugin wieder hinter deins stelle was wohl intern ein "wakeup" auslöst, also das szenario was ich letztens beschrieben habe, dann dann startet das frontend in schwarz. hätte jetzt nicht auch ein parameter geben müssen indem man das plugin nun DETACHED startet statt suspended? oder habe ich das nun ganz falsch verstanden.

Zitat von traxanos

das böse plugin wieder hinter deins stelle [..], dann dann startet das frontend in schwarz.

macht's auch, wenn's davor steht (mit "-s" gestartet ..) - außerdem ..

traxanos: Warum startest du das 'böse' Plugin auch nach softhddevice? Jeder weiß, dass das böse Plugin als erstes geladen werden muss.

nein tut es nicht, wenn es davor steht, dann kann es normal mit aktuell noch RESU gestartet werden. steht es nun dahinter startet das frontend in schwarz und ich sehe den rahmen des fensters, was mit -f normal gearnicht da sein drüfte. vor seiner änderung wurde wenn das böse nach shd gestartet wurde einfach doppelt aufgeweckt. ich denke da fehlt nur ein ein parameter um im dettached modus zustarten ode rich habs es komplett falsch verstanden.

Jetzt verstehe ich gar nichts mehr...

Für was braucht man den Detached Modus? Ich starte das böse Plugin, danach softhddevice und danach noch einige Plugins mehr. Und das läuft so ganz gut.

.. wäre wohl einen eigenen thread wert - um "diesen" hier wär's schade

Zitat von Copperhead

Für was braucht man den Detached Modus?

Für die karierten Maiglöckchen (etwas spezielle, aber notwendige Extrawünsche -> ab hier in softhddevice und yavdr 0.4 - hat das jemand am laufen? ) in yaVDR

Zitat von johns

Danach ist nichts passiert, was mit entfernen von "-DUSE_AUDIO_DRIFT_CORRECTION" verwendet wird.

kam nicht erst danach der config-parameter ins Makefile:

CONFIG += -DUSE_AUDIO_DRIFT_CORRECTION  # build new audio drift code

ich kenn mich da eh nicht aus - du bist der chef und weißt bescheid

ciax

Zitat von johns

Kannst bitte nochmal testen, jetzt sollte wenn mit -s (suspend) gestartet.
Nur Menu / Back / Stop und svdrp "RESU" diesen beenden.

hier starte ich bisher zuerst den "vdr-core" (mit plug softhddevice inkl. "-s") und dann/gleichzeitig X (das etwas dauert) mit graphtft-fe für den zweiten bildschirm. bis jetzt mußte man zB. einen kanal umschalten und dann war das bild da. jetzt dienen "Menu / Back / Stop und svdrp "RESU" " damit wieder ein bild da ist - richtig verstanden?

ciax

Johns danke für den oss-fix, läuft nun wieder flüssig so siehts aus (Kanal 1 RTL SD Kanal 7 ARD HD) http://pastebin.com/dBh6rnBq
cu peje

Frage: Warum verwendet noch jemand freiwillig OSS? Sollte das nicht lange durch ALSA abgelöst sein?

weils auch oss v4 gibt, klingt in meinen Ohren viel gefälliger als alsa....
siehe auch: https://wiki.archlinux.org/index.php/Open_Sound_System
cu peje

Naja... Ob man da klanglich wirklich einen Unterschied feststellen kann, müsste aber erst nochmal in einer Blindstudie ermittelt werden.

Fakt ist, dass die allermeisten Distributionen schon lange OSS abgestoßen haben. Vermutlich wirkt sich die Audio-API auch wenig bis garnicht auf den Klang aus. Die Aufgabe derer ist es, die Signale möglichst unverfälscht durchzureichen und über passende Treiber die Hardware anzusteuern.

MrEimer diese Diskusion gehört nicht in diesen Thread, aber teste doch selbst...
Und abgesen von unseren linuxen laufen die meisten *nixe mit oss
cu peje

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.