Recording-Problem

Hallo Liste,

ich betreibe eine TerraTec-USB Soundkarte am Raspberry Pi. Die Ausgabe von Sound mit "aplay" funktioniert bestens. Mit verschiedenen Mikrofonen kann ich durch das Programm "arecord" Audiofiles aufnehmen.

doorpi startet ohne Fehlermeldung, konfiguriert sind

capture_device = ALSA: USB PnP Sound Device
playback_device = ALSA: USB PnP Sound Device

Verbindung zur FritzBox funktioniert, auch der Anruf sowohl von DoorPi (nach Klingeln) als auch von internen Telefonen aus. Auch Fernschalten des Öffners funktioniert.

Problem: Audio-Übertragung vom Telefon zu DoorPi geht prima - zurück nicht. Spricht man ins Mikrofon an der TerraTec, hört man dies höchstens (bei entsprechender Einstellung von ALSA) aus dem ebenfalls an die TerraTec angeschlossenen Lautsprechern. Aber weder im Recording, noch am entfernten Telefon kommt etwas an.

Ist das schon mal jemandem passiert ?

LG

pah

Zitat von Nea

Hi, bist Du diesen Thread mal durch gegangen?

Neues DoorPI Projekt

Nein, aber das war bei mir schon ganz richtig konfiguriert, ich benutze ALSA seit vielen Jahren, fühlte mich da eigentlich sicher.

Mic Playback an oder aus, je nachdem, ob man das Echo hören will.

Mic Capture war auch ganz korrekt auf Maximum. Und, wie gesagt, "arecord" funktioniert gut. Alsamixer steht auf

numid=3,iface=MIXER,name='Mic Playback Switch'
  ; type=BOOLEAN,access=rw------,values=1
  : values=off
numid=4,iface=MIXER,name='Mic Playback Volume'
  ; type=INTEGER,access=rw---R--,values=1,min=0,max=127,step=0
  : values=58
  | dBminmax-min=0.00dB,max=23.81dB
numid=7,iface=MIXER,name='Mic Capture Switch'
  ; type=BOOLEAN,access=rw------,values=1
  : values=on
numid=8,iface=MIXER,name='Mic Capture Volume'
  ; type=INTEGER,access=rw---R--,values=1,min=0,max=16,step=0
  : values=16
  | dBminmax-min=0.00dB,max=23.81dB
numid=9,iface=MIXER,name='Auto Gain Control'
  ; type=BOOLEAN,access=rw------,values=1
  : values=on
numid=5,iface=MIXER,name='Speaker Playback Switch'
  ; type=BOOLEAN,access=rw------,values=1
  : values=on
numid=6,iface=MIXER,name='Speaker Playback Volume'
  ; type=INTEGER,access=rw---R--,values=2,min=0,max=151,step=0
  : values=118,118
  | dBminmax-min=-28.37dB,max=-0.06dB
numid=2,iface=PCM,name='Capture Channel Map'
  ; type=INTEGER,access=r----R--,values=1,min=0,max=36,step=0
  : values=0
  | container
    | chmap-fixed=MONO


numid=1,iface=PCM,name='Playback Channel Map'
  ; type=INTEGER,access=r----R--,values=2,min=0,max=36,step=0
  : values=0,0
  | container
    | chmap-fixed=FL,FR

Eigentlich sollte alles stimmen.

LG

pah

Hm, ich bin immer noch nicht weiter gekommen.

Diverse Versuche mit geänderten ALSA-Konfigurationen führen zum selben Ergebnis:

- doorpi Audio-Wiedergabe funktioniert
- doorpi Audio-Aufnahme vom Mikrofon funktioniert nicht. Ich kann zwar den Mikrofon-Sound via Mikrofon-Playback auf den lokalen Lautsprechern hören - aber über siphone geht gar nichts, und auch in den records ist nichts zu hören.

Ohne doorpi geht auch alles wunderbar, d.h., ein recording vom Mikrofon ist problemlos möglich. Auch alsamixer sagt mir, dass korrekterweise Mic Recording maximal ist.

Schlussfolgerung: irgendetwas stimmt nicht an der Konfiguration von doorpi - könnte das irgendetwas mit den verwendeten Codecs zu tun haben ? Wie kann ich doorpi dazu bewegen, genauer mitzuteilen, welches recording device es verwendet ?

LG

pah

Hab ich alles, danke trotzdem. Auch mehrfach überprüft - ohne Effekt. Etwas ratlos.

LG

pah

Sorry, war ein paar Tage etwas Land unter wegen der Endredaktion eines neuen Buches.

1. Vier verschiedene Mikrofone ausprobiert:
- primitives Kristallmikro
- Mikrofon eines Headsets
- Elektretmikrofon mit separater Speisung
- Eingebautes Mikrofon einer WebCam (über separaten USB-Anschluss)

2. Zwei USB-Soundkarten ausprobiert (plus das Mikro der WebCam, das separat digitalisiert)

3. Drei verschiedene Raspberry Pi: Typ A 1, Typ 2 und Typ 3

==> Keine Änderung. Ich kann lokal mit arecord aufnehmen, höre mich auch selbst bei eingeschaltetem Mic Playback - aber es geht nichts über doorpi bzw. linphone raus. Auch die Pegel stimmen laut amixer (Ja, auch bei capture)

Die einzige Sache, die ich bisher nicht geändert habe, ist der SIP-Server - das ist meine gute alte FritzBox 7390.

Es gibt diverse Forenbeiträge, die vom Scheitern an der FritzBox berichten und genau dieses Problem irgendwie verschämt zugeben. Woran liegt es ? Ich tappe immer noch im Dunkeln.

Die einzige Anomalie, die ich bisher gefunden habe, findet sich in der trace-Ausgabe von doorpi_cli:

2016-04-03 17:02:10,229 [INFO] [doorpi.sipphone.from_linphone]
also error in pcm_hw.c:1557 - open '/dev/snd/pcmC1D0c' failed (-2)
2016-04-03 17:02:10,254 [WARNING] [doorpi.sipphone.from_linphone]
./share/sounds/linphone/rings/oldphone.wav does not exist
2016-04-03 17:02:10,279 [WARNING] [doorpi.conf.config_object] could not delete section DoorPi, because it's not empty.
2016-04-03 17:02:10,279 [WARNING] [doorpi.conf.config_object]
found SIP-Phone - dialtone in BACKWARD_COMPATIBILITY_KEYS with DoorPi -
dialtone
2016-04-03 17:02:10,285 [WARNING] [doorpi.conf.config_object] could not delete section DoorPi, because it's not empty.
2016-04-03 17:02:10,286 [WARNING] [doorpi.conf.config_object]
found SIP-Phone - records in BACKWARD_COMPATIBILITY_KEYS with DoorPi -
records
2016-04-03 17:02:10,288 [WARNING] [doorpi.conf.config_object] could not delete section DoorPi, because it's not empty.
2016-04-03 17:02:10,288 [WARNING] [doorpi.conf.config_object]
found SIP-Phone - record_while_dialing in BACKWARD_COMPATIBILITY_KEYS
with DoorPi - record_while_dialing
2016-04-03 17:02:23,611 [WARNING] [doorpi.sipphone.from_linphone]
There is no object pool created in thread [1951708256]. Use
belle_sip_object_pool_push() to create one. Unowned objects not unref'd
will be leaked.
2016-04-03 17:02:23,821 [WARNING] [doorpi.sipphone.from_linphone] alsa_set_params: period:8 Using 8
2016-04-03 17:02:23,821 [WARNING] [doorpi.sipphone.from_linphone] alsa_set_params: periodsize:256 Using 170
2016-04-03 17:02:23,821 [WARNING] [doorpi.sipphone.from_linphone]
alsa_set_params: The period size 256 is not supported by your hardware.
2016-04-03 17:02:23,823 [WARNING] [doorpi.sipphone.from_linphone] alsa_set_params: period:8 Using 8
2016-04-03 17:02:23,823 [WARNING] [doorpi.sipphone.from_linphone] alsa_set_params: periodsize:256 Using 170
2016-04-03 17:02:23,823 [WARNING] [doorpi.sipphone.from_linphone]
alsa_set_params: The period size 256 is not supported by your hardware.
2016-04-03 17:02:28,811 [WARNING] [doorpi.sipphone.from_linphone] Too much data in channel 0, 34 ms in excess dropped
2016-04-03 17:02:28,812 [WARNING] [doorpi.sipphone.from_linphone] Too much data in channel 1, 10 ms in excess dropped
2016-04-03 17:02:33,822 [WARNING] [doorpi.sipphone.from_linphone] Too much data in channel 0, 32 ms in excess dropped
2016-04-03 17:02:33,822 [WARNING] [doorpi.sipphone.from_linphone] Too much data in channel 1, 20 ms in excess dropped
2016-04-03 17:02:38,879 [WARNING] [doorpi.sipphone.from_linphone] Too much data in channel 0, 32 ms in excess dropped
2016-04-03 17:02:38,880 [WARNING] [doorpi.sipphone.from_linphone] Too much data in channel 1, 20 ms in excess dropped
2016-04-03 17:02:43,839 [ERROR] [doorpi.sipphone.from_linphone] *** alsa_can_read fixup, trying to recover
2016-04-03 17:02:43,839 [ERROR] [doorpi.sipphone.from_linphone]
snd_pcm_avail_update: Datenübergabe unterbrochen (broken pipe)
2016-04-03 17:02:43,839 [WARNING] [doorpi.sipphone.from_linphone] MSAudio MSTicker: We are late of 214 miliseconds.
2016-04-03 17:02:43,840 [INFO] [doorpi.sipphone.from_linphone] also error in pcm.c:7843 - overrun occurred
2016-04-03 17:02:43,892 [WARNING] [doorpi.sipphone.from_linphone] Too much data in channel 0, 30 ms in excess dropped
2016-04-03 17:02:43,892 [WARNING] [doorpi.sipphone.from_linphone] Too much data in channel 1, 30 ms in excess dropped
2016-04-03 17:02:49,951 [WARNING] [doorpi.sipphone.from_linphone] MSAudio MSTicker: We are late of 1325 miliseconds.
2016-04-03 17:02:49,952 [ERROR] [doorpi.sipphone.from_linphone] *** alsa_can_read fixup, trying to recover
2016-04-03 17:02:49,952 [ERROR] [doorpi.sipphone.from_linphone]
snd_pcm_avail_update: Datenübergabe unterbrochen (broken pipe)
2016-04-03 17:02:49,952 [INFO] [doorpi.sipphone.from_linphone] also error in pcm.c:7843 - overrun occurred
2016-04-03 17:02:49,953 [WARNING] [doorpi.sipphone.from_linphone] Too much data in channel 0, 238 ms in excess dropped
2016-04-03 17:02:49,953 [WARNING] [doorpi.sipphone.from_linphone] Too much data in channel 1, 210 ms in excess dropped

Wem ist das schon mal begegnet ?

LG

pah

Zu 1.: Längst geschehen, ich arbeite hier sogar als root

Zu 2.: Ist der default-Inhalt, direkt aus dem frisch installierten Paket - siehe Anhang

zu 3.: Die USB-Soundkarte ist bei mir c0, Reihenfolge wurde in /etc/modprobe.de/alsa-base.conf geändert mit

# This sets the index value of the cards but doesn't reorder.
options snd_usb_audio index=0
options snd_bcm2835 index=1


# Does the reordering.
options snd slots=snd-usb-audio,snd-bcm2835

Damit ergibt amixer -c0 contents den Inhalt aus der im Anhang liegenden Datei amixer.txt.

Ist mir schleierhaft ...

LG

pah

1. Nein, Jessie

2. In der Datei /lib/modprobe.d/aliases.conf habe ich

# These are the standard aliases and dependencies.
# This file does not need to be modified.


# prevent unusual drivers from appearing as the first sound device ###########
options snd-pcsp index=-2
#options snd-usb-audio index=-2
options cx88_alsa index=-2
options snd-atiixp-modem index=-2
options snd-intel8x0m index=-2
options snd-via82xx-modem index=-2


# work around other kernel issues ############################################
# The EHCI driver should be loaded before the ones for low speed controllers
# or some devices may be confused when they are disconnected and reconnected.
softdep uhci-hcd pre: ehci-hcd
softdep ohci-hcd pre: ehci-hcd

Das ist hier ohne Effekt - das Auskommentieren der snd-usb-audio - Zeile sorgt nur dafür, dass es keinen Konflikt mit der /etc/modprobe.d/alsa-base.conf gibt.

"Du meinst bestimmt:" /etc/modprobe.d/alsa-base.conf => Natürlich.

Ändern von
defaults.ctl.card 1
defaults.pcm.card 1

Bewirkt Folgendes:
1. Reihenfolge der Soundkarten wird nicht geändert. USB ist immer noch Karte 0, bcm2835 Karte 1 => OK, korrekt
2. aplay spielt jetzt - weil default pcm device die Karte 1 ist - sounds ohne explizite Device-Angabe über den bcm2835 ab => OK, korrekt
3. alsamixer alles OK

Jetzt aber kommt etwas Interessantes. In der doorpi.ini ist eingetragen

playback_device = ALSA: USB PnP Sound Device
capture_device = ALSA: USB PnP Sound Device

Beim Start findet doorpi diese Karte aber nicht, sondern fälschlicherweise

2016-04-07 20:30:15,089 [INFO] [doorpi.sipphone.from_linphone] found 3 possible sounddevices:
2016-04-07 20:30:15,090 [DEBUG] [doorpi.sipphone.from_linphone] |rec|play| name
2016-04-07 20:30:15,093 [DEBUG] [doorpi.sipphone.from_linphone] | X | X | ALSA: default device
2016-04-07 20:30:15,096 [DEBUG] [doorpi.sipphone.from_linphone] | O | X | ALSA: bcm2835 ALSA
2016-04-07 20:30:15,098 [DEBUG] [doorpi.sipphone.from_linphone] | O | X | ALSA: bcm2835 ALSA
2016-04-07 20:30:15,100 [DEBUG] [doorpi.sipphone.from_linphone] using capture_device: ALSA: default device
2016-04-07 20:30:15,101 [DEBUG] [doorpi.sipphone.from_linphone] using playback_device: ALSA: default device

Erster Effekt: doorpi spielt sein empfangenes Audio über das default device = bcm2835 ab - klar, ist der Default
Zweiter Effekt: Wiederum kein gesendetes Audio.

Hier liegt offenbar irgendein Problem mit der Device-Erkennung von doorpi vor, denn eigentlich ist ja bcm2835 das default device, und es hat eben KEINEN rec-Kanal.

Also warum wird hier die USB-Karte nicht gefunden ? Wie kommt doorpi darauf, dass das default device aufnehmen könne ?

Folgerichtig gibt es dann im Weiteren noch die Fehlermeldung

[doorpi.sipphone.from_linphone] also error in pcm_hw.c:1557 - open '/dev/snd/pcmC1D0c' failed (-2)

Klar - doorpi versucht, den Recording-Kanal (D0c) vom default device (C1) aufzumachen, den es nicht gibt. Es gibt als Recording-Kanal eben nur /dev/snd/pcmC0D0c - das ist die USB-Soundkarte.

Hilft zwar bisher möglicherweise, doorpi zu verbessern - aber mir noch nicht weiter...

LG

pah

OK, machen wir es nochmal.

/etc/modprobe.d/alsa-base.conf entfernt => 1. Karte = card 0 ist der interne bcm2835, 2. Karte = card 1 ist das USB-Teil.

Korrekterweise liefert
cat /proc/asound/cards | grep ]: | sed 's/.* - //'
bcm2835 ALSA
USB PnP Sound Device

in der doorpi.ini steht
capture_device = ALSA: USB PnP Sound Device
playback_device = ALSA: USB PnP Sound Device

doorpi_cli liefert als vollständiges Log die hier angehängte Datei test1.txt

Wie man daran sieht, wählt doorpi die richtigen devices aus.

Auf Knopfdruck ruft doorpi ganz korrekt ein Telefon meiner FritzBox an, ich kann auch ins Telefon sprechen und höre mich am Raspberry - nur umgekehrt nicht. Ich kann auch den Türöffner betätigen, alles OK - bis auf das Mikrofonsignal vom Raspberry. Stöbern in der Logdatei: da gibt es wieder die Fehlermeldung

2016-04-07 21:33:36,601 [INFO] [doorpi.sipphone.from_linphone] also error in pcm_hw.c:1557 - open '/dev/snd/pcmC0D0c' failed (-2)

Warum ? doorpi versucht, den capture-Kanal D0c von Card 0 aufzumachen, den es gar nicht gibt - wie kommt es darauf ?

Und kurze Zeit darauf:

2016-04-07 21:34:09,487 [ERROR] [doorpi.sipphone.from_linphone] snd_pcm_avail_update: Datenübergabe unterbrochen (broken pipe)
2016-04-07 21:34:09,488 [ERROR] [doorpi.sipphone.from_linphone] *** alsa_can_read fixup, trying to recover
2016-04-07 21:34:09,488 [INFO] [doorpi.sipphone.from_linphone] also error in pcm.c:7843 - overrun occurred

Pustekuchen.

Ihr seht mich willig und wenigstens durchschnittlich begabt - aber hier tappe ich im Dunklen. Bin für jeden Hinweis dankbar.

LG

pah

Als Antwort auf den Doppelpost - vielleicht bekomme ich ja auch etwas auf die Finger ;-))

- reboot schon tausende Male ausgeführt, ohne Effekt. Konnte die USB-Karte auch im alsamixer sehen, das wars nicht

- config-Datei: Mag sein, ist aus diversen Posts im Netz zusammengebastelt. Ich habe aber nirgendwo eine Erläuterung zur aktuellen Fassung der Konfig-Datei gefunden.

LG

pah