(gelöst) bluealsa, ~/.asoundrc

Sound, Digitalkameras, TV+Video und Spiele.
Benutzeravatar
smutbert
Moderator
Beiträge: 8318
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: bluealsa, ~/.asoundrc

Beitrag von smutbert » 20.04.2020 11:59:46

Auf alles ein ja. Du kannst die Abschnitte auch vertauschen. Ein paar Anmerkungen habe ich trotzdem:

zu 2. und 8. ("type softvol" bzw. "type bluealsa")
Dass es sich dabei um die Instanz eines Plugins handelt ist eigentlich schon nach dem "pcm.GO2_SOFTVOL {" bzw. "pcm.GO2 {" klar. Eine andere Möglichkeit gibt es nämlich nicht. Es geht bei "type X" nur mehr darum festzulegen um welches Plugin es sich dreht.

zu 3. (slave.pcm "GO2")
Die meisten der Plugins geben die Audiodaten nach der Verarbeitung, in dem Fall also nach dem Ändern der Lautstärke, an ein weiteres pcm.X also eine weitere Instanz irgendeines Plugins weiter. "slave.pcm" sagt an wohin die Audiodaten weitergereicht werden sollen.

zu 8. ("type bluealsa")
bluealsa gehört offensichtlich zu den Ausnahmen der eben aufgestellten Behauptung: Es leitet die Audiodaten nicht an ein weiteres pcm.X weiter sondern liefert sie beim beim Bluetoothtreiber ab.

zu 10. ("device "30:C0:1B:72:63:8E"")
Nicht wegen der Authorisierung sondern viel mehr um festzulegen an welches Bluetoothgerät die Audiodaten geleitet werden sollen.

zu 11. ("profile "a2dp"")
Das ist nur das Protokoll mit dem der Bluetooth-Controller die Audiodaten an den Lautsprecher sendet. Was zwischen Anwendung, Ding1 und Ding2 abläuft wird dadurch nicht beeinflusst.



Die geschwungenen Klammern sind nebenbei bemerkt nur eine mögliche Schreibweise. Ich bin mir bei der Syntax nicht ganz sicher und kann nicht ausprobieren ob ich es fehlerfrei hinbekommen habe, aber dasselbe lässt sich glaube ich grunsätzlich auch komplett ohne Klammern schreiben:

Code: Alles auswählen

pcm.GO2_SOFTVOL.type		softvol
pcm.GO2_SOFTVOL.slave.pcm	"GO2"
pcm.GO2_SOFTVOL.control.name	"Bluetooth"
pcm.GO2_SOFTVOL.control.card	"Intel"

pcm.GO2.type			bluealsa		# für Bluetooth zuständiges Alsa-Plugin
pcm.GO2.type.interface		"hci0"			# Name des Bluetooth-Adapters
pcm.GO2.type.device		"30:C0:1B:72:63:8E"	# MAC-Adresse des Bluetoothgeräts (via bluetoothctl)
pcm.GO2.type.profile		"a2dp"			# Bluetooth-Profil
Zuletzt geändert von smutbert am 20.04.2020 16:33:24, insgesamt 1-mal geändert.

fischig
Beiträge: 3600
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: bluealsa, ~/.asoundrc

Beitrag von fischig » 20.04.2020 13:41:17

zu 10. ("device "30:C0:1B:72:63:8E"")
Nicht wegen der Authorisierung sondern viel mehr um festzulegen an welches Bluetoothgerät die Audiodaten geleitet werden sollen.
Sollte er das nicht schon durch „hci0“ wissen?

Benutzeravatar
smutbert
Moderator
Beiträge: 8318
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: bluealsa, ~/.asoundrc

Beitrag von smutbert » 20.04.2020 16:33:15

Nein, es können viele Bluetoothgeräte gleichzeitig mit einem Computer verbunden sein. Wenn nur ein audiofähiges Gerät darunter ist, könnte bluealsa natürlich schlau genug sein auch das zu verwenden, aber ich würde nicht damit rechnen, dass dem so ist.
Schöner ist es auf jeden Fall explizit das gewünschte Gerät anzugeben.

fischig
Beiträge: 3600
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: bluealsa, ~/.asoundrc

Beitrag von fischig » 20.04.2020 17:57:57

Ok, ich habe bisher nur diesen einen BT-Lautsprecher verwendet und ging davon aus, dass jedes weitere BT-Gerät eine andere Gerätedatei bekommt. Die Annahme dürfte dann falsch sein.

fischig
Beiträge: 3600
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: bluealsa, ~/.asoundrc

Beitrag von fischig » 24.04.2020 20:31:50

Bevor ich auf deine PN eingehen kann: Ich habe mir leider meine schöne funktionierende Konfiguration zerschossen. :cry: , womöglich, weil ich versucht habe, den Lautsprecher auch an einem anderen Debian-Rechner (mit anderem(!) USB-Controller) zu benutzen. Auch in Bezug auf meine früheren Tests ging ich davon aus, dass lediglich die Mitnahme des (USB-)Controllers problematisch sei, das scheint aber nicht der Fall zu sein. Benutzung eines externen Lautsprechers an einem anderen Debian-Rechner scheint nicht vorgesehen zu sein, auch wenn der über seinen eigenen Controller verfügt. Ich bin mittlerweile nach einigen Klimmzügen wieder soweit, dass sich der Lautsprecher auf dem 1. System wieder automatisch verbindet (bluetoothctl, info), aber Töne kommen noch nicht/nicht mehr aus diesem Lautsprecher. Ich melde mich wieder, wenn ich relevante Meldungen beisammen habe.

fischig
Beiträge: 3600
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: bluealsa, ~/.asoundrc

Beitrag von fischig » 25.04.2020 20:31:55

So, fasse ich mal zusammen:

rfkill:

Code: Alles auswählen

# rfkill list
0: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no
1: eeepc-wlan: Wireless LAN
	Soft blocked: no
	Hard blocked: no
2: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
.asoundrc:

Code: Alles auswählen

pcm.GO2_SOFTVOL {
  type softvol
  slave.pcm "GO2"
  control.name "GO2"
  control.card 0
}

# Parameter für die Benutzung des BT-Lautsprechers
pcm.GO2 {
  type bluealsa			# Alsa-Plugin für Bluetooth
  interface "hci0"		# Name des Bluetooth-Adapters
  device "30:C0:1B:72:63:8E"	# MAC-Adresse des BT-Lautsprechers
  profile "a2dp"		# Bluetooth-Profil
}
bluetoothctl:

Code: Alles auswählen

[NEW] Controller 00:1A:7D:DA:71:13 BlueZ 5.43 [default]
[NEW] Device 30:C0:1B:72:63:8E JBL GO 2
[JBL GO 2]# info 30:C0:1B:72:63:8E
Device 30:C0:1B:72:63:8E
	Name: JBL GO 2
	Alias: JBL GO 2
	Class: 0x200414
	Icon: audio-card
	Paired: yes
	Trusted: yes
	Blocked: no
	Connected: yes
	LegacyPairing: no
	UUID: Headset                   (00001108-0000-1000-8000-00805f9b34fb)
	UUID: Audio Sink                (0000110b-0000-1000-8000-00805f9b34fb)
	UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
	UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
	UUID: Handsfree                 (0000111e-0000-1000-8000-00805f9b34fb)
[JBL GO 2]# 
aplay:

Code: Alles auswählen

$ aplay -D GO2_SOFTVOL [xyz].wav
ALSA lib bluealsa-pcm.c:679:(_snd_pcm_bluealsa_open) Couldn't get BlueALSA transport: Kein passendes Gerät gefunden
aplay: main:788: Fehler beim Öffnen des Gerätes: Kein passendes Gerät gefunden
ebenso:

Code: Alles auswählen

$ aplay -D bluealsa:HCI=hci0,DEV=30:C0:1B:72:63:8E,PROFILE=a2dp [xyz].wav
ALSA lib bluealsa-pcm.c:679:(_snd_pcm_bluealsa_open) Couldn't get BlueALSA transport: Kein passendes Gerät gefunden
aplay: main:788: Fehler beim Öffnen des Gerätes: Kein passendes Gerät gefunden
Un' nu?

Benutzeravatar
smutbert
Moderator
Beiträge: 8318
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: bluealsa, ~/.asoundrc

Beitrag von smutbert » 25.04.2020 21:06:36

Mir bleibt die Fehlerursache genauso verborgen wie dir.
Hast du versucht den bluealsa-Dämon mit der Option --disable-hfp zu starten - möglicherweise hat er sich beim neu Pairen mit dem falschen Protokoll verbunden und sich das gemerkt (dann wüßtest du jetzt wofür --disable-hfp gut ist)?
Du könntest auch in die Datei »/var/lib/bluetooth/00:1A:7D:DA:71:13/30:C0:1B:72:63:8E/info« (oder so ähnlich) schauen – möglicherweise steht da das (zuletzt) verwendete Protokoll drin.


Ansonsten fällt mir nur ein mit dem Pairing von vorne anzufangen, vielleicht hilft das
  • Während der Bluetoothlautsprecher außer Reichweite oder ausgeschaltet ist, am Computer das Verzeichnis »/var/lib/bluetooth/00:1A:7D:DA:71:13/30:C0:1B:72:63:8E« oder wenn du Bluetooth nur für den Lautsprecher nutzt, dann gleich das komplette „/var/lib/bluetooth/00:1A:7D:DA:71:13“ löschen und den Computer herunterfahren
  • Falls möglich den Bluetoothlautsprecher auf die Werkseinstellungen zurücksetzen und Ausschalten
  • Dann neu Pairen und Verbinden (falls letzteres nicht automatisch passiert).
An der Konfiguraton von Alsa (~/.asoundrc) oder mplayer solltest du jedenfalls natürlich nichts ändern müssen.

fischig
Beiträge: 3600
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: bluealsa, ~/.asoundrc

Beitrag von fischig » 25.04.2020 21:21:54

smutbert hat geschrieben:Hast du versucht den bluealsa-Dämon mit der Option --disable-hfp zu starten
Hab' ich. Ich versuch's nochmal, man weiß ja nie, insbesondere bei mir! :oops:
Übrigens, es gibt da im Rasperry-Netz-Umfeld noch andere Optionen für bluealsa, mit denen da rumjongliert wird. Links habe ich leider nicht notiert.

Danke für deine weiteren Tipps, ich geh' sie durch! Sag mal bitte was zu BT-Lautsprechermobilität. Ist das tatsächlich nicht vorgesehen? Schiene mir dann ein dicker Fehler zu sein.

Benutzeravatar
smutbert
Moderator
Beiträge: 8318
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: bluealsa, ~/.asoundrc

Beitrag von smutbert » 25.04.2020 22:40:18

Etwas ist mir noch eingefallen:
bluealsa, also der Dämon gibt Meldungen aus. Wenn den also einmal in einem Terminalfenster starten könntest oder wahlweise die Ausgaben in einer Logdatei umleitest, dann sehen wir ob sich PC und Lautsprecher mit A2DP verbinden oder nicht und/oder möglicherweise auch andere Hinweise auf die Fehlerursache.
fischic hat geschrieben: ↑ zum Beitrag ↑
25.04.2020 21:21:54
Danke für deine weiteren Tipps, ich geh' sie durch! Sag mal bitte was zu BT-Lautsprechermobilität. Ist das tatsächlich nicht vorgesehen? Schiene mir dann ein dicker Fehler zu sein.
Dazu hätte ich etwas geschrieben, sobald du den Lautsprecher auf dem ersten PC wieder zum laufen bekommen hast. Im Prinzip ist es zweifelsohne vorgesehen, aber nicht alles was vorgesehen ist funktioniert auch. ☺

Bluetooth glänzt, speziell unter GNU/Linux, nicht gerade mit Zuverlässigkeit (aber ich habe auch unter MacOS und Android schon merkwürdige Sachen erlebt) und wie viele Pairing-Partner sich ein Bluetoothgerät überhaupt merkt, hängt komplett vom Gerät ab.
Wenn sich das Gerät nur einen Pairing-Partner merkt oder andere Schwierigkeiten beim Verwenden mit mehreren Computern macht (zB wenn das Pairing an sich nur selten auf Anhieb glatt läuft), dann kopiere ich die Pairing-Informationen von einem System auf das andere – im Normalfall funktioniert das. In deinem Fall müsstest du »/var/lib/bluetooth/00:1A:7D:DA:71:13/30:C0:1B:72:63:8E« auf den anderen Computer kopieren und zwar nach »/var/lib/bluetooth/YY:YY:YY:YY:YY:YY/30:C0:1B:72:63:8E«.
YY:YY:YY:YY:YY:YY steht für die Mac-Adresse des Bluetooth-Controllers des anderen Computers. (Nachdem beide Verzeichnisse bereits existieren sollten, kopierst also nur das Unterverzeichnis 30:C0:1B:72:63:8E von dem einen auf den anderen Computer.)

fischig
Beiträge: 3600
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: bluealsa, ~/.asoundrc

Beitrag von fischig » 26.04.2020 10:31:32

Da ich den bluealsa-Start in /etc/rc.local geschreiben hatte, gehe ich davon aus, dass, händisch gestartet, root das tun sollte.

Hier die Meldung:

Code: Alles auswählen

# /usr/bin/bluealsa: Couldn't initialize controller thread: Bad file descriptor
Es gibt dazu ein paar (nicht besonders taufrische) Threads im Netz, z.B :
https://github.com/Arkq/bluez-alsa/issues/126

Code: Alles auswählen

https://github.com/Arkq/bluez-alsa/issues/149
aus denen ich aber nicht recht schlau werde, insbesondere nicht, was das Löschen der „Datei“(?) =hci0 unter (/var)/run/bluealsa angeht. Das habe ich versucht, aber ob systematisch genug, kann ich aufgrund meines mangelhaften Verständnisses dieser (englischsprachigen) Threads nicht sagen.

Wenn's dir auch nicht mehr sagt, werde ich wohl die anderen Tipps angehen müssen.

Benutzeravatar
smutbert
Moderator
Beiträge: 8318
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: bluealsa, ~/.asoundrc

Beitrag von smutbert » 26.04.2020 13:47:51

Du kannst ja bluealsa auch im Terminal als root starten?
Wenn es das Problem aus deinem Link ist, dann verbinden sich Lautsprecher und Computer tatsächlich mit dem falschen Protokoll. Dort wird dagegen statt --disable-hsp die Option -p a2dp-source empfohlen.
(Ich weiß ehrlich gesagt nicht ob hsp und hfp dasselbe Protokoll oder zwei verschiedene eng verwandte Protokolle sind und mir ist auch nicht klar warum das Problem jetzt auftritt und nicht schon nach dem ersten Einrichten – daher habe ich auch im vorigen Beitrag vorgeschlagen, alles zu löschen wo sich vergangene Bluetoothverbindungseinstellungen verstecken können und von vorne anzufangen.)

Mach es doch einmal folgendermaßen:
- Kommentier bluealsa in der rc.local aus. damit es nicht automatisch gestartet wird und schalte den Bluetooth-Lautsprecher erst einmal aus
- Starte den Computer (neu) und mach ein Terminalfenster auf in dem du dann bluealsa als root mit dem Befehl

Code: Alles auswählen

# bluealsa -p a2dp-source
startest
- schalte den Bluetoothlautsprecher ein und schau wann sich was sich bei der Ausgabe von bluealsa tut und probier es mit der Wiedergabe klappt.


Dasselbe kannst du dann auch noch mit anderen bluealsa-Optionen wiederholen

Code: Alles auswählen

# bluealsa --disable-hsp
# bluealsa --disable-hfp
# bluealsa --disable-hfp --disable-hsp -p a2dp-source

fischig
Beiträge: 3600
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: bluealsa, ~/.asoundrc

Beitrag von fischig » 26.04.2020 15:22:59

# bluealsa -p a2dp-source
Funktioniert nicht. Wenn ich recht sehe, dann gibt's auch

Code: Alles auswählen

-p a2dp-source
nicht als mitzugebende Option (bluealsa --help). Das funktioniert wohl, wenn überhaupt, nur über eine in /etc/init.d zu erstellende .conf. Ob man das von Rasperry auf einen i386-PC übertragen kann - keine Ahnung.

Nun ja, kaputt ist's sowieso. Wenn du keinen anderen Rat mehr hast, dann versuche ich's mit einem Neuanfang, einschließlich Neuinstallation von bluealsa - wenn schon, denn schon :wink: .

Nebenbei: so langsam geht mir das Bluetooth-Gerödel auf den Wecker. Ich könnte den Lautsprecher per Klinke mit dem eeepc verbinden. Dann wär's halt nix mehr mit der Mobilität des Lautsprechers, aber ich finde kein geeignetes kurzes Kabel (ca.0,5m Länge). Für meinen TP T430 wäre Lautsprecher-Mobilität unwichtig, aber der hat keine Klinkensteckdose mehr.

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: bluealsa, ~/.asoundrc

Beitrag von Tintom » 26.04.2020 16:14:58

Ich oute mich mal als stiller Mitleser. Danke für dieses Thema und die Beharrlichkeit beim Problemlösen!

Was mich stutzig macht:
fischic hat geschrieben: ↑ zum Beitrag ↑
26.04.2020 15:22:59
Für meinen TP T430 wäre Lautsprecher-Mobilität unwichtig, aber der hat keine Klinkensteckdose mehr.
Neben dem VGA-Anschluss sieht etwas verdächtig nach Klinke aus: https://thinkwiki.de/images/8/8e/T430_LinkeSeite.jpg

fischig
Beiträge: 3600
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: bluealsa, ~/.asoundrc

Beitrag von fischig » 26.04.2020 16:27:01

Tintom hat geschrieben:Neben dem VGA-Anschluss sieht etwas verdächtig nach Klinke aus:
Stimmt! Warum ist der nicht grün? Diese chinesischen Newcomer halten sich an keinerlei Konventionen! Empörend! :mrgreen:
Tintom hat geschrieben:Danke für dieses Thema und die Beharrlichkeit beim Problemlösen!
Danke für die Blumen! Ich bin nicht so der Fitteste in IT-Angelegenheiten, aber eine gewisse Hartnäckigkeit schreibe ich mir schon zu. :wink: Und ohne smutbert wäre ich hier wohl ziemlich aufgeschmissen! :THX:

Benutzeravatar
smutbert
Moderator
Beiträge: 8318
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: bluealsa, ~/.asoundrc

Beitrag von smutbert » 26.04.2020 17:39:23

fischic hat geschrieben: ↑ zum Beitrag ↑
26.04.2020 15:22:59
# bluealsa -p a2dp-source
Funktioniert nicht. Wenn ich recht sehe, dann gibt's auch

Code: Alles auswählen

-p a2dp-source
nicht als mitzugebende Option (bluealsa --help). Das funktioniert wohl, wenn überhaupt, nur über eine in /etc/init.d zu erstellende .conf. Ob man das von Rasperry auf einen i386-PC übertragen kann - keine Ahnung.
In die .conf-Datei schreibst du auch nichts anderes als die Optionen, mit denen bluealsa gestartet wird, das läuft also auf dasselbe hinaus. Dass es die Option bei dir nicht gibt heißt nur, dass deine Version älter ist als in dem verlinkten Fehlerbericht, aber das macht nichts, weil sie eh dieselbe Funktion erfüllt wie --disable-hfp und --disable-hsp. (Diese Änderung war in deinem Link genau die Fehlerursache.)

Bei gleichen Versionen kann man das schon zwischen PC und RPi übertragen.

fischic hat geschrieben: ↑ zum Beitrag ↑
26.04.2020 15:22:59
Nun ja, kaputt ist's sowieso. Wenn du keinen anderen Rat mehr hast, dann versuche ich's mit einem Neuanfang, einschließlich Neuinstallation von bluealsa - wenn schon, denn schon :wink: .
Eine Neuinstallation von bluealsa ist bestimmt nicht notwendig. Wir müssen nur finden/löschen wo der Lautsprecher, bluez oder bluealsa irgendetwas unpassendes zwischengespeichert hat und eigentlich würde ich hoffen, dass das bei meinem Vorschlag dabei ist, wenn ich mich selbst ztiteren darf:
smutbert hat geschrieben: ↑ zum Beitrag ↑
25.04.2020 21:06:36
  • Während der Bluetoothlautsprecher außer Reichweite oder ausgeschaltet ist, am Computer das Verzeichnis »/var/lib/bluetooth/00:1A:7D:DA:71:13/30:C0:1B:72:63:8E« oder wenn du Bluetooth nur für den Lautsprecher nutzt, dann gleich das komplette „/var/lib/bluetooth/00:1A:7D:DA:71:13“ löschen und den Computer herunterfahren
  • Falls möglich den Bluetoothlautsprecher auf die Werkseinstellungen zurücksetzen und Ausschalten
  • Dann neu Pairen und Verbinden (falls letzteres nicht automatisch passiert).
Wobei ich beim letzten Schritt noch hinzufügen möchte, dass es vielleicht ganz gut wäre bluealsa sicherheitshalber wieder mit der Option --disable-hfp und eventuell auch --disable-hsp zu starten.

fischig
Beiträge: 3600
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: bluealsa, ~/.asoundrc

Beitrag von fischig » 26.04.2020 18:36:46

Hmmm, also woran's jetzt gelegen hat, kriege ich in dem Chaos nicht mehr zusammen. Aber es funtkioniert alles wieder fehlerfrei!

Was ich gemacht habe:

Erst mal alles was im Verdacht stand mit der Fehlfunktion zusammenzuhängen gelöscht: (/var)/run/bluealsa/=hci0, dann wie von dir schon weiter oben vorgeschlagen, alles unter /var/lib/bluetooth/00:1A:7D:DA:71:13. Bluealsa-Eintrag in /etc/rc.local auskommentiert. Hatte ich vorher schon durchgeführt. Meine letzten Meldungsmitteilungen bezogen sich schon auf händisches Starten von bluealsa (s.o.)
Wie angekündigt, bluealsa neu installiert (Version 0.9). Händisches Starten brachte nur verschiedene mir chaotisch erscheinende Fehlermeldungen. Dennoch wurde anscheinend bluealsa „korrekt“ gestartet, jedenfalls deute ich das folgende so: Ich habe das erst mal „beiseite gelegt“ und mich der Neu-Einrichtung des Lautsprechers via bluetoothctl gewidmet. Das hat funktioniert. Beim „connect“ brauchte ich mehrere Versuche. Anschließend konnte ich meine wav via aplay -D GO2_SOFTVOL [xyz].wav aus dem BT-Lautsprecher hören, ebenso wie sämtliche eingerichteten Radiosender via mplayer.
In rc.local steht jetzt nur:

Code: Alles auswählen

/usr/bin/bluealsa &
Weiterhin keine Fehler nach erneutem Reboot.

und wenn ich bluealsa --help richtig lese, dann gibt's bei meiner Version auch kein --disable-hfp (mehr?)

Code: Alles auswählen

Usage:
  bluealsa [OPTION]...

Options:
  -h, --help		print this help and exit
  -V, --version		print version and exit
  -S, --syslog		send output to syslog
  -i, --device=hciX	HCI device to use
  -p, --profile=NAME	enable BT profile
  --a2dp-force-mono	force monophonic sound
  --a2dp-force-audio-cd	force 44.1 kHz sampling
  --a2dp-volume		control volume natively

Available BT profiles:
  - a2dp-source	Advanced Audio Source (SBC)
  - a2dp-sink	Advanced Audio Sink (SBC)
  - hfp-hf	Hands-Free (v1.7)
  - hfp-ag	Hands-Free Audio Gateway (v1.7)
  - hsp-hs	Headset (v1.2)
  - hsp-ag	Headset Audio Gateway (v1.2)

By default only output profiles are enabled, which includes A2DP Source and
HSP/HFP Audio Gateways. If one wants to enable other set of profiles, it is
required to explicitly specify all of them using `-p NAME` options.
und a2dp wird wohl defaultmäßig benutzt, wenn ich das Englisch im Letzten Absatz richtig verstehe.

Interessiert jemanden meine menu.xml bezüglich der Sendereinrichtung mit mplayer?

fischig
Beiträge: 3600
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: bluealsa, ~/.asoundrc

Beitrag von fischig » 26.04.2020 21:06:51

So, ich glaube, ich habe einen Übeltäter ausfindig gemacht. Wenn meine Frau Radio hört über ihren Taschenrechner mit Telefoniefunktion (Android), und dabei den BT-Lautsprecher benutzt, dann ist selbiger danach unter Debian Stretch und bluealsa erstmal nicht mehr benutzbar. Die vorherige Konfiguration am Debian-System unter /var/lib/bluetooth bleibt erhalten, ob verändert oder nicht, weiß ich nicht, wäre vielleicht zu überprüfen.

Ich habe dann folgendes gemacht: bluealsa in /etc/rc.local auskommentiert alles unterhalb und einschließlich des Controller-MAC-Verzeichnisses unter /var/lib/bluetooth gelöscht. Dann System-Neustart. Dann Neueinrichtung des Lautsprechers via bluetoothctl wie von Kofler beschrieben im Terminal bis zum trust. Ein connect (Attempting to connect to ...) versucht bluetoothctl in diesem Stadium gar nicht erst, es kommt immer nur permanent der bluez.Error. Bluetoothctl nicht beendet. Händische Aktivierung von bluealsa als root im 2. Terminal mit dem gleichen, aber immer noch auskommentierten Kommando wie in /etc/rc.local. Bluetoothctl reagiert selbständig mit Meldungen zum Controller im 1. Terminal.
Erneuter connect-Versuch im 1. Terminal, jetzt kommt „Attempting to connect to ...“ und nach mehr oder weniger zahlreichen Versuchen gibt bluetoothctl nach mit der Meldung „Connected: yes“ und der Lautsprecher den signifikanten Ton von sich. Ab jetzt funktioniert der BT-Lautsprecher wieder. bluealsa in /etc/rc.local reaktiviert und nach Neustart funktioniert's immer noch.

Soweit, so schlecht! Das kann's doch eigentlich nicht sein! Verbesserungsvorschläge?
Zuletzt geändert von fischig am 26.04.2020 21:14:47, insgesamt 1-mal geändert.

Benutzeravatar
smutbert
Moderator
Beiträge: 8318
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: bluealsa, ~/.asoundrc

Beitrag von smutbert » 26.04.2020 21:12:50

Kann es sein, dass das Smartphone deiner Frau noch einigermaßen in Bluetooth-Sende-/Empfangsreichweite war?

Zum vorvorigen Post:

Genau, jetzt hast du die neuere Version. Der letzte Absatz sagt nur, dass per default mit den Protokollen nur Ausgabegeräte (Lautsprecher) und keine Eingabe- oder besser Aufnahmegeräte (Mikrofone) genutzt werden können. Wenn du sicherstellen willst, dass sich kein Gerät mit hfp/hsp verbindet brauchst du jetzt die Option, die der alten Version unbekannt war ("-p a2dp-source" wobei wir natürlich immer noch nicht wissen ob das jetzt notwendig sein kann oder nicht).

fischig
Beiträge: 3600
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: bluealsa, ~/.asoundrc

Beitrag von fischig » 26.04.2020 21:21:33

smutbert hat geschrieben:Kann es sein, dass das Smartphone deiner Frau noch einigermaßen in Bluetooth-Sende-/Empfangsreichweite war?
Ja, das kann gut sein! Ich habe zwar darauf geachtet, dass der Radioempfang ausgeschaltet und die BT-Verbindung beendet wurde, aber daran habe ich nicht gedacht. Ich benutze so kein Ding. Jetzt muss ich wohl das ganze Gelumpe nochmal machen, um etwas mehr Klarheit zu erhalten. :evil:
smutbert hat geschrieben:Wenn du sicherstellen willst, dass sich kein Gerät mit hfp/hsp verbindet brauchst du jetzt die Option, die der alten Version unbekannt war ("-p a2dp-source"
Ok, ich versuch' diese Option. Andererseits geht's ja gerade darum, dass der Lautsprecher auch dem Taschenrechner zur Verfügung stehen sollte.

fischig
Beiträge: 3600
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: bluealsa, ~/.asoundrc

Beitrag von fischig » 27.04.2020 16:18:32

Ich versuche mich gerade an deinem PN-Vorschlag: „zum Umschalten im laufenden Betrieb“

Laden von snd_aloop nur via modprobe, noch nicht eingetragen in /etc/modules.
Für

Code: Alles auswählen

$ alsaloop -C plughw:Loopback,1
muss ich beim Testen ein zweites Terminal öffnen, während im 1. Terminal läuft:

Code: Alles auswählen

$ mplayer -ao alsa:device=plughw=Loopback -really-quiet -prefer-ipv4 -playlist /home/thekla/.system/radiosender/hrinfo_2.m3u
- richtig? Das funktioniert tadellos.

Einschränkung: nach einigen Sekunden wird der Ton kratzig, so als ob sich da zwei Tonquellen überlagern.

Breche ich jetzt im 2.Terminal ab und starte dort stattdessen

Code: Alles auswählen

$ alsaloop -C plughw:Loopback,1 -P GO2_SOFTVOL
kommt kein Ton, nur Fehlermeldung:

Code: Alles auswählen

underrun for playback GO2_SOFTVOL

Benutzeravatar
smutbert
Moderator
Beiträge: 8318
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: bluealsa, ~/.asoundrc

Beitrag von smutbert » 27.04.2020 17:06:15

Nachdem wir hier ja auch noch mindestens einen weitgehend stillen Mitleser haben, erlaube ich mir an dieser Stelle (sinngemäß) zu posten, was ich dir geschrieben habe. Es geht darum mit Alsa (und ohne Pulseaudio) bei laufender Audiowiedergabe zwischen verschiedenen Audiogeräten umzuschalten.
Das ganze läuft so ab, dass die Wiedergabe über eine virtuelle Soundkarte läuft von der das Audiosignal erst wieder aufgenommen und über die gewünschte reale Audiohardware ausgegeben wird.
  1. Die virtuelle Soundkarte wird mit dem Laden des Moduls snd-aloop eingerichtet

    Code: Alles auswählen

    # modprobe snd-aloop
    
    Durch eintragen des Moduls in der »/etc/modules« passiert das beim Systemstart automatisch.
  2. Das Audioprogramm, in dem Fall, mplayer muss dann den Ton über die virtuelle Soundkarte ausgeben

    Code: Alles auswählen

    $ mplayer -ao alsa:device=plughw=Loopback -really-quiet -prefer-ipv4 irgendeine/Audiodate.wav
    
  3. Nachdem über die virtuelle Soundkarte noch nichts zu hören ist, muss das Audiosignal wie angekündigt erst aufgenommen und über die echte Hardware wiedergegeben werden, das sollte mit diesen beiden Befehlen klappen, für die eingabauten Lautsprecher (dem default-Gerät von Alsa)

    Code: Alles auswählen

    $ alsaloop -C plughw:Loopback,1
    
    und für den über die »~/.asoundrc« eingerichteten Blueteoothlautsprecher

    Code: Alles auswählen

    $ alsaloop -C plughw:Loopback,1 -P GO2_SOFTVOL -t 20000
    
und zur Anwort auf deinen letzten Beitrag

Ja, genau.
Läuft alsaloop nach der underrun-Fehlermeldung weiter oder war es das?

Ändert sich etwas, wenn du dem Befehl mit einer Option eine Latenz mitgibst (underrun bedeutet, dass der Datenstrom sozusagen abreisst - ob das auch die Ursache ist, dass es still bleibt weiß ich noch nicht, aber das sollte sich mit einer höheren Latenz lösen lassen):

Code: Alles auswählen

$ alsaloop -C plughw:Loopback,1 -P GO2_SOFTVOL -t 20000
Wenn das auch nicht funktioniert gäbe es auch noch genug Alternativen zu alsaloop, die möglicherweise besser funktionieren könnten (womit wir möglicherweise auch die Kratzigkeit loswerden könnten, deren Ursache sich mir auch noch nicht erschließen will).

fischig
Beiträge: 3600
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: bluealsa, ~/.asoundrc

Beitrag von fischig » 27.04.2020 19:23:15

Also, mit

Code: Alles auswählen

$ alsaloop -C plughw:Loopback,1
kommt zunächt:

Code: Alles auswählen

playback hw:0,0: change avail_min 1434
-(1458) und nach einigen Sekunden/Minuten kommt dann

Code: Alles auswählen

underrun for playback hw: 0,0
und es kratzt.

mit

Code: Alles auswählen

alsaloop -C plughw:Loopback,1 -P GO2_SOFTVOL -t 2000
(ich hatte eine 0 zu wenig gelesen) kam zunächst overrun ich bin dann runter bis auf 2, same procedure, dann hoch auf die vorgeschlagenen 20000 und da meinte er dann merkwürdigerweise underrun. und dabei blieb er auch, egal welches -t ich wählte. Sonst kam nichts, kein Ton.

Die Radiosender funktionieren außerhalb alsaloop störungsfrei mit bluealsa, internem und BT-Lautsprecher.

Benutzeravatar
smutbert
Moderator
Beiträge: 8318
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: bluealsa, ~/.asoundrc

Beitrag von smutbert » 27.04.2020 23:05:24

overrun ist merkwürdig. Ich glaube mit alsaloop oder einem entsprechenden arecord | aplay-Gespann kommen wir hier nicht weiter. Bevor ich dir jetzt Alternativen zu alsaloop genau beschreibe würde ich das gerne selbst testen. Allerdings habe ich es glaube ich ja schon in meiner PN erwähnt, dass mein Computer gerade nicht so will wie ich – bis ich das gelöst habe und so etwas selbst ausprobieren kann, wird es möglicherweise etwas dauern.

Immerhin kann ich dir grob sagen was ich probieren will:
ich hätte mit rec aufgenommen und mit play (beides aus dem Paket Debiansox) wieder abgespielt. Im Prinzip würde der Befehl so aussehen

Code: Alles auswählen

$ rec | play
aber ich weiss nicht ob Optionen notwendig sind um das Format der Audiodaten anzugeben und wie ich rec und play klar mache welche Audiogeräte sie verwenden sollen.

Ich glaube, dass bluealsa das Problem ist. Das ist in alsa ein bisschen ein Fremdkörper, weil es sich etwas anders verhält als andere direkt in Alsa integrierte Hardwaretreiber (die Overrungs ergeben meiner Meinung nach keinen Sinn). Das mit den underruns und dem Kratzen ist nur ein zusätzliches, vergleichsweise kleines Problem, das sich mit anderen Programmen wahrscheinlich automatisch erledigt.

fischig
Beiträge: 3600
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: bluealsa, ~/.asoundrc

Beitrag von fischig » 28.04.2020 08:55:45

mein Computer (will) gerade nicht so wie ich – bis ich das gelöst habe und so etwas selbst ausprobieren kann, wird es möglicherweise etwas dauern.
Ich kann warten - und Ansprüche stell' ich sowieso nicht.

Falls du dennoch Zeit und Lust hast, weiter hier zu lesen:
Ich habe mal testweise dem rc.local-Eintrag die Option "-p a2dp-source" mitgegeben: Ergebnis war: kein automatisches Verbinden des Lautsprechers nach dem Einschalten. Ergo: Wieder raus.

Weiter: beim Versuch, den BT-Lautsprecher an einem zweiten Rechner (TP T430) zu benutzen, habe ich deinen Tipp befolgt und das komplette Verzeichnis /var/lib/bluetooth/[Controller-Name]/[BT-Laut-MAC]/ vom eeepc auf diesen Rechner kopiert, ebenso die ~/.asoundrc. Verbinden des Lautsprechers funktioniert, aber aplay -D GO2_SOFTVOL /usr/share/sounds/alsa/Front_Center.wav bringt nur:

Code: Alles auswählen

Wiedergabe: WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate: 48000 Hz, mono
aplay: set_params:1305: Kanalanzahl nicht unterstützt
Wiedergabeversuch für eine „richtige“ WAV mit „aplay -D GO2_SOFTVOL /Pfad/zu/[xyz].wav“:

Code: Alles auswählen

Wiedergabe: WAVE '/Pfad/zu/[xyz].wav' : Unsigned 8 bit, Rate: 44100 Hz, stereo
aplay: set_params:1299: Sample-Format nicht unterstützt
Available formats:
- S16_LE
„aplay -D GO2_SOFTVOL -f S16_LE -f S16_LE /Pfad/zu/[xyz].wav“:

Code: Alles auswählen

Warnung: benutztes Format ist U8
Wiedergabe: WAVE '/Pfad/zu/[xyz].wav' : Unsigned 8 bit, Rate: 44100 Hz, stereo
aplay: set_params:1299: Sample-Format nicht unterstützt
Available formats:
- S16_LE
Funktioniert insbesondere das Kopieren des /var/lib/bluetooth/.../-Verzeichnisses nicht zwischen unterschiedlichen Architekturen (eeepc: i386/T430: amd64)?
Bevor ich den Lautsprecher jetzt auf dem T430 komplett neu zu paaren/verbinden versuche (und mir damit womöglich wieder die nach wie vor funktionierende Konfig auf dem eeepc zerschieße), wüsste ich gerne, ob meine Vermutung überhaupt plausibel ist.

fischig
Beiträge: 3600
Registriert: 24.12.2019 12:25:08
Lizenz eigener Beiträge: MIT Lizenz

Re: bluealsa, ~/.asoundrc

Beitrag von fischig » 01.05.2020 14:23:54

Ich komm' nochmal auf den kleinen Androiden zurück: Wir haben's nochmal getestet. An dessen Bluetooth sollte es, soweit ich das einzuschätzen vermag, nicht liegen. Der Androide wurde nach der Benutzung des BT-Lautsprechers komplett abgeschaltet und dennoch funktionierte anschließend die selbsttätige Verbindung des Lautsprechers mit dem eeepc nicht mehr. Es reichte allerdings, ihn via Bluetooth-Knopf am Lautsprecher und via bluetoothctl am eeepc neu zu verbinden.

Was das Thinkpad angeht, so werde ich wohl um's Risiko nicht herumkommen.

Antworten