softhddevice - nach 0.5.0 wie gehts weiter?

Zitat von hotzenplotz5

johns ich dachte ich fang mal sowas wie eine übersetzung an, aber mein englisch ist einfach übel.

vielleicht mag jemand anders noch sein wissen/übersetzung einbringen ?

Ich hatte auch bereits mit einer Übersetzung begonnen.
Ich werde das mal mit Deiner Arbeit abgleichen.
Kann ja nicht schaden, schon jetzt etwas zu haben, auch wenn es später angepasst werden muss.

CafeDelMar

Zitat von johns

Also bei pass-through macht die Lautstärke kein Maschinengewehr mehr.

Das Problem hatte ich auch vorher nicht.
Ich gebe mit AES0 dem Alsa-Device die Info mit, dass es sich um Daten handelt, wenn keine vernünftigen Daten kommen, bleibt es einfach still.
Von daher hatte ich ja schon mal gefragt, ob man diese AES-Flags nicht direkt mit ins Plugin nehmen könnte, sollte ja eigentlich nur einen positiven Effekt haben. Aber schlag Dich damit jetzt bitte nicht rum, die Flags können ja auch so explizit mitgegeben werden.
Und anstatt Stille kann ich jetzt wunderbar die Lautstärke selbst bei DD 5.1 über den VDR regeln. Ich brauche die Funktion, ausgenommen Mute, zwar nicht, habe es aber trotzdem einfach mal getestet.

CafeDelMar

Zitat von johns

Da die im Thread verwendet werden und das Löschen nicht im Thread war, geht dies irgendwann in die Hose.
Wirst dann testen dürfen, wenn die neue Version fertig ist.

Johns

Mit der aktuellen Version und -DUSE_AUDIORING tritt das Problem weiterhin auf.

Zitat von johns

Wer über Umschaltzeiten meckert sollte mal sowas angucken

gemeckert habe ich nie - im gegenteil, du zeigst mit softhddevice das, was sich die "settopboxen" mal abschauen könnten. echt cool!

ciax

Hallo Johns,

zunächst einmal möchte ich mich ganz herzlich bei Dir für die Entwicklung des Plugins bedanken - tolle Sache! Es ist bemerkenswert, in welchem Tempo Du dieses Plugin entwickelt hast und immer noch weiterentwickelst.

Ich nutze das Plugin im Wohnzimmer & Schlafzimmer auf einem EeeBox-PC 1012 (Atom/ION, fullscreen) und auf meinem Entwicklungsrechner im Fenster auf dem Desktop (alle per streamdev an den Server).

Beim Betrieb im Fenster auf dem Desktop habe ich zwei Punkte, die das Plugin etwas unbequem (für mich) machen:

1. Fullscreen per Einfach-Klick mit der Maus:

Ist das VDR-softhddevice-Fenster teilweise durch andere Fenster verdeckt und möchte es nach vorne holen, so passiert es mir häufig, dass ich in das Fenster hineinklicke und dies daraufhin in Fullscreen-Modus umschaltet.

Was würdest Du (und die anderen) davon halten, wenn statt eines Einfach-Klicks ein Doppel-Klick das Fenster in den Fullscreen-Modus bringen würde?

Falls Du damit einverstanden wärst, so könnte ein Patch hierfür ungefähr so aussehen:

diff --git a/video.c b/video.c
index 762036b..9fa506a 100644
--- a/video.c
+++ b/video.c
@@ -8732,6 +8737,8 @@ static void VideoEvent(void)
     KeySym keysym;
     char buf[32];
     uint32_t values[1];
+    static Time lastButtonTime  =   0;
+    const  Time doubleClickTime = 250;
 
     XNextEvent(XlibDisplay, &event);
     switch (event.type) {
@@ -8762,7 +8769,10 @@ static void VideoEvent(void)
                event.xconfigure.width, event.xconfigure.height);
            break;
        case ButtonPress:
-           VideoSetFullscreen(-1);
+           if (event.xbutton.time - lastButtonTime < doubleClickTime)  {
+               VideoSetFullscreen(-1);
+           }
+           lastButtonTime = event.xbutton.time;
            break;
        case KeyPress:
            XLookupString(&event.xkey, buf, sizeof(buf), &keysym, NULL);

2. Skalieren des OSDs in das Fenster:

Bis Version 0.3.1 wurde - bei Verwendung von Text2Skin-Skins das OSD in das Fenster hineinskaliert. Seit Version 0.3.5 geschieht das nicht mehr.

Die beiden VDR-eigenen Skins und EnigmaNG (andere habe ich nicht ausprobiert) passen sich wunderbar in das softhddevice-Fenster ein, wohingegen von den von mir getesteten Text2Skin-Skins (Anthras von Tomas) nur der linke, obere Teil sichtbar ist.

Nun verstehe die ganze OSD-Geschichte im VDR zugegebenermassen nicht wirklich, vermute aber, dass die 'native' Skins sich eben selbst an die Gegebenheiten (Fensterausmaße) anpassen, wohingegen bei den Text2Skin-Skins vermutlich mit fixen Größen gearbeitet wird.

Tomas hatte das hier auch schon mal angesprochen und Du hattest hier geantwortet, dass Du Dir das mal ansehen wolltest.

Möglicherweise habe ich den entscheidenden Unterschied gefunden: in video.c in der Funktion VideoOsdInit() belegst Du die Variablen OsdWidth und OsdHeight.

Bis Version 0.3.1 hattest Du hier feste Zahlenwerte eingetragen (1920 und 1080), ab Version 0.3.5 schreibst Du in die Variable VideoWindowWidth() und VideoWindowHeight() - vermutlich die Fensterausmaße.

Also habe ich mal probehalber wieder die festen Zahlenwerte eingetragen:

void VideoOsdInit(void)
{
#if 1 // bis Version 0.3.1
    OsdWidth = 1920; 
    OsdHeight = 1080;
#else // ab Version 0.3.5
    OsdWidth = VideoWindowWidth;	// FIXME: must be configured
    OsdHeight = VideoWindowHeight;
#endif

und tatsächlich erscheinen dann auch die Text2Skin-Skins wieder in das Fenster hineinskaliert.

Allerdings kann ich nicht abschätzen, welche Auswirkungen diese Änderung auf native Skins habe würde. Vermutlich bekommen diese damit auch die feste Größe 1920x1080 mitgeteilt, stellen sich darin dar und das softhddevice-plugin skaliert die 1920x1080 auf die tatsächliche Fenstergröße herunter (was dazu führt, dass die Schriften nicht so schön aussehen und die Symbole/Icons in den native-Skins ziemlich klein sind.)

Daher würde ich diese Änderung wohl nicht generell einbauen. Aber was hieltest Du davon, wenn man diesen 1920x1080-Modus zumindest per Parameter beim Plugin-Start aktivieren könnte?

Viele Grüße und nochmals vielen Dank,
Alex

Zitat von johns

Schade habe gehofft das dieses Problem damit weg ist.
Schau mal bitte was im syslog steht:

Code

.... vdr: audio:  44100Hz supports 2 2 2 2 2 2 2 2 channels
.... vdr: audio:  48000Hz supports 2 2 2 2 2 2 2 2 channels

Gibt an mit wieviel Kanälen die einzelnen Formate ausgegeben werden. mono > 2, strereo -> 2, 3 -> 2 ... 8 -> 2.

Johns

Apr 21 00:12:55 htpc vdr: audio: 44100Hz supports 1 2 3 4 5 6 7 8 channels
Apr 21 00:12:55 htpc vdr: audio: 48000Hz supports 1 2 3 4 5 6 7 8 channels

Das Problem tritt auf beim Switch von
Apr 21 00:14:07 htpc vdr: codec/audio: format change 48000Hz 2 channels
Apr 21 00:14:07 htpc vdr: audio: setup channels 2 frequency 48000Hz pcm

auf

Apr 21 00:14:08 htpc vdr: codec/audio: format change 48000Hz 5 channels
Apr 21 00:14:08 htpc vdr: audio: setup channels 5 frequency 48000Hz pcm

Zitat von johns

Nimm mal "hw:" und nicht "plughw:". Wobei dann die Wandlung von "5 -> 6" in meinem Plugin noch fehlt.

Johns

mit hw: stürzt der vdr ab:

Apr 21 14:11:14 htpc vdr: codec/audio: format change 48000Hz 5 channels
Apr 21 14:11:14 htpc vdr: audio: setup channels 5 frequency 48000Hz pcm
Apr 21 14:11:14 htpc vdr: audio: unsupported 5 -> 6 channels resample

Außerdem brauche ich plug, damit ich alles als 6-Kanal ausgeben kann (auch Stereo). Ich brauche das damit ich am Receiver mein 5.1 Set für Fernsehen und meine Stereo-Boxen für Musik benutzen kann. Alles was als Multi-Kanal ankommt geht dann automatisch an das 5.1 Set.
Dafür habe ich eine asound, die alles als 6-Kanal ausgibt:

pcm.!default {
  type plug
  slave {
	pcm denon
	channels 6
  }
}


pcm.denon {
  type hw
  card 0
  device 7
}

1/3/5/7 Kanäle sind anscheinend per HDMI grundsätzlich nicht erlaubt.
Eine 6-Kanalausgabe für 5.0 Ton wäre natürlich super. Bei xine scheint es ja genauso zu funktionieren.

Merkwürdig bei der Sache ist, dass der Ton beim Umschalten für ca. eine Sekunde normal ist und erst dann die einzelnen Kanäle wahllos vertauscht werden. Außerdem komisch, dass das Problem nicht mehr aufgetreten ist, wenn beim Tonwechsel der Buffer neu angelegt wurde. Als ob noch jemand alte (2.0-)Daten eine Sekunde nach dem Umschalten in den Buffer schreibt.

Achja: Würde das 5->6 Kanal-Resampling bei meiner Konfiguration (plughw) überhaupt greifen? Oder klappt das nur wenn die Hardware keinen 5-Kanal-Support meldet (wie hw)?

Zitat von johns

Es könnte mit dem Ende vom Ringbuffer zusammenhängen.
Wenn die Puffer neu angelegt werden, dann starten die immer bei 0.
Ohne Neuanlegen lass ich die einfach stehen wo sie sind und da könnte es am Ende Probleme geben.

Wenn das Plugin umwandeln soll, dann mußt du hw: nehmen.

Johns

Könntest du denn das potentielle Problem im Buffer beheben/umgehen? Kann der Start nach Umschalten auf 0 gesetzt werden? Die ideale Lösung wäre für mich, wenn alsa das Umwandeln auf 6-Kanal per plug übernehmen würde.
Wenn ich jetzt die aktuelle Version mit 5->6 Kanalumwandlung nehme und direkt auf hw (mit channels 6) gehe funktionieren die 5- und 6-Kanal-Sender, aber 2 Kanal kann in Ermangelung einer 2->6 Kanal-Wandlung nicht mehr ausgegeben werden (audio: unsupported 2 -> 6 channels resample). Ob die Kanäle nun bei 5-Kanal-Sendern korrekt ausgegeben werden kann ich gerade nicht testen, weil gerade kein Sender echten 5-Kanal-Ton ausgibt. Mach ich dann später...

So, Sky sendet wieder 5 Kanal-Sound.
Die 5->6 Kanalumwandlung funktioniert anscheinend, zumindest habe ich bisher keine falschen Kanalzuordnungen bemerkt.
Dafür habe ich immer nach einigen Audioumschaltungen das Problem, dass ca. alle 7 Sekunden ein Bild- und Tonaussetzer passiert. Wenn es erstmal aufgetreten ist (meistens schon nach dem ersten Umschalten aber nicht immer) passiert es immer wieder, solange bis ich das Programm einmal wechsle. Das Phänomen hatte ich aber auch schon mal irgendwann beim Testen einer Version in der letzten Zeit (ca. letzte Woche).
Das Syslog dazu: http://pastebin.com/s0xYP1AQ