segfault bei softhddevice mit squeezeplug.patch

Dr. Seltsam · 4. Februar 2014

Das neue squeezebox-Plugin enthält ja einen Patch für softhddevice:

Diff

--- vdr-plugin-softhddevice-0.6.1rc1.git20140124.1219.orig/softhddevice.cpp
+++ vdr-plugin-softhddevice-0.6.1rc1.git20140124.1219/softhddevice.cpp
@@ -2208,7 +2208,10 @@ bool cSoftHdDevice::SetPlayMode(ePlayMod
 	    break;
 	case pmAudioOnly:
 	case pmAudioOnlyBlack:
-	    break;
+	    dsyslog("[softhddev] play mode external audio\n");
+	    Suspend(0, 1, 0);
+	    SuspendMode = SUSPEND_EXTERNAL;
+	    return true;
 	case pmVideoOnly:
 	    break;
 	case pmNone:

Alles anzeigen

in yavdr testing ist der schon drin. Seitdem stürzt vdr mit einem segfault ab, wenn ich im mp3-Plugin (das den gleichen Playmode benutzt) skippe:

Im backtrace sieht das so aus:

Code

#0  0x00007fdddced7090 in RingBufferUsedBytes () from /usr/lib/vdr/plugins/libvdr-softhddevice.so.2.0.0
(gdb) bt
#0  0x00007fdddced7090 in RingBufferUsedBytes () from /usr/lib/vdr/plugins/libvdr-softhddevice.so.2.0.0
#1  0x00007fdddced2bda in AudioFlushBuffers () from /usr/lib/vdr/plugins/libvdr-softhddevice.so.2.0.0
#2  0x00007fdddcec4cef in Clear () from /usr/lib/vdr/plugins/libvdr-softhddevice.so.2.0.0
#3  0x00007fddd888734e in cMP3Player::Empty() () from /usr/lib/vdr/plugins/libvdr-mp3.so.2.0.0
#4  0x00007fddd8888713 in cMP3Player::SkipSeconds(int) () from /usr/lib/vdr/plugins/libvdr-mp3.so.2.0.0
#5  0x00007fddd887b729 in cMP3Control::ProcessKey(eKeys) () from /usr/lib/vdr/plugins/libvdr-mp3.so.2.0.0
#6  0x000000000046dcd6 in main ()

Drückt man Pause und löst sie wieder, ist es ähnlich:

Code

#0  0x00007fe275bf9090 in RingBufferUsedBytes () from /usr/lib/vdr/plugins/libvdr-softhddevice.so.2.0.0
(gdb) bt
#0  0x00007fe275bf9090 in RingBufferUsedBytes () from /usr/lib/vdr/plugins/libvdr-softhddevice.so.2.0.0
#1  0x00007fe275bf4bda in AudioFlushBuffers () from /usr/lib/vdr/plugins/libvdr-softhddevice.so.2.0.0
#2  0x00007fe275be6cef in Clear () from /usr/lib/vdr/plugins/libvdr-softhddevice.so.2.0.0
#3  0x00007fe2715a934e in cMP3Player::Empty() () from /usr/lib/vdr/plugins/libvdr-mp3.so.2.0.0
#4  0x00007fe2715aa558 in cMP3Player::PrevCheck() () from /usr/lib/vdr/plugins/libvdr-mp3.so.2.0.0
#5  0x00007fe27159d7e3 in cMP3Control::ProcessKey(eKeys) () from /usr/lib/vdr/plugins/libvdr-mp3.so.2.0.0
#6  0x000000000046dcd6 in main ()

Auslöser ist wohl AudioFlushBuffers, das durch Clear ausgelöst wird. Clear wiederum ruft das mp3-Plugin über DeviceClear auf.

Im Moment bin ich wohl der einzige, der das nachstellen kann, da ich eine für alsa-Ausgabe gepatchte Version des mp3-Plugins in Verbindung mit Ausgabe über plug:dmix verwende. Ohne den squeezebox-Patch klappt das auch prima.

Das Problem tritt auch mit deaktiviertem CloseOnSwitch auf. Auch die Option -w alsa-no-close-open ändert nichts.

Auf meinem Test-VDR ist der backtrace ausagekräftiger:

Code

#0  RingBufferUsedBytes (rb=0x0) at ringbuffer.c:337
#1  0x00007f75dd600bfa in AudioFlushBuffers () at audio.c:2457
#2  0x00007f75dd5f1f4a in Clear () at softhddev.c:2594  --> Aufruf von AudioFlushBuffers
#3  0x00007f75d32a0e9e in DeviceClear (this=<optimized out>) at /home/martin/vdr-2.1.3/include/vdr/player.h:31
#4  cMP3Player::Empty (this=0x1d93400) at player-mp3.c:2045
#5  0x00007f75d32a21d3 in cMP3Player::SkipSeconds (this=0x1d93400, secs=3) at player-mp3.c:2131
#6  0x00007f75d3297646 in ProcessKey (Key=kRight, this=0x1d93040) at mp3.c:685
#7  cMP3Control::ProcessKey (this=0x1d93040, Key=kRight) at mp3.c:641
#8  0x000000000046ecc2 in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:1218

softhddev.c:2594 ist der Aufruf von AudioFlushBuffers
audio.c:2457 ist die Zeile

Zitat

RingBufferReadAdvance(AudioRing[AudioRingWrite].RingBuffer,
RingBufferUsedBytes(AudioRing[AudioRingWrite].RingBuffer));

in AudioFlushBuffers()

Da ist also irgendwo noch der Wurm drin. Deshalb sollte der squeezebox-Patch erstmal nicht ins softhddevice-git einfließen.

gerade gemerkt:
der squeezebox-Patch ist auch Schuld daran, dass das mp3-Plugin bei DVB-Ausgabemodus stumm bleibt und der Fortschrittsbalken im Turbomodus durchrast. Auf meinem Test-VDR kriege ich dann auch leicht einen segfault mit ähnlichem backtrace:

Code

Program terminated with signal 11, Segmentation fault.
#0  RingBufferUsedBytes (rb=0x0) at ringbuffer.c:337
337         return atomic_read(&rb->Filled);
(gdb) bt
#0  RingBufferUsedBytes (rb=0x0) at ringbuffer.c:337
#1  0x00007face91d8bfa in AudioFlushBuffers () at audio.c:2457
#2  0x00007face91c9f4a in Clear () at softhddev.c:2594
#3  0x00007facdee78e9e in DeviceClear (this=<optimized out>) at /home/martin/vdr-2.1.3/include/vdr/player.h:31
#4  cMP3Player::Empty (this=0x203f8c0) at player-mp3.c:2045
#5  0x00007facdee79cdf in cMP3Player::StopPlay (this=this@entry=0x203f8c0) at player-mp3.c:2052
#6  0x00007facdee79f04 in cMP3Player::Activate (this=0x203f8c0, On=<optimized out>) at player-mp3.c:1717
#7  0x000000000048543e in cDevice::Detach (this=0x1e87160, Player=Player@entry=0x203f8c0) at device.c:1247
#8  0x00000000004d3a84 in cPlayer::Detach (this=this@entry=0x203f8c0) at player.c:37
#9  0x00007facdee75384 in cMP3Player::~cMP3Player (this=0x203f8c0, __in_chrg=<optimized out>) at player-mp3.c:1696
#10 0x00007facdee75429 in cMP3Player::~cMP3Player (this=0x203f8c0, __in_chrg=<optimized out>) at player-mp3.c:1698
#11 0x00007facdee6b5be in cMP3Control::Stop (this=this@entry=0x203f610) at mp3.c:271
#12 0x00007facdee6b95b in cMP3Control::~cMP3Control (this=0x203f610, __in_chrg=<optimized out>) at mp3.c:265
#13 0x00007facdee6b999 in cMP3Control::~cMP3Control (this=0x203f610, __in_chrg=<optimized out>) at mp3.c:266
#14 0x00000000004d3be0 in cControl::Shutdown () at player.c:105
#15 0x000000000046edcd in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:1268

Alles anzeigen

johns · 5. Februar 2014

Der Segfault sollte einfach zulösen zu sein.

Beim Suspend gibts kein Audio mehr, damit stürzt dann der Clear ab.

Entweder muß ich im Highlevel den Suspend abfragen oder im low-level, daß es kein Audiodevice mehr gibt.

Diff

diff --git a/softhddev.c b/softhddev.c
index e5c937e..e3c09d1 100644
--- a/softhddev.c
+++ b/softhddev.c
@@ -2591,8 +2591,10 @@ void Clear(void)
 
     VideoResetPacket(MyVideoStream);   // terminate work
     MyVideoStream->ClearBuffers = 1;
-    AudioFlushBuffers();
-    //NewAudioStream = 1;
+    if (!SkipAudio) {
+       AudioFlushBuffers();
+       //NewAudioStream = 1;
+    }
     // FIXME: audio avcodec_flush_buffers, video is done by VideoClearBuffers
 
     // wait for empty buffers

Alles anzeigen

Johns

johns · 5. Februar 2014

Das durchrassen kommt dadurch, daß der Ton nicht mehr ausgeben wird und so kein Zeittakt für das mp3 Plugin kommt.

pmAudioOnlyBlack und pmAudioOnly wird wohl für beide gebraucht.

Der eine sendet darüber seine Daten, der andere will an das Audiodevice.

Geht dann wohl nur über einen Servicecall um das Audiodevice frei zu bekommen.

Johns

TomJoad · 5. Februar 2014

Ich habe auch schon lange mp3 mit alsa gepatched. Das sind im wesentlichen die Routinen, die auch music(version=0.9.9-dev2) verwendet, ich habe aber, wo nötig, DeviceClear durch eine eigene FlushBuffers-Routine ersetzt. Damit gibt es aktuell keine Probleme mit softhddevice. Ich hatte auch eine Service-Schnittstelle implementiert, die gut funktioniert hat, aber der squeeze-Patch ist viel simpler und funktioniert bei mir auch gut

johns · 5. Februar 2014

Wäre für squeezeplugin nicht pmVideoOnly:richtig?
bzw. wenn mp3 über alsa läuft, könnte es auch diesen Playmode setzen.

Oder wir definieren pmExternAudio_THIS_SHOULD_BE_AVOIDED ?

Johns

urknall · 5. Februar 2014

Am saubersten wäre wohl einen Service Call: detach/attach audio-only in softhddevice einzubauen und diese neuen Routinen beim starten beenden der Plugins aufrufen zu lassen.

urknall · 5. Februar 2014

Hoppla das hat sich überschnitten, oder halt wie Johns schrieb anders herum betrachtet, je nach sichtweise...

Dr. Seltsam · 5. Februar 2014

Code

pmAudioOnly,      // audio only from player, video from decoder
pmAudioOnlyBlack, // audio only from player, no video (black screen)
pmVideoOnly,      // video only from player, audio from decoder
pmExtern_THIS_SHOULD_BE_AVOIDED
                 // external player (e.g. MPlayer), release the device
                 // WARNING: USE THIS MODE ONLY AS A LAST RESORT, IF YOU
                 // ABSOLUTELY, POSITIVELY CAN'T IMPLEMENT YOUR PLAYER
                 // THE WAY IT IS SUPPOSED TO WORK. FORCING THE DEVICE
                 // TO RELEASE ITS FILES HANDLES (OR WHATEVER RESOURCES
                 // IT MAY USE) TO ALLOW AN EXTERNAL PLAYER TO ACCESS
                 // THEM MEANS THAT SUCH A PLAYER WILL NEED TO HAVE
                 // DETAILED KNOWLEDGE ABOUT THE INTERNALS OF THE DEVICE
                 // IN USE. AS A CONSEQUENCE, YOUR PLAYER MAY NOT WORK
                 // IF A PARTICULAR VDR INSTALLATION USES A DEVICE NOT
                 // KNOWN TO YOUR PLAYER.

Alles anzeigen

Das mit den Playmodes ist vertrackt.

pmVideoOnly passt m.E. nicht wirklich. Es wurde nach meinen Recherchen mal eingeführt, damit man beim teletext-Plugin (nicht osdteletext!) weiterhin den Fernsehton hören kann. Die Implementierung bei FF-Karten (SD, HD) mag da zu ganz anderen Ergebnissen führen.

Hier geht es ja eher darum, dass das Plugin weder Video noch Audio-Daten liefert, sondern nur das OSD nutzen will. Damit scheidet auch pmExtern_THIS_SHOULD_BE_AVOIDED aus, denn es schließt auch das OSD.

Dr. Seltsam · 5. Februar 2014

Zitat von urknall

Am saubersten wäre wohl einen Service Call: detach/attach audio-only in softhddevice einzubauen und diese neuen Routinen beim starten beenden der Plugins aufrufen zu lassen.

woher weiss das squeezebox-Plugin, dass softhddevice als Ausgabeplugin läuft? Die Servicecalls dürften ja nicht erfolgen, wenn jemand ein anderes Ausgabedevice laufen hat.

urknall · 5. Februar 2014

Stimmt da hast du recht, daran hatte ich gar nicht gedacht...

mini73 · 5. Februar 2014

Moin!

Service-call wäre eigentlich nicht das richtige. Ähnlich wie bei "ScaleVideo" sollte es eine API im vdr geben, das vom Plugin genutzt werden kann. Damit können auch Ausgabe-Devices erkannt werden, die diese Fähigkeit nicht unterstützen.

Was möchte man denn? Einen Aufruf, damit das Ausgabedevice seinen Ton ab- und wieder anschaltet? Aber doch eigentlich nur, weil softhddevice und mp3 zufällig beide Alsa benutzen, oder?
Es ist also eigentlich ein spezielles Problem zwischen mp3, squeezebox und softhddevice, oder?

Wie sind die Playmodes eigentlich zu interpretieren?
pmAudioOnly bedeutet, der player (also das mp3-Plugin bei DVB-Ausgabe, was wohl eigentlich vdr-Ausgabe bedeutet) erzeugt nur Ton, der durch den vdr an das Ausgabedevice weitergeleitet wird (mit den üblichen Problemen, Ende verschlucken usw.).
pmVideoOnly bedeutet, der player gibt nur Videopakete an der vdr.
Woher kommt dabei der Ton bzw. das Video (je nach dem, was fehlt), was bedeutet "from decoder"? Passt das nur für FF-Karten, die nicht im Transfer-Mode sind? Oder werden einfach die entsprechenden Pakete vom Live-Signal eingemischt? Das kann ja aber eigentlich wegen unterschiedlicher Timestamps nicht klappen, die gehören ja nicht zusammen.
Letztlich soll dem Ausgabedevice doch mitgeteilt werden, was für Daten es zu erwarten hat, oder? Die fehlende Komponente kann er sich dann ausdenken, nur bei pmAudioOnlyBlack sagt der player eindeutig, dass kein Video angezeigt, sondern nur der Ton ausgegeben werden soll.

Lars.

horchi · 5. Februar 2014

Hi lars,

genau, wie die zu interpretieren sind ist eine gute Frage, hier geht das Verständnis scheinbar allgemein etwas auseinander. Habe gerade mit Johns per PN überlegt wie man das angehen könnte. Vermutlich ist der pmExtern_THIS_SHOULD_BE_AVOIDED der einzige Mode der dazu gedacht ist das der VDR bzw. das Ausgabe Plugin ein Gerät ganz loslässt. Diesen kann ich jedoch nicht verwenden da ich das OSD benötige, die OSD Ausgabe selbst am VDR vorbei zu implementieren fände ich eher schräg.

Ich tendiere dazu bei Klaus die zusätzlichen Modi

Code

pmExternAudioOnly_THIS_SHOULD_BE_AVOIDED
         pmExternAudioOnlyBlack_THIS_SHOULD_BE_AVOIDED

anzufragen. Diese müssten ja nicht sofort von jedem Ausgabe Plugin unterstützt werden, John würde sie in softhddevice einbauen.

@Klaus, falls du gerade mit liest, wie siehst du das?

Viele Grüße
Jörg

TomJoad · 5. Februar 2014

Zitat von Dr. Seltsam

woher weiss das squeezebox-Plugin, dass softhddevice als Ausgabeplugin läuft? Die Servicecalls dürften ja nicht erfolgen, wenn jemand ein anderes Ausgabedevice laufen hat.

Wie ich schon geschrieben habe, funktionieren Servicecalls. Die werden einfach ignoriert, wenn nichts entsprechendes beim VDR angemeldet ist.
Trotzdem finde ich den ClearDevice nicht gut, was soll denn das Ausgabeplugin da machen, wenn die Ausgabe eigentlich über mp3/music läuft. Besser ist m.E. eine FlushBuffers-Routine im mp3-Plugin, die snd_pcm_drop aufruft.

mini73 · 5. Februar 2014

Zitat von TomJoad

Wie ich schon geschrieben habe, funktionieren Servicecalls. Die werden einfach ignoriert, wenn nichts entsprechendes beim VDR angemeldet ist.

Die funktionieren aber nicht, wenn ich z.B. gleichzeitig xineliboutput und softhddevice geladen habe (ja, das geht, man kann zwischen beiden als primäres Device hin und her schalten) und beide den Servicecall unterstützen, weil das Plugin nicht wissen kann, welches der Ausgabeplugins gerade aktiv ist.

Lars.

mini73 · 5. Februar 2014

Moin!

Zitat von horchi
Ich tendiere dazu bei Klaus die zusätzlichen Modi
Code
pmExternAudioOnly_THIS_SHOULD_BE_AVOIDED
         pmExternAudioOnlyBlack_THIS_SHOULD_BE_AVOIDED
anzufragen. Diese müssten ja nicht sofort von jedem Ausgabe Plugin unterstützt werden, John würde sie in softhddevice einbauen.

Ja, wäre eine Überlegung wert. Muss man mal ausprobieren.

Lars.

TomJoad · 5. Februar 2014

Zitat von mini73

Die funktionieren aber nicht, wenn ich z.B. gleichzeitig xineliboutput und softhddevice geladen habe (ja, das geht, man kann zwischen beiden als primäres Device hin und her schalten) und beide den Servicecall unterstützen, weil das Plugin nicht wissen kann, welches der Ausgabeplugins gerade aktiv ist.

Lars.

xineliboutput hat noch nie das Alsa-Device blockiert, dort brauche ich den Servicecall nicht. Ich habe ja auch oben geschrieben, dass mir der kleine Patch mittlerweile sympathischer ist.
Bei mir hatte ich vorher in softhddevice einen Service() definiert, der bei Aufruf mit SOFTHD_STOP_AUDIO einen Suspend(0,1,0) gemacht hat und bei SOFTHD_START_AUDIO Resume(/) und SuspendMode= NOT_SUSPENDED.
Entsprechend dann im mp3 bei cOutputAlsa::Init einen CallFirstService(SOFTHD_STOP_AUDIO) und bei ~cOutputAlsa() einen CallFirstService(SOFTHD_START_AUDIO).
Das hat immer gut funktioniert
Ich weiss allerdings nicht, wie softhddevice darauf reagiert, wenn es nicht primäres Device ist und ob bei dir das Umschalten bei laufendem Plugin funktioniert hat

mini73 · 5. Februar 2014

Für sein eigenes Setup geht vieles, Workarounds gibt's Dutzende. Das mit dem Servicecall geht natürlich in gewisser Weise.
Mal sehen, ob wir etwas finden, was mit quasi allen Setups zurecht kommt.

Bis jetzt gefallen mir die pmExternAudioOnly-Dinger auch ganz gut.

Lars.

kls · 6. Februar 2014

Zitat von horchi
Ich tendiere dazu bei Klaus die zusätzlichen Modi
Code
pmExternAudioOnly_THIS_SHOULD_BE_AVOIDED
         pmExternAudioOnlyBlack_THIS_SHOULD_BE_AVOIDED
anzufragen. Diese müssten ja nicht sofort von jedem Ausgabe Plugin unterstützt werden, John würde sie in softhddevice einbauen.

@Klaus, falls du gerade mit liest, wie siehst du das?

Die ganzen ePlayMode wurden in der Anfangszeit des VDR eingebaut, weil halt verschiedene Plugins ganz spezielle Dinge machen wollten. VDR selber ist ein reiner Videorecorder und benötigt nur pmAudioVideo für die Wiedergabe von Aufzeichnungen (bzw. den Transfer-Mode) und pmNone für die Live-Wiedergabe direkt über das primäre Device (also *intern* im primären Device, ohne Transfer-Mode - was natürlich nur bei FF-Devices geht).

Alles andere sind Spezialitäten bzw. Hacks, die ich selber weder benutze noch brauche. Ich sehe daher auch kein Problem darin, noch weitere einzubauen. Einzige Voraussetzungen: die normale Funktion des VDR darf davon in keinster Weise beeinflusst werden, und es müssen die enstprechenden Implementierungen für dvbsddevice und dvbhddevice gemacht werden.

Klaus

Dr. Seltsam · 6. Februar 2014

Zitat von kls

Einzige Voraussetzungen: die normale Funktion des VDR darf davon in keinster Weise beeinflusst werden, und es müssen die enstprechenden Implementierungen für dvbsddevice und dvbhddevice gemacht werden

Wenn ich das richtig verstehe, soll der Patch-Ersteller sich auch um die Erweiterung der FF-Plugins kümmern? Das könnte schwierig werden, weil kaum noch einer so eine Karte hat. Die Hardwarefähigkeiten der FF-Karten kennt wahrscheinlich auch kaum einer so gut wie Du. Ist es bei diesen überhaupt möglich, das OSD noch bereit zu stellen, aber das oder die für die Video- und/oder Audio-Wiedergabe zuständige(n) device(s) zu schließen und freizugeben?

Die Implementierung der bisherigen Playmodes in dvbsddevice ist für jemanden, der mit der Funktion der ioctls des Treibers nicht vertraut ist, alles andere als einfach nachzuvollziehen, da hilft auch ein Blick in die DVB API nicht. Die richtigen ioctls in der richtigen Reihenfolge für den gewünschten Zweck damals zu finden, erforderte wahrscheinlich einiges Tüfteln.

Code

case pmNone:
         // special handling to return from PCM replay:
         CHECK(ioctl(fd_video, VIDEO_SET_BLANK, true));
         CHECK(ioctl(fd_video, VIDEO_SELECT_SOURCE, VIDEO_SOURCE_MEMORY));
         CHECK(ioctl(fd_video, VIDEO_PLAY));


         CHECK(ioctl(fd_video, VIDEO_STOP, true));
         CHECK(ioctl(fd_audio, AUDIO_STOP, true));
         CHECK(ioctl(fd_video, VIDEO_CLEAR_BUFFER));
         CHECK(ioctl(fd_audio, AUDIO_CLEAR_BUFFER));
         CHECK(ioctl(fd_video, VIDEO_SELECT_SOURCE, VIDEO_SOURCE_DEMUX));
         CHECK(ioctl(fd_audio, AUDIO_SELECT_SOURCE, AUDIO_SOURCE_DEMUX));
         CHECK(ioctl(fd_audio, AUDIO_SET_AV_SYNC, true));
         CHECK(ioctl(fd_audio, AUDIO_SET_MUTE, false));
         break;
    case pmAudioVideo:
    case pmAudioOnlyBlack:
         if (playMode == pmNone)
            TurnOffLiveMode(true);
         CHECK(ioctl(fd_video, VIDEO_SET_BLANK, true));
         CHECK(ioctl(fd_audio, AUDIO_SELECT_SOURCE, AUDIO_SOURCE_MEMORY));
         CHECK(ioctl(fd_audio, AUDIO_SET_AV_SYNC, PlayMode == pmAudioVideo));
         CHECK(ioctl(fd_audio, AUDIO_PLAY));
         CHECK(ioctl(fd_video, VIDEO_SELECT_SOURCE, VIDEO_SOURCE_MEMORY));
         CHECK(ioctl(fd_video, VIDEO_PLAY));
         break;
    case pmAudioOnly:
         CHECK(ioctl(fd_video, VIDEO_SET_BLANK, true));
         CHECK(ioctl(fd_audio, AUDIO_STOP, true));
         CHECK(ioctl(fd_audio, AUDIO_CLEAR_BUFFER));
         CHECK(ioctl(fd_audio, AUDIO_SELECT_SOURCE, AUDIO_SOURCE_MEMORY));
         CHECK(ioctl(fd_audio, AUDIO_SET_AV_SYNC, false));
         CHECK(ioctl(fd_audio, AUDIO_PLAY));
         CHECK(ioctl(fd_video, VIDEO_SET_BLANK, false));
         break;
    case pmVideoOnly:
         CHECK(ioctl(fd_video, VIDEO_SET_BLANK, true));
         CHECK(ioctl(fd_video, VIDEO_STOP, true));
         CHECK(ioctl(fd_audio, AUDIO_SELECT_SOURCE, AUDIO_SOURCE_DEMUX));
         CHECK(ioctl(fd_audio, AUDIO_SET_AV_SYNC, false));
         CHECK(ioctl(fd_audio, AUDIO_PLAY));
         CHECK(ioctl(fd_video, VIDEO_CLEAR_BUFFER));
         CHECK(ioctl(fd_video, VIDEO_SELECT_SOURCE, VIDEO_SOURCE_MEMORY));
         CHECK(ioctl(fd_video, VIDEO_PLAY));
         break;
    case pmExtern_THIS_SHOULD_BE_AVOIDED:
         close(fd_video);
         close(fd_audio);
         fd_video = fd_audio = -1;
         break;

Alles anzeigen

Wenn ich jetzt raten sollte, würde ich sagen, die neuen Playmodes

pmExternAudioOnly_THIS_SHOULD_BE_AVOIDED
= stelle OSD zur Verfügung; zeige TV-Bild im Hintergrund; Ton kommt von einem externen Player, der evtl. -aber nicht zwangsläufig- an das vom Ausgabeplugin genutzte audio device geht

pmExternAudioOnlyBlack_THIS_SHOULD_BE_AVOIDED
= stelle OSD zur Verfügung; zeige anstelle des TV-Bildes im Hintergrund ein schwarzes Bild; Ton kommt von einem externen Player, der evtl. -aber nicht zwangsläufig- an das vom Ausgabeplugin genutzte audio device geht

können für die FF-Karten exakt genauso implementiert werden wie pmAudioOnlyBlack bzw. pmAudioOnly.

Dass jemals ein vom Plugin gestarteter externer Player auf die audio-devices der FF-Karten zugreifen muss, ist ja wohl nicht zu erwarten. Deshalb muss das audio device bei diesen Ausgabedevices m.E. nicht geschlossen werden.

Dr. Seltsam · 6. Februar 2014

Bei dvbhddevice ist eine Anpassung m.E. nicht erforderlich. Das Plugin definiert nur für zwei Playmodes (pmNone und pmExtern_THIS_SHOULD_BE_AVOIDED) eine spezielle Behandlung. Alle anderen Playmodes werden bereits heute gleich behandelt. Ich denke mal, das auch hier kein Bedarf für ein Plugin besteht, das audio device extern zu beliefern.

segfault bei softhddevice mit squeezeplug.patch

Jetzt mitmachen!

Teilen