softhddevice gibt Sounddevice nicht frei

  • wie muss softhddevice konfiguriert sein, damit es bei Playmode pmExternal... auch einen suspend macht?


    Hat das Starten des Plugins mit der -D Option darauf einen Einfluss? Welche Einstellung im Menü ist ggf. zu aktivieren?


    Es gibt drei Modi:


    DETA/ATTA
    SUSP/RESU
    external player


    Suspend über Menu ist wie SUSP/RESU.
    Bei SUSP/RESU kann man über Menu und setup.conf configurieren (Suspend.Close).


    DETA und External Player schalten immer Audio und Video aus.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • gibt es hier inzwischen neue Erkenntnisse?


    Verstehen tu ich es immer noch nicht wirklich.


    Die Auswirkung von ClearOnSwitch=1 entsteht nur bei Playmode 0. Der kommt sowohl beim Wechsel auf external Playmode (z.B. Wechsel zu mplayer; was dann auch zusätzlich einen Suspend bewirkt) als auch bei Beenden einer Aufzeichnungswiedergabe sowie beim Kanalwechsel. Die einzige wirkliche Änderung beim Playmode 0 ist nun, dass nicht nur beim Beenden einer Aufzeichnungswiedergabe, sondern auch beim Kanalwechsel ein Clear() ausgeführt wird. Das Clear() wiederum löst einen AudioFlushBuffers() aus. Und wenn ich es richtig verstanden habe, wird dabei das audio device geschlossen und gleich wieder geöffnet.


    Der Aufruf von Clear() erfolgte auch im alten Code (bzw. erfolgt auch bei ClearOnSwitch=1), wenn eine Aufzeichnungswiedergabe beendet wird. Da macht und machte es offenbar keine Probleme.
    Beim Wechsel auf den Playmode external (z.B. mplayer) gibt es zunächst einen Playmode 0 (pmNone), und dann Playmode 5 (pmExtern_THIS_SHOULD_BE_AVOIDED).
    Im alten Code wurde beim Playmode 0 kein Clear ausgelöst - dies ist im neuen Code bei ClearOnSwitch=1 jedoch der Fall. Anschließend führt der Playmode 5 einen Suspend aus.


    Probleme treten also offenbar immer nur dann auf, wenn in kurzer Abfolge hintereinander durch Playmode 0 ein Clear() aufgerufen wird und danach bzw. parallel ein Suspend() mit int audio=1 ausgelöst wird (wie z.B. bei DETA oder pmExternal...)


    Zitat

    AudioNextRing schließt das Audiodevice und öffnet es neu. Entweder hängt der Close oder der Open.


    an welcher Stelle im Code geschieht das open/close?


    Kann es sein, dass dieser Code in Suspend()


    Code
    if (audio) {
    	AudioExit();
    	if (MyAudioDecoder) {
    	    CodecAudioClose(MyAudioDecoder);
    	    CodecAudioDelDecoder(MyAudioDecoder);
    	    MyAudioDecoder = NULL;
    	}
    	NewAudioStream = 0;
    	av_free_packet(AudioAvPkt);
        }


    mit dem Close/Open des alsa-devices kollidiert?



    Zitat

    Also im Moment ist die Rückmeldung schon nach dem Flush und damit kann es AlsaFlushBuffers nicht sein, der nächste Kandidat wäre AlsaSetup.


    in AlsaSetup() gibt es ja noch den Abschnitt "close+open to fix HDMI no sound bug". Johns, ist dass die Stelle, wo Du ein Hängen beim close/open vermutest?

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • ich kann jetzt auch bei mir nachvollziehen, dass es bei aktiviertem ClearOnSwitch beim DETA und anschließendem ATTA per svdrpsend nicht immer, aber regelmäßig beim ATTA hängt. Bild und Ton kommen dann nicht wieder . Ich habe zahlreiche Debugmeldungen im Code verstreut und konnte somit die Stelle eingrenzen, wo es beim attachen hängen bleibt.


    Es hängt in AlsaOpenPCM an dieser Stelle:


    Hier kommt in den Fällen, wo es hängt, überhaupt gar keine Rückmeldung. Erst wenn ich vdr mit Strg-C beende, läuft der Code weiter:


    audio.c AlsaOpenPCM open 'default' none blocking war erfolgreich, error= Erfolg
    audio/alsa: set block mode erfolgreich gesetzt: default
    audio.c Ende AlsaOpenPCM. jetzt return handle


    In einigen wenigen Fällen habe ich beim Hängen aber auch "error: Die Dateizugriffsnummer ist in schlechter Verfassung" gesehen.


    Ich vermute, dass hier in zu rascher Abfolge das device geschlossen und wieder geöffnet wird: Einmal ein close in AlsaExit, dann in AlsaSetup ("close+open to fix HDMI no sound bug") und schließlich ein open in AlsaOpenPCM.


    Wenn ich das "close+open to fix HDMI no sound bug" in AlsaSetup deaktiviere indem ich dort auf "if (0)" prüfe,


    dann gibt es keine Probleme mehr.


    Dies ist noch keine Lösung (wird der close+open Fix benötigt?), aber zumindest ein Ansatz.


    Getestet habe ich mit dem aktuellen git vom 26.12. ohne einen der Patches in diesem Thread

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Genau das ist die Stelle, die ich auch als Ursache vermute.
    Durch den "Flush" vorher scheint ALSA aus dem Tritt zukommen.
    Ob der "close+open" noch notwendig ist, kann ich prüfen, habe mehrere Wochen gesucht, warum bei mir kein HDMI Ton funktionierte.
    ALSA ist entweder so kompliziert oder die Entwickler sehr unfähig.
    Ich habe keine Lust ein Testprogram zuschreiben und es auf der Mailingliste zuposten.


    Ein Workaround wäre beim Flush die Open+Close zureduzieren, wie beim Umschalten, da wird nur bei einer Veränderung der Konfiguration geschlossen und wieder geöffnet.


    Code
    Debug(3, "audio/alsa: xxxxx state '%s'\n",
                    snd_pcm_state_name(snd_pcm_state(AlsaPCMHandle)));


    Vielleicht passiert es nur bei einem bestimmten State? Obiger Code gibt den aktuellen State aus.
    Ich konnte auf keinem Rechner den Fehler reproduzieren.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • gibt es hier inzwischen neue Erkenntnisse?


    Nein, bei mir funktioniert es mit dem letzten Patch von johns. Hatte das Problem seitdem nie wieder.


    Gruß

    Gen2VDR v5.1
    ---------------
    Intel DG45ID mit Core2Duo E4300, 2,5GB DDR2, Gainward G210 1024MB passiv, SSD, cineS2 + DuoFlex S2 unicable, TT Budget T-1500, MSI Mega Sky 580 DVB-T USB-Stick, Atric Einschalter, 3TB Video HDD

  • Zitat

    bei mir funktioniert es mit dem letzten Patch von johns


    ich fürchte aber, das ist nur eine "Placebo-Nebenwirkung". Ich konnte die Fehlerquote schon dadurch senken, dass ich viel Debug-Ausgaben eingebaut habe und so den Code verlangsame. ;D

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Bei einem DETA:


    zum Ende von AlsaFlushBuffers (nach snd_pcm_drop und snd_pcm_prepare) ist der state bei einem DETA jedenfalls immer noch running.


    In AlsaSetup bringt der snd_pcm_close keinen Fehler.


    Danach gibt es zwei verschiedene Szenarien (immer noch beim DETA):
    -im ersten Szenario wird nun in AlsaOpenPCM das device erfolgreich non blocking wieder geöffnet und der block mode erfolgreich gesetzt (keine Fehlermeldungen). Anschließend ruft Suspend AudioExit auf, wodurch AlsaExit das alsa device wieder schliesst (snd_pcm_close ohne Fehlermeldung).


    -im zweiten Szenario wird AlsaOpenPCM zwar noch aufgerufen, aber es kommt nie zu einem Öffnen des devices und auch nicht zu einem Verlassen der Funktion. AlsaExit kann snd_pcm_close NICHT ausführen, da es kein AlsaPCMHandle gibt. Jedoch wird bei mir dann (und nur dann!) ein snd_mixer_close durchgeführt.



    Bei beiden Szenarien kommt es vor, dass das anschließende ATTA funktioniert oder nicht funktioniert, da gibt es also keinen Zusammenhang.


    In AlsaSetup und AlsaOpenPCM kann ich den state nicht loggen, weil der Code so nicht funktioniert. Da kriege ich

    Code
    vdr: pcm.c:928: snd_pcm_state: Zusicherung »pcm« nicht erfüllt.


    Was mir auffällt ist, dass nach einem Resume bzw. ATTA -auch dann, wenn es klappt - der gleiche Code scheinbar immer wieder ausgeführt wird:



    Das ganze dauert zwar kaum mehr als 1 Sekunde, aber warum hier immer wieder geöffnet und geschlossen wird, verstehe ich nicht.
    Bei den Ausgaben handelt es sich um meine eigenen debug-Meldungen, die ich im Code verstreut habe. Anhand der Bezeichnung lässt sich aber erkennen, auf welche Stellen es sich jeweils bezieht

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Der Hänger beim DETA/ATTA geht auch weg, wenn man in AlsaSetup zwischen close und re-open einen kurzen sleep einbaut. Ich habe es mal mit 50 Millisekunden probiert, wahrscheinlich reicht auch weniger. Vielleicht sollte man das "close+open to fix HDMI no sound bug" auch konfigurierbar machen, denn wenn es nur HDMI betrifft, ist der fix für alle Leute , die den Ton vom Mainboard SPDIF nehmen, ja sowieso nicht nötig.



    Mir fiel ferner noch auf, dass während des Kanalwechsel bei aktiviertem ClearOnSwitch AudioFlushBuffers doppelt ausgeführt wird.



    Es wird einmal durch das Clear() ausgelöst (im state RUNNING) und dann noch ein weiteres mal durch den AudioPlayHandlerThread im state PREPARED.


    Der AudioFlush muss aber in der Funktion Clear() drin bleiben, denn er wird bei den Trickspeed-Funktionen benötigt, wo vdr nur ein Clear() aufruft, aber es nicht gleichzeitig einen Streamwechsel mit Playmode-Änderung auf pmNone wie beim Kanalwechsel gibt.


    Ich habe daher in SetPlayMode bei case 0 jetzt statt dem Aufruf von Clear() dies reingeschrieben:

    Code
    int i;
        VideoResetPacket(MyVideoStream);	// terminate work
        MyVideoStream->ClearBuffers = 1;
        // wait for empty buffers
        // FIXME: without softstart sync VideoDecode isn't called.
        for (i = 0; MyVideoStream->ClearBuffers && i < 20; ++i) {
    	usleep(1 * 1000);
        }


    In Verbindung mit einem Deaktivieren des "close+open to fix HDMI no sound bug" -workarounds habe ich nun auch spürbar schnellere Umschaltzeiten

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Bei nicht Öffnen, wird regelmässig ein reopen probiert.
    Was ansich nicht schlecht ist, sobald das Audiodevice wieder frei ist,
    kommt dann der Ton. Aber ich glaube nicht, daß es im Moment richtig funktioniert.


    Mehrere AudioFlushBuffers sollten kein Problem sein, wenn ja, dann würde ich lieber
    im Low-Level erkennen, daß gerade ein Flush unnötig ist.


    Mein Patch + 50ms wait behebt das Problem?


    Ich werde noch einbauen, daß der open+close beim Flush nur ausgeführt wird, wenn er auch notwendig ist.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Code
    Mehrere AudioFlushBuffers sollten kein Problem sein, wenn ja, dann würde ich lieber
    im Low-Level erkennen, daß gerade ein Flush unnötig ist.


    ich befürchte, es verzögert den Umschaltvorgang unnötig. Wäre gut, wenn Du da eine Erkennung einbauen könntest.


    Zitat

    Mein Patch + 50ms wait behebt das Problem?


    ich hatte weder Deinen Patch V1 noch V2 probiert, nachdem es hier Rückmeldungen gab, dass dies nicht allen hilft. Die 50ms lösen bei mir das Problem bei einem aktuellen git ganz allein, ohne weitere Patches

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Ok deshalb habe ich gefragt.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • da ist evtl. noch ein weiteres Problem mit ClearOnSwitch.


    Obwohl ich das close/re-open in AlsaSetup deaktiviert habe, beendet vdr auf der Konsole in bestimmten Fällen nicht richtig. Starte ich z.B. auf der Konsole vdr mit den Plugins iptv und osdteletext und gehe auf einen iptv-Kanal, denn beendet vdr beim Strg-C nicht richtig, sondern bleibt irgendwo hängen (Meldung "exiting, exit code 0" fehlt auch). Sobald ich ClearOnSwitch deaktiviere, klappt es. Das ganze habe ich jetzt 50 mal hintereinander probiert, und es gibt entweder jedesmal den Fehler oder nie.


    Allerdings klappt es auch mit ClearOnSwitch, wenn ich das oasteletext-Plugin nicht mitlade. Sehr mysteriös.


    Hast Du eine Idee, wie ich das weiter debuggen kann? Habe schon lauter debug-Meldungen im Code verstreut, aber ich kriege einfach nicht raus, in welcher Funktion bzw. Zeile es hängt.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • die letzte Aussage ziehe ich zurück. Das Problem muss in iptv liegen. Dass es nur in bestimmten Konstellationen auftritt hat weiter wohl nichts zu sagen.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • So nun eine aktuallisierte Version des Patches.


    Der Flush sollte nun Threadsafe sein.
    Der Close/Open ist als Default aus.
    Der Delay ist als Default aus.


    Mit -w alsa-close-open sollte man den open close wieder aktiviern können.
    Mit -w alsa-close-open-delay kann man den Delay aktivieren.


    Bitte testen, auch die, die im Moment keine Probleme haben.
    Da ja nun als default kein close/open mehr gemacht wird.


    Johns

    Dateien

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Hallo Johns,


    danke für den Patch. Nach erstem Test scheint's zu funktionieren (Patch gegen die neueste GIT). Falls ich was komisches feststelle melde ich mich.


    Gruß

    Gen2VDR v5.1
    ---------------
    Intel DG45ID mit Core2Duo E4300, 2,5GB DDR2, Gainward G210 1024MB passiv, SSD, cineS2 + DuoFlex S2 unicable, TT Budget T-1500, MSI Mega Sky 580 DVB-T USB-Stick, Atric Einschalter, 3TB Video HDD

  • Hi !


    Kurz zur Erklärung ich nutze yaVDR (testing repo) und habe seit Installation von XBMC 12.3 auch das Problem, das softhddevice das Audio-Device nicht frei gibt.
    Gestern wurde nen nen neues softhddevice Paket geschnürt (0.6.1rc1.git20140114.1359-0yavdr0~precise) , welches den hier genannten Patch enthalten soll.


    Nach der Installation geht nur überhaupt kein Sound mehr bei mir, also wieder zurück auf die vorherige Version von softhddevice (0.6.1rc1.git20131220.2124-0yavdr0~precise) aus yavdr/testing und mal probiert die Option ClearOnSwitch auf 0 zu stellen.
    Und plötzlich funktioniert wieder alles :) auch ohne Patch. Also kann ich nur sagen, das bei mir der Patch leider nicht funktioniert ...

    Hardware: MB Asrock B75 Pro3-M, CPU Pentium G2120, RAM 4GB DDR-3, 60GB SSD System, 3TB HD Data, GFX GT610 HDMI, CineS2 V6.5, IR-USBWakup + Logitech Harmony, MiMO Displaylink UM710S 7" Display
    Software: yaVDR 0.5 testing repo

  • Hast Du denn mal versucht, ob das Ergänzen der Parameter

    Code
    -w alsa-close-open


    oder und ggf. zusätzlich

    Code
    -w alsa-close-open-delay


    in der /etc/vdr/plugins/plugin/softhddevice.conf den Ton auch bei aktiviertem ClearOnSwitch wieder hervorzaubert?


    Wenn nicht, teste das doch bitte mal mit der neuen Plugin-Version. Und Du bist auch sicher, dass 0.6.1rc1.git20140114.1359-0yavdr0~precise den Patch enthält?


    Welche Tonausgabe hast Du? über HDMI der Grafikkarte?

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Einmal editiert, zuletzt von Dr. Seltsam ()

  • Also wg. dem enthaltenen Patch - Wurde so in meinem UrsprungsThread so geschrieben: XBMC 12.3 unter yaVDR (Ursprungslink)


    Diese beiden Parameter habe ich beide noch nicht probiert, weder unter dem Paket vom 20.12.2013 , noch unter dem neuen Paket vom 14.01.2014.
    Teste gerne beides noch mal , nur gerade Laufen Aufnahmen und es wird auch TV geschaut auf meiner Kiste ;) Muss da später heute abend, oder morgen Abend mal Testen.


    Meine Tonausgabe läuft per Passthrough über HDMI ( hw 0,7 ) und es sind die beiden Optionen -a und -p mit hw 0,7 in der plugin.softhddevice.conf definiert (sonst hätte das bei mir gar nicht mit dem Ton funktioniert).

    Hardware: MB Asrock B75 Pro3-M, CPU Pentium G2120, RAM 4GB DDR-3, 60GB SSD System, 3TB HD Data, GFX GT610 HDMI, CineS2 V6.5, IR-USBWakup + Logitech Harmony, MiMO Displaylink UM710S 7" Display
    Software: yaVDR 0.5 testing repo

  • die beiden -w Parameter sind neu und werden daher erst mit dem neuen Paket funktionieren.


    Im alten Code war ja als ein Fix für 'kein Ton bei HDMI' ein close und re-open des alsa-devices enthalten. Das ist per default nun raus, kann aber wieder aktiviert werden. Wenn Du -w alsa-close-open benutzt, entspricht das weitestgehend der alten Pluginversion. Vermutlich hast Du dann die gleichen Probleme beim Wechsel von xbmc zu vdr.


    Wenn ich den Patch richtig verstehe, muss zur Aktivierung des Delays zwischen close und re-open die Option -w alsa-close-open-delay zusätzlich zu -w alsa-close-open gesetzt werden. Johns möge mich ggf. korrigieren.


    Interessant wäre, ob Deine Probleme mit beiden Optionen und aktiviertem ClearOnSwitch gelöst sind.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!