PulseAudio Dummys

[mcbo]

Jetzt sind wir ganz dicht am Ziel.

Es könnte aber auch sein, dass wir nur in dsnooped von Anfang an das Subdevice mitangeben hätten müssen.

Genau, das war der Fehler.

Mit dieser Lösung, kann ich den Audio-Stream, jetzt mehrfach über "dsnooped" abgreifen.

Jetzt habe ich aber noch das Problem,
das mein Decoder "monitord" nicht mit "dsnooped" spricht.

Hierfür brauche ich das Device im Format "plughw:Loopback,1,0"

Wie schicke ich das "dsnooped" wieder in ein Loopback?

[smutbert]

Mit arecord aufnehmen und gleich wieder mit aplay auf einem anderen Loopback(sub)device abspielen, ganz grob, ohne den vielleicht notwendigen Optionen von aplay und arecord:

Code: Alles auswählen

arecord -D dsnooped | aplay -D "hw:Loopback,0,7"

dann stünde "plughw:Loopback,1,7" für die Aufnahme durch monitord zur Verfügung.

Aber bist du sicher, dass plughw:… notwendig ist? Oder ist monitord vielleicht nur auf die Konvertierungsfähigkeiten von plughw angewiesen? Dann sollte das auch anders möglich sein, auch wenn ich auf Anhieb nicht weiß, wie.

[mcbo]

Du hast recht.

Die Lösung bei monitord ist "plug:dsnooped"

[mcbo]

Hi,

ich hätte da noch ein kleines Problem.

aplay verursacht bei mir in Verbindung mit rtl_fm und der Option -l (Squelch) immer "underruns"

Code: Alles auswählen

rtl_fm -f XXX.XXXM -M fm -s 22050 -l 20 -p 36.790 | aplay -t raw -r 22050 -f S16_LE -c 1 -D hw:Loopback,0,0

Gibt es für aplay eine Alternative, um das Loopback-Device zu versorgen?

Ohne die Option -l (Squelch) bei rtl_fm, gibt es kaum "underruns".
Dann muß ich mir aber ständig das Rauschen anhören.

Scheinbar kommt aplay mit den "Stillen" zwischen den Funkübertragungen nicht klar.

Hast Du eine Idee?

[smutbert]

und die Underruns äußern sich in stotterndem Ton? Treten die underruns nur bei Stille auf?


So ziemlich alle Audioplayer sollten in der Lage sein, den Audiodatenstrom über das Loopbackgerät abzuspielen, zB auch mplayer, alsaplayer,…, aber ich glaube aplay ist schon die richtige (und eine sehr genügsame) Wahl. Ich nehme an mit der Rauschsperre liefert rtl_fm trotzdem einen dauernden Audiodatenstrom, der aber eben zeitweise einfach nur Stille enthält (die andere Variante wäre natürlich, dass der einfach den Datenstrom „anhält“, dann kannst du das, was ich jetzt schreibe vergessen — eine Idee hätte ich uU aber auch für diese Situation).

Jedenfalls hat aplay keine Schwierigkeiten Stille abzuspielen. Eher hätte ich vermutet, dass die Rechenlast durch rtl_fm zu groß wird und der Cubietruck nicht mehr mitkommt. Kannst du das ausschließen?

[mcbo]

und die Underruns äußern sich in stotterndem Ton?

Ja, kurze Aussetzer. Teilweise auch nur optisch auf der Konsole.

Treten die underruns nur bei Stille auf?

Die underuns kommen dann, wenn wieder Modulation (Rauschsperre öffnet) kommt.

Eher hätte ich vermutet, dass die Rechenlast durch rtl_fm zu groß wird und der Cubietruck nicht mehr mitkommt. Kannst du das ausschließen?

Ja, kann ich ausschließen.
Getestet habe ich auf unterschiedlichen Systemen.
- Raspberry Pi mit Raspian (Debian)
- CubieTruck mit Cubian (Debian)
- Banana Pi mit Raspian (Debian)
- Dell Latitude mit i7 CPU (Debian)

Und verschiedene DVB-T Sticks.

Überall "Underruns"

Es muß also an rtl_fm oder alsa / aplay liegen.

[smutbert]

DVB-T Sticks? Da läuft das doch ganz anders?

Nach deiner Beschreibung ist mir noch nicht ganz klar wie das läuft. Sagen wir du würdest so etwas wie

Code: Alles auswählen

rtl_fm … -l … > ~/datenstrom

(mit Rauschsperre) machen und überwachst die Größe der Datei ~/datenstrom. Wird die Datei dann laufend größer oder nur, wenn die Rauschsperre gerade nicht aktiv ist?

[mcbo]

Habe es gerade noch einmal getestet.

Die Datei wird nur größer, wenn eine Modulation (Rauschsperre ist geöffnet) anliegt.

Damit kommt aplay wohl nicht klar?

[smutbert]

Ja, das ist es dann. aplay rechnet nicht damit, dass die abzuspielende Datei plötzlich eine Pause macht und versucht eben trotzdem alle 1/48000 Sekunden ein Sample abzuspielen. Bei aktivierter Sperre, läuft der Puffer leer und wenn dann die Audiodaten wieder kommen, versucht aplay vielleicht sogar noch den Rückstand aufzuholen (?)…
Mir fallen zwei mögliche Lösungsansätze ein:

• Dafür sorgen, dass das Abspielprogramm mit Pausen vernünftig zurechtkommt. Dadurch scheidet aplay vermutlich aus, aber auch viele andere Programme werden damit so ihre Probleme haben, vermute ich. mplayer ist vielleicht einen Versuch wert.
• Trotz Rauschsperre, immer Audiodaten liefern lassen. Das sollte mit jedem Abspielprogramm funktionieren und relativ einfach möglich sein. Dazu definierst du ein neues Ausgabegerät
  

  Code: Alles auswählen

  pcm.dmixer {
  	type dmix
  	slave {
  		pcm "hw:Loopback,0,0"
  		rate 44100
  	}
  }
  

  das dank dmix die Ausgaben mehrerer Programme entgegennehmen kann und startest zusätzlich zu rtl_fm parallel ein aplay, das nur Stille abspielt (erstaunlich wie oft das hier im Forum schon vorkommt):

  Code: Alles auswählen

  $ rtl_fm -f XXX.XXXM -M fm -s 22050 -l 20 -p 36.790 | aplay -t raw -r 22050 -f S16_LE -c 1 -D "plug:dmixer"
  
  $ aplay /dev/zero -f S16_LE -r 22050 -c 2 -D dmixer
  

  Das plug:… war bei mir hier wegen der Kanalzahl nötig, die mit dmix standardmäßig bei 2 (Stereo) liegt, gut möglich, dass du das auch eleganter hinbekommst. Das sollte außerdem auch mit deinem multi-Gerät funktionieren, du musst nur dmixer in slave.a.pcm einsetzen (und gegebenenfalls für slave.b.…/….c.… ebenfalls eigene dmixer-Geräte definieren und dort einsetzen).[/s]

[mcbo]

Hi,

Das dmix-Device funktioniert.
Habe testweise mal einen Web-Radiostream mit mplayer und rtl_fm gemixt.

aber

Ich habe immer noch underruns.
Liegt das daran, dass ich den Stream vom rtl_fm über die Pipe direkt bekomme.
Damit wirkt ja dmix noch nicht und der Stream reisst bei geschlossenem Squelch ja ab.

Code: Alles auswählen

root@raspberrypi:~# sudo rtl_fm -f XXX.XXXM -M fm -s 22050 -l 20 -p 37 -E dc | aplay -t raw -r 22050 -f S16_LE -c 1 -D "plug:dmixer"
Found 1 device(s):
  0:  Generic, RTL2832U, SN: 7777111110005700

Using device 0: Generic RTL2832U
Found Elonics E4000 tuner
Tuner gain set to automatic.
Tuner error set to 37 ppm.
Tuned to XXXXXXXXX Hz.
Oversampling input by: 46x.
Oversampling output by: 1x.
Buffer size: 8.08ms
Exact sample rate is: 1014300.020041 Hz
Sampling at 1014300 S/s.
Output at 22050 Hz.
Wiedergabe: Rohdaten 'stdin' : Signed 16 bit Little Endian, Rate: 22050 Hz, mono
Unterlauf!!! (mindestens 1306269165,182 ms)
Unterlauf!!! (mindestens 1306167142,526 ms)
Unterlauf!!! (mindestens 1306209116,635 ms)

[smutbert]

hast recht! Die underruns könnten auch eine ganz andere Ursache haben [1], das finde ich aber alles etwas undurchsichtig. Vielleicht könntest du zumindest versuchen, ob die underruns aufhören, wenn du nebenher ein Programm laufen läßt, das etwas Systemlast erzeugt.

[1] http://lists.osmocom.org/pipermail/osmo ... 01225.html

[mcbo]

Wie müsste denn der Befehl ausehen, wenn ich rtl_fm über die Pipe an mplayer leiten will?
Bin da irgendwie gescheitert.

Wenn ich rtl_fm ohne Option "-l" oder mit "-l 0" laufen lasse, gibt es keine underruns.
Gibt es eine Möglichkeit, eine Rauschsperre nach rtl_fm nachzubilden?
Eventuell mit sox oder so?

Muß ich den zwingend, den rtl_fm-Stream, über aplay weiter verarbeiten?
Oder könnte ich den Stream auch als Filestream in ein RAM-Drive legen und von dort weiter verwenden.

rtl_fm -f XXX.XXXM -M fm -s 22050 -l 20 -p 37 -E dc > /tmp/stream

[smutbert]

mit mplayer könntest du es zB so in der Art machen

Code: Alles auswählen

rtl_fm … | mplayer /dev/stdin …

die Optionen für die Audioausgabe von mplayer müsstest du noch selbst herausfinden und ergänzen. Ausprobiert ob das dein Problem löst, habe ich aber nicht.

Die Rauschsperre ist in rtl_fm wohl schon am sinnvollsten - ich wüßte auch keinen Weg wie man das anders machen könnte, aber ich kenne rtl_fm erst seit diesem Thread hier.

Das mit der Datei sollte auch funktionieren, aber du brauchst eher so etwas wie einen Ringpuffer [1], damit die Datei/der Puffer nicht einfach immer größer und größer wird. Aber auch da habe ich keine Idee, wie man das angehen könnte.

[1] http://de.wikipedia.org/wiki/Warteschla ... Ringpuffer

[mcbo]

Hi,

ich bin es mal wieder

Ich habe Deine Variante mit "dsnoop", mit einem rtl_fm Stick,
für eine Funküberwachung laufen.

meine .asoundrc:

Code: Alles auswählen

pcm.dsnooped {
        type dsnoop
		ipc_key 2048
        ipc_perm 0666
        slave {
                pcm "hw:Loopback,1,0"
                channels 1
                rate 22050
        }
}

Einspeisen tue ich das Funksignal so:

Code: Alles auswählen

sudo rtl_fm -d 0 -f XXX.XXXM -M fm -s 22050 -l 20 -p 5 -E DC -F 0 -g 42 | AUDIODEV=plughw:Loopback,0,0 play -t raw -r 22050 -e signed-integer -b 16 -c1 -V1 -q -

Das Signal kann man dann mehrfach hier abgreifen:

Code: Alles auswählen

sudo arecord -D plug:dsnooped -f S16_LE -c 2 -t wav | aplay -t raw -r 48k -f S16_LE -D plughw:4,0

Das klappt echt super auf einem BananaPi.

Jetzt meine Fragen:

(1.)
Ich würde gerne zusätzlich einen 2. rtl_fm - Stick auf einem anderen Kanal betreiben.
Kann man das "dsnooped" - Device mehrfach verwenden?
Könnte ich meine .asoundrc so anlegen?

Code: Alles auswählen

pcm.dsnooped1 {
        type dsnoop
		ipc_key 2048
        ipc_perm 0666
        slave {
                pcm "hw:Loopback1,1,0"
                channels 1
                rate 22050
        }
}

pcm.dsnooped2 {
        type dsnoop
		ipc_key 2048
        ipc_perm 0666
        slave {
                pcm "hw:Loopback2,1,0"
                channels 1
                rate 22050
        }
}

(2.)
Wie könnte ich die Audio Signale des 2. rtl_fm Emfpänger mixen und auf einen Lautsprecher ausgeben?
Eventuell auch Mono ein Funk-Kanal Links und ein Funk-Kanal Rechts?

Danke, Gruß

Marcel

[smutbert]

1.) ja, aber der ipc Key sollte sich nicht wiederholen, wenn ich Sinn und Zweck richtig verstanden habe. Also zB einmal 2048 und für das zweite 2049.
2.) ich wüßte keinen Weg eine Quelle (pcm.dsnooped1, pcm.dsnooped2) in Alsa direkt mit einer Senke, also gewissermaßen einem Ausgang einer Soundkarte zu verbinden. Es gibt aber genug Software, die das erledigen kann, fast alles was dazu nötig ist machst du ja schon in dieser Zeile

Code: Alles auswählen

sudo arecord -D plug:dsnooped -f S16_LE -c 2 -t wav | aplay -t raw -r 48k -f S16_LE -D plughw:4,0

Du bräuchtest nur zwei Instanzen davon, eine für jedes dsnooped und musst dafür sorgen, dass das Ausgabegerät (hier plughw:4,0) mehrere Ausgabeströme mischen kann. Das erreichst du indem du dir einen dmix-Gerät einrichtest

Code: Alles auswählen

pcm.dmixer {
	type dmix
	ipc_key 2051
	slave {
		pcm "hw:4,0"
	}
}

und das (dmixer) statt plughw:4,0 angibst oder es funktioniert vielleicht auch ein schlichtes

Code: Alles auswählen

plug:\'dmix:SLAVE=\"hw:4,0\"\'

statt dem plughw:4,0 - bei der zweiten Variante bin ich allerdings weder beim Escapen (\) sattelfest, noch weiß ich wie sich genau sich der dann fehlende ipc_key auswirkt.

[mcbo]

dmixer klappt !!!
Ich muß nur in das Device "plug:dmixer" einspeisen !!!

Aber die Duplizierung von "dsnooped" will noch nicht

meine ".asoundrc":

Code: Alles auswählen

pcm.dsnooped1 {
        type dsnoop
      ipc_key 2048
        ipc_perm 0666
        slave {
                pcm "hw:Loopback1,1,0"
                channels 1
                rate 22050
        }
}

pcm.dsnooped2 {
        type dsnoop
      ipc_key 2049
        ipc_perm 0666
        slave {
                pcm "hw:Loopback2,1,0"
                channels 1
                rate 22050
        }
}

Wenn ich dann in das Device "plughw:Loopback1,0,0" oder "plughw:Loopback2,0,0" einspeisen will,
bekomme ich folgenden Fehler:

Code: Alles auswählen

Invalid value for card
aplay: main:682: audio open error: No such device

Gruß

Marcel

[smutbert]

hab nicht genau genug aufgepaßt, was du geschrieben hast
das Loopbackmodul stellt zwei Geräte mit je 8 Subgeräten zur Verfügung:
- Loopback,0,0-7
- Loopback,1,0-7
hw:Loopback1 oder hw:Loopback2 gibt es dagegen nicht, aber mit den vorhandenen 16 Subgeräten solltest du ein Auslangen finden (aplay -l das die Audiogeräte auflistet kennst du vermutlich noch)

Es gibt mehrere möglichkeiten, wie die 2 dsnooped-Geräte aussehen könnten. Du könntest zB einmal die Schleife von Loopback,1 auf Loopback,0 und einmal die umgekehrte von Loopback,0 auf Loopback,1 nutzen:

Code: Alles auswählen

pcm.dsnooped1 {
        type dsnoop
      ipc_key 2048
        ipc_perm 0666
        slave {
                pcm "hw:Loopback,1,0"
                channels 1
                rate 22050
        }
}

pcm.dsnooped2 {
        type dsnoop
      ipc_key 2049
        ipc_perm 0666
        slave {
                pcm "hw:Loopback,0,0"
                channels 1
                rate 22050
        }
}

dann musst du ein Signal in Loopback,0 und das andere in Loopback,1 einspeisen. Nach dem Schema wird es aber ein Durcheinander, wenn du noch ein drittes Signal verarbeiten willst...

Oder du nutzt einfach ein weiteres Subgerät, dann musst du weniger ändern :

Code: Alles auswählen

pcm.dsnooped1 {
        type dsnoop
      ipc_key 2048
        ipc_perm 0666
        slave {
                pcm "hw:Loopback,1,0"
                channels 1
                rate 22050
        }
}

pcm.dsnooped2 {
        type dsnoop
      ipc_key 2049
        ipc_perm 0666
        slave {
                pcm "hw:Loopback,1,1"
                channels 1
                rate 22050
        }
}

Dann verwendest du Loopback,1 nur für die Aufnahme und Loopback,0 für das Einspeisen des Signals. So hättest du noch 6 weitere Subgeräte frei. Erst wenn du mehr als 8 Signale willst, müsstest wie bei der ersten Variante die Loopbackgeräte auch in der anderen Richtung nutzen.


In beiden Fällen musst du eines der beiden

Code: Alles auswählen

sudo rtl_fm [viele Optionen] | AUDIODEV=plughw:Loopback,0,0 play -t raw -r 22050 -e signed-integer -b 16 -c1 -V1 -q -

anpassen und zwar das plughw:Loopback,0,0 (je nach Variante die 0 für das Gerät oder Subgerät)

Alles klar?

[mcbo]

Super, danke, funktioniert !!!

Gruß

Marcel

[mcbo]

Hi,

eine Frage hätte ich dazu noch

Kann ich das "dmixer" - Device (gemixte Signal), welches ja an die Hardware "hw:4,0"
gebunden ist, auch abgreifen und für Icecast (ices,darkice,ezstream) verwenden?
Oder muß ich mir hierfür noch ein virtuelles Device (Dummy-Device) erstellen?

Code: Alles auswählen

pcm.dmixer {
   type dmix
   ipc_key 2051
   slave {
      pcm "hw:4,0"
   }
}

Danke,

Gruß

Marcel

[smutbert]

Von dmix kannst du nichts "abgreifen", das gibt den Audiodatenstrom nur an die Hardware weiter. Du könntest ein weiteres Loopdevice einschleifen, also dmix an ein weiteres Subdevice von Loopback,0 oder Loopback,1 ausgeben lassen und dann mit einem weiteren dsnoop-Ding, einmal mit

Code: Alles auswählen

arecord … | aplay …

an dmix wiedergeben und einmal mit einem Streamingserver aufnehmen und ins Netz streamen.
Aber das wird schön langsam etwas unübersichtlich und erinnert mich etwas an dieses Setup viewtopic.php?f=25&t=147913
das hat auch relativ harmlos angefangen und ist dann etwas ausgeartet - zumindest habe ich zum Schluss nicht mehr ganz durchgeblickt


Eine andere Variante wäre vielleicht pulseaudio, das bietet von vornherein die Möglichkeit jedes Wiedergabegerät auch als Aufnahmequelle auszuwählen, aber da kann ich kaum weiterhelfen, weil ich damit keine Übung habe und es nicht einmal installiert habe.
Es gibt auch noch ecasound oder jackd, beide bieten ebenfalls Möglichkeiten zum Routen von Signalen zwischen verschiedenen Quellen und Senken, aber auch mit den beiden kenne ich mich nicht wirklich aus.

[mcbo]

Danke, habe es mit 2 getrennten Streams gelöst.

Ein kleines Ärgernis habe ich aber noch mit meinem BananaPI

Für mein "pcm.dmixer" Device, muß ich in der ".asoundrc",
die Hardware ID (pcm "hw:3,0" ) meiner Soundkarte (USB) angeben.

Leider ändert die sich beim aktivieren des HDMI-Ports.
Das HDMI-Audio-Device schiebt sich dann auf hw:3,0 und verdrängt meine
USB-Soundkarte auf hw:4,0.

Alle Versuche, die Reihenfolge in der "alsa-base.conf" zu beeinflussen sind bis jetzt gescheitert.

Code: Alles auswählen

# autoloader aliases
install sound-slot-0 /sbin/modprobe snd-card-0
install sound-slot-1 /sbin/modprobe snd-card-1
install sound-slot-2 /sbin/modprobe snd-card-2
install sound-slot-3 /sbin/modprobe snd-card-3
install sound-slot-4 /sbin/modprobe snd-card-4
install sound-slot-5 /sbin/modprobe snd-card-5
install sound-slot-6 /sbin/modprobe snd-card-6
install sound-slot-7 /sbin/modprobe snd-card-7
# Cause optional modules to be loaded above generic modules
install snd /sbin/modprobe --ignore-install snd && { /sbin/modprobe --quiet snd-ioctl32 ; /sbin/modprobe --quiet snd-seq ; : ; }
install snd-rawmidi /sbin/modprobe --ignore-install snd-rawmidi && { /sbin/modprobe --quiet snd-seq-midi ; : ; }
install snd-emu10k1 /sbin/modprobe --ignore-install snd-emu10k1 && { /sbin/modprobe --quiet snd-emu10k1-synth ; : ; }
# Keep snd-pcsp from beeing loaded as first soundcard
options snd-pcsp index=-2
# Keep snd-usb-audio from beeing loaded as first soundcard
options snd-usb-audio index=-1
# Prevent abnormal drivers from grabbing index 0
options bt87x index=-2
options cx88_alsa index=-2
options snd-atiixp-modem index=-2
options snd-intel8x0m index=-2
options snd-via82xx-modem index=-2

Hast Du einen Tip für mich?


Gruß

Marcel

[smutbert]

Aber klar doch. Nimm statt der Nummer, den Namen der Soundkarte, so wie wir es mit den snoop-Einträgen bereits machen (hw:Loopback,…). Den Namen siehst du in der Ausgabe von aplay -l. Hier zB von meinem System

# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0]
Subdevices: 0/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 0: ALC892 Analog [ALC892 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 1: ALC892 Digital [ALC892 Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: Juli [ESI Juli@], device 0: ICE1724 [ICE1724]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: Juli [ESI Juli@], device 1: ICE1724 IEC958 [ICE1724 IEC958]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 3: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 3: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7

blau hervorgehoben sind die Namen, die ich statt x einsetzen kann in Angaben wie hw:x,y (oder einfach nur hw:x)

[mcbo]

Hallo smutbert,

ich teste mein Projekt jetzt schon seit einigen Wochen.

rtl_fm ==> Loopback ==> arecord ==> ezstream (icecast2)

Loopback ==> arceord ==> multimon_ng (Pocsag-Decoder)
Loopback ==> arecord ==> mp3-File
Loopback ==> arecord ==> dmixer ==> Lautsprecher

espeak (Sprachausgabe) ==> dmixer ==> Lautsprecher

Das ganze Projekt habe ich mit Python-Scripts umgesetzt.

Dieses Konstrukt läuft eigentlich sehr gut.
Nur ca. 1 mal am Tag, ganz sporadisch, hängt mein Decoder.
Es sieht aus, als wenn die Pipe vom rtl_fm - Stream unterbrochen wird.
Dadurch werden dann die arecords abgeschossen.
In meinen Python-Logfiles kann ich keinen Fehler finden.
Aber im Terminal hat er mir mal broken pipe geschrieben.

Gibt es für arecord eine Alternative?
Bringt mir hier die Option -N oder ein Buffer was?

Oder könnte ich die Pipe mit Python überwachen, und eventuell die Dienste neu starten?


Gruß

Marcel

[smutbert]

Keine Ahnung ob das eine gute Idee ist, aber wahrscheinlich würde ich die Pipes durch etwas anderes ersetzen, mir fallen aber nur "named Pipes" ein: da würde das irgendwie so ähnlich

Code: Alles auswählen

$ mkfifo namedpipe
$ rtl_fm … > ./namedpipe
$ cat ./namedpipe | aplay …

aussehen. Die Idee dahinter wäre, dass du die Befehle einzeln überwachen und nötigenfalls neu starten könntest, allerdings bringt das in der Form, die ich gerade aufgeschrieben habe wahrscheinlich gar nichts, weil da wohl immer noch entweder beide „Enden“ der Pipe oder gar keine beendet wird (denke ich).
Zum Überwachen (und automatischen Neustarten) von Programmen in der Shell findest du jedenfalls sicher genug Beispiele.

mir ist jetzt nur nicht ganz klar, wieso sich deswegen die arecords beenden - mit welcher Meldung tun sie das denn?

python interessiert mich zwar sehr, weil ich da auch gerade etwas am Basteln bin, aber helfen kann ich dir mit pyhton fürchte ich leider gar nicht.

[mcbo]

Hi,

mir ist jetzt nur nicht ganz klar, wieso sich deswegen die arecords beenden - mit welcher Meldung tun sie das denn?

Das ist mir auch nicht so klar.
Ich kann keine Fehlermeldung finden.
Habe sämtliche Logmöglichkeiten versucht.

Kann so eine Pipe überlaufen?

Ich habe es jetzt erst einmal so gelöst:

- mehrere Links auf arecord angelegt (arecord_multimon-ng, arecord_lautsprecher, arecord_ezstream, ........)
- diese arecords überwache ich jetzt in einem Python-Script und starte die Dienste bei Bedarf automatisch durch.

Das ist nur eine Notlösung

Das Einzigste, was ich Beobachten kann, wenn der arecord sich beendet hat ist, dass das Pythonscript von meinem Decoder auf 100% CPU-Last geht

Gruß

Marcel