(gelöst) Bluealsa mit simultaner Tonausgabe auf zwei Geräten

[fischig]

Danke sehr! Leider komme ich jetzt wohl erst wieder am Donnerstag dazu. Fahre ein paar Tage mit der Liebsten zum Wandern!

[fischig]

So, da bin ich wieder.
Ich habe deinen Code so kopiert: Teil1 und Teil 2 in eine .asoundrc.

Die Kopie funktioniert. Bis ich sie verdaut habe, werde ich wohl noch einiges erfragen müssen, aber das kommt später. Einstweilen sieht es so aus, dass ich die beiden abschließenden Kommandos nicht gleichzeitig laufen lassen kann. Ton entweder nur über plug:bt_ls oder nur über plug:bt_kh.

[smutbert]

Eigentlich war es schon so gedacht, dass die beiden gleichzeitig laufen können. Bluealsa kann das jedenfalls und so wie ich es beschrieben habe sollte es eigentlich auch klappen.

Allerdings bin ich nach deiner Schilderung auf eine mögliche Ursache gestossen. Viele (billige?) Bluetooth-Controller unterstützen so wie es aussieht (gleichzeitig) nur eine a2dp-Verbindung. Hier [1] hat das jemand offensichtlich mit zwei Bluetooth-Controllern (einer pro Bluetooth-Lautsprecher) gelöst.

[1] https://github.com/Arkq/bluez-alsa/issues/79

[fischig]

Kann es sein, dass ein sogenannter „SBC“ „codec“, was immer das sein mag, bei der simultanen Tonwiedergabe eine wichtige Rolle spielen mag? Dieser „codec“ spielt in deinem Link eine Rolle, und auch bei einem der von mir gefundenen Transmitter https://www.ebay.de/itm/TROND-Bluetooth ... 3356949317 ist die Rede davon, dass bei Simultanbetrieb der Transmitter auf diesen „codec“ zurückfällt. Hast du eine Idee, ob man bei dem aktuell von mir verwendeten Controller versuchen könnte, ihn auf diesen codec festzunageln?

Ich bin etwas ratlos, einen Controller zu finden, der Simultanwiedergabe sicher beherrscht - China und Preis hin oder her. Ich habe das noch in keiner Beschreibung gefunden.

[smutbert]

Ich kenne leider keine Möglichkeit den Codec festzulegen und weiß auch nicht ob/welche Bluetooth-Controller mehrere a2dp-Verbindungen unterstützen. Ich habe (mit unterschiedlichen Begründungen) die Behauptung gefunden, dass generell nur eine a2dp-Verbindung pro Bluetooth-Controller funktioniert (und auch gegenteilige Behauptungen).

Ausprobieren kann ich es mangels zweitem Bluetoothgerät mit meinem Bluetooth-Controller (einer von Intel) leider nicht.

[fischig]

Ich werde das morgen mal mit einem weiteren (Billig-)USB-Controller probieren. Wenn ich recht sehe, muss ich via bluetoothctl den einen Lautsprecher an hci0 löschen und mit dem zusätzlichen hci1 neu verbinden und natürlich so in den Code einfügen. Lieber wär's mir schon gewesen, das mit einem Controller hinzukriegen. so dicke ist die Anzahl der USB-Buchsen ja selbst bei nicht ganz alter Hardware nicht. Immerhin scheint der Nebeneffekt deiner Mühen (einfaches Umschalten zwischen den Lautsprechern) zwar noch mit etwas scripten, aber prinzipiell machbar.

[fischig]

So, erstmal: Wir bleiben am besten bei deinen Bezeichnungen. Es ist ohne individuelle Namensgebung kompliziert genug!

Hier meine .asoundrc:

Code: Alles auswählen

# pcm für die Wiedergabe mit festgelegtem, bewährtem Format
pcm.loopsink {
	type plug
	slave {
		# Wiedergabe an die virtuelle Soundkarte
		pcm "hw:Loopback,0"

		# Format
		rate 48000
		format "S16_LE"
		channels 2
	}
}

pcm.dsnooper {
	# dsnoop erlaubt gleichzeitige Aufnahmen mit mehreren Programmen
	type dsnoop

	# beliebiger Wert (in der Konfiguration nicht zwei Mal denselben Wert verwenden!)
	ipc_key 1536

	# hier landen die Audiodaten der Wiedergabe an Loopback,0, also vom oben definierten
	# pcm.loopsink und in Folge auch die Audiodaten, die am unten definierten pcm.schleife
	# wiedergegeben werden
	slave.pcm "hw:Loopback,1"
}

pcm.schleife {
	# Plugin zum Zusammensetzen zweier unterschiedlicher Geräte zur Wiedergabe und Aufnahme
	type asym

	# weiterleiten von/zu den oben definierten pcms
	playback.pcm "loopsink"
	capture.pcm "plug:dsnooper"
}

# Lautstärkeregelung für den Bluetooth-Lautsprecher
pcm.bt_ls {
	# Plugin zur Lautstärkeregelung
	type softvol
	
	# Weiterleitung an...
	slave.pcm "bt_ls_hw"
	
	# Name des Reglers und Soundkarte (aplay -l) in der er erscheinen soll
	control.name "PCM Bluetooth-LS"
	control.card PCH
}

# Dasselbe noch einmal für den Bluetooth-Kopfhörer
pcm.bt_kh {
	type softvol
	slave.pcm "bt_kh_hw"
	control.name "PCM Bluetooth-KH"
	control.card PCH
}

# Bluetooth-Lautsprecher
pcm.bt_ls_hw {
	# Plugin bluealsa ist für Bluetooth zuständig
	type bluealsa
	# Name des Bluetooth-Adapters
	# (nicht notwendig, wenn nur ein Adapter vorhanden ist)	
	interface "hci0"
	# MAC-Adresse des Bluetooth-Lautsprechers
	device "88:00:00:00:31:F0"
	# zu verwendendes Protokoll zur Audiodatenübertragung (Bluetooth-Profil)
	profile "a2dp"
}

# Dasselbe noch einmal für den Bluetooth-Kopfhörer
pcm.bt_kh_hw {
	type bluealsa
	interface "hci1"
	device "12:51:02:20:0F:E8"
	profile "a2dp"
}

Die Zuordnung der jeweiligen Controller-MACs zu hci* habe ich via

Code: Alles auswählen

hcitool dev

rausbekommen.

Beim Testen funktioniert die Irish-Pub-Ausgabe via bt_ls. bt_kh funktioniert nicht, auch nicht, wenn ich die Ausgabe via bt_ls abbreche. Ich vermute, irgendwie kommt er an hci1 nicht heran.
Meldung ist:

Code: Alles auswählen

ALSA lib pcm_dsnoop.c:673:(snd_pcm_dsnoop_open) unable to open slave
arecord: main:788: ALSA lib bluealsa-pcm.c:667:(_snd_pcm_bluealsa_open) BlueALSA connection failed: Datei oder Verzeichnis nicht gefunden
aplay: main:788: Fehler beim Öffnen des Gerätes: Das Argument ist ungültig
Fehler beim Öffnen des Gerätes: Datei oder Verzeichnis nicht gefunden

[smutbert]

Mit welchem Befehl startest du bluealsa (den Daemon) doch gleich? Legst du bluealsa auf hci0 fest?

Möglicherweise oder sogar vermutlich brauchst du zwei bluealsa-Instanzen, eine pro Bluetooth-Controller. Ich glaube du startest das in der rc.local? Dort könntest du zwei Befehle eintragen

Code: Alles auswählen

bluealsa -i hci0 ... &
bluealsa -i hci1 ... &

... steht für die anderen Optionen, die du wohl am besten beibehältst (--disable-hsp oä) und das & am Ende ist vor allem beim ersten Daemon wichtig, damit er im Hintergrund gestartet wird und nicht die weitere Ausführung von rc.local, also insbesondere das Starten des zweiten bluealsa-Daemons blockiert.

[fischig]

Funktioniert nicht mit zwei Instanzen. Näheres habe ich noch nicht rausgefunden.
Geht das überhaupt:

It is not possible to run more than one instance of the BlueALSA server per D-Bus interface.

?(1)
(1) https://github.com/Arkq/bluez-alsa Keine Ahnung, ob ich eine „D-Bus-Schnittselle“ benutze.

Was bedeutet/welche Konsequenzen hat, wenn bluetoothctl einen der beiden Controller zum default erklärt?

Nebenbei: Ich benutzte bisher (schon ziemlich am Anfang erwähnt [vor S. 4]) keinerlei Optionen mehr im bluealsa-Kommando in rc.local. Die Option --disable-hsp erschien mir bestenfalls überflüssig.
Gibt's irgendwo Zusammenstellungen der Optionen von bluealsa? Eine Manpage habe ich nicht.

[fischig]

Viele (billige?) Bluetooth-Controller unterstützen so wie es aussieht (gleichzeitig) nur eine a2dp-Verbindung.

Ich habe begründete Hoffnung, dass das nicht zutrifft. MIt dieser simplen asoundrc

Code: Alles auswählen

pcm.btL1 {			# Lautsprecher-pcm (für BT-Speaker in bluetoothctl)
  type bluealsa			# Alsa-Plugin für Bluetooth
  interface "hci0"		# vom Kernel eingerichtete BT-Schnittstelle
  device "88:00:00:00:31:F0"	# MAC-Adresse des Lautsprechers (= „BT-Speaker“ in bluetoothctl,
				# Lautsprecher mit Werbeaufdruck für Becks Bier)
  profile "a2dp"		# Bluetooth-Profil
}

pcm.btL2 {			# Lautsprecher-pcm (für „L1“ in bluetoothctl)				
  type bluealsa			# Alsa-Plugin
  interface "hci0"		# vom Kernel eingerichtete BT-Schnittstelle
  device "12:51:02:20:0F:E8"	# MAC-Adresse des Kopfhörers (= „L1“ in bluetoothctl,
				# Kopfhörer)
  profile "a2dp"		# Bluetooth-Profil
}

kriege ich via aplay (gestartet in zwei Terminals) den Ton derselben Datei gleichzeitig auf beide BT-Lautsprecher. Synchron ist der natürlich nicht. (Bei den Namen und auch den Begriffen Lautsprecher/Kopfhörer mach ich keine Klimmzüge mehr und nummeriere die einfach durch. Die Reglerplugins lass' ich auch weg, die stören nur und es sollte reichen, wenn man dieses andauernde und umständliche Bereinigen der asound.state einmal macht, wenn man glaubt fertig zu sein.)
Die Synchronität der Ausgbe lässt sich wohl nur über deine „schleife“ erreichen.

[smutbert]

Also erstens danke fürs herausfinden. Gut zu wissen, dass es grundsätzlich funktionieren soll.

Allerdings verstehe ich dann nicht, warum es nicht auch wie auf der ersten Seite in diesem Thread beschrieben mit der Loopbacksoundkarte geklappt hat (viewtopic.php?f=25&t=177552#p1238724), denn da passiert im Grunde dasselbe: der Ton wird mit zwei aplay-Befehlen an beiden Bluetooth-Geräten wiedergegeben.

(Mit so hartnäckigen Schwierigkeiten habe ich zwar nicht gerechnet, aber das ist jetzt so ungefähr das, was ich gemeint habe, als ich gesagt habe, mit mpd ginge es vermutlich leichter/eleganter. Dort trägt man einfach beide Ausgabegeräte in die mpd-Konfiguration ein und schaltet sie nach belieben zu oder weg.)

[fischig]

Ich werd's noch mal nachstellen, die asoundrc-Variante habe ich aufgehoben (wäre dann 3. oder 4. Versuch).

Ich habe kein Problem damit, es mit mpd zu versuchen. Da muss ich mich allerdings erst mal einlesen oder du sagst mir, wie du dir die Konfiguration vorstellst. Ich weise aber schon mal darauf hin, dass ich die simultane Tonausgabe in 1. Linie bei der Video-Wiedergabe nutzen möchte.

[fischig]

Ich hab's noch mal nachgestellt. Es bleibt dabei, der laufende Radiostream wird nur an einen Lautsprecher übertragen. Fehlermeldung für den Lautsprecher, wenn der Kopfhörer-Ton läuft:

Code: Alles auswählen

arecord -r 48000 -f S16_LE -c 2 -D schleife | aplay -r 48000 -f S16_LE -c 2 -D plug:bt_ls
ALSA lib pcm_dsnoop.c:673:(snd_pcm_dsnoop_open) unable to open slave
arecord: main:788: Fehler beim Öffnen des Gerätes: Das Argument ist ungültig
aplay: playback:2787: Lesefehler

Ob's an mplayer liegt? ich versuch mich dann mal mit mpd.
Aber irgendwie scheint mir die Diskrepanz zwischen der Benutzung deiner asoundrc und meinem letzten Test damit zusammenzuhängen, dass wir einmal versuchen, ein- und denselben Stream (ich nehme an, das man diese Radioübertragung als Stream bezeichnet) auf zwei Lautsprechern auszugeben (smutbert) und einmal eine Datei zweimal öffnen (fischic).

[smutbert]

An mplayer kann es eigentlich nicht mehr liegen und der Fehler jetzt liegt auch nicht an bluetooth. Was aber auch heißt, dass ich den Fehler eigentlich nachstellen können sollte. Die „Diskrepanz“ sollte nichts machen. dnsoop sorgt dafür, dass gleichzeitig mehrere Anwendungen den Stream aufnehmen können, aber genau daran scheint es zu scheitern, obwohl es bei mir funktioniert hat.


Wiederhole den Test doch bitte noch einmal und zeige auch die Ausgabe von der Kopfhörerwiedergabe.
Funktioniert die Wiedergabe über den Lautsprecher, wenn die Kopfhörerausgabe nicht läuft?
Du machst alles unter einem Benutzeraccount und nicht etwa unter unterschiedlichen, oder?

[fischig]

Radio (mplayer) eingeschaltet.
Lautsprecher läuft mit folgender Meldung:

Code: Alles auswählen

$ arecord -r 48000 -f S16_LE -c 2 -D schleife | aplay -r 48000 -f S16_LE -c 2 -D bt_ls
Aufnahme: WAVE 'stdin' : Signed 16 bit Little Endian, Rate: 48000 Hz, stereo
Wiedergabe: WAVE 'stdin' : Signed 16 bit Little Endian, Rate: 48000 Hz, stereo
Warnung: Rate ist nicht exakt (angefordert: 48000 Hz, unterstützt: 44100 Hz)
         probieren Sie bitte das plug-Plugin: (-Dplug:bt_ls)
Überlauf!!! (mindestens 0,008 ms)
...

Jetzt Versuch, den Kopfhörer dazuzuschalten:

Code: Alles auswählen

$ arecord -r 48000 -f S16_LE -c 2 -D schleife | aplay -r 48000 -f S16_LE -c 2 -D plug:bt_kh
ALSA lib pcm_dsnoop.c:673:(snd_pcm_dsnoop_open) unable to open slave
arecord: main:788: Fehler beim Öffnen des Gerätes: Das Argument ist ungültig
aplay: playback:2787: Lesefehler

und jetzt umgekehrt. Radio läuft weiter, Lautsprecher ausgeschaltet.
Kopfhörer läuft mit folgender Meldung:

Code: Alles auswählen

$ arecord -r 48000 -f S16_LE -c 2 -D schleife | aplay -r 48000 -f S16_LE -c 2 -D plug:bt_kh
Aufnahme: WAVE 'stdin' : Signed 16 bit Little Endian, Rate: 48000 Hz, stereo
Wiedergabe: WAVE 'stdin' : Signed 16 bit Little Endian, Rate: 48000 Hz, stereo

jetzt Versuch, den Lautsprecher zuzuschalten:

Code: Alles auswählen

$ arecord -r 48000 -f S16_LE -c 2 -D schleife | aplay -r 48000 -f S16_LE -c 2 -D bt_ls
ALSA lib pcm_dsnoop.c:673:(snd_pcm_dsnoop_open) unable to open slave
arecord: main:788: Fehler beim Öffnen des Gerätes: Das Argument ist ungültig
aplay: playback:2787: Lesefehler

Ich mache alles als ein- und derselbe Benutzer. Drei Terminals (mplayer, bt_kh, bt_ls) aber das dürfte klar sein.

Aber du bringst mich da auf eine neue Idee: Soll ich das Ganze mal versuchen, als root zu reproduzieren?
Dazu müsste ich meine ~/.asoundrc inhaltlich unverändert nach /etc/asound.conf transferieren - richtig? (Wäre vielleicht eh sinnvoll.)

[smutbert]

[...] Soll ich das Ganze mal versuchen, als root zu reproduzieren?
Dazu müsste ich meine ~/.asoundrc inhaltlich unverändert nach /etc/asound.conf transferieren - richtig? (Wäre vielleicht eh sinnvoll.)

Das oder /root/.asoundrc sollte ebenfalls funktionieren, aber ich sehe keinen Anhaltspunkt, dass hier die root-Rechte etwas verändern könnten.

Ich kann jetzt bei mir ähnliche Fehler produzieren, aber die Fehlermeldung lautet interessanterweise nicht immer gleich. Bei der Ursache tappe ich noch im Dunkeln. Ich werde noch das eine oder andere ausprobieren.

[smutbert]

Das Hauptproblem scheint dsnoop zu sein. Ich finde zwar viele ähnliche Probleme im Netz, aber keine bei unserem Problem zuverlässig funktionierende Lösung.

Dafür habe ich die Gelegenheit genutzt mich endlich einmal etwas mit ecasound auseinanderzusetzen. Das kann den Ton aus beliebigen Quellen (egal ob reale oder Loopback-Soundkarte oder von wav-Dateien) wie selbstverständlich über verschiedene Soundkarten, Lautsprecher,... (auch gleichzeitig) wiedergeben.
Das macht das Testen einfacher. Ohne weitere Änderung gegenüber deiner letzten .asoundrc sollte es genügen ecasound zu installieren und mit einer beliebigen wav-Datei (/PFAD/WAVE-DATEI.WAV) zu testen, zuerst die Wiedergabe am Lautsprecher

Code: Alles auswählen

$ ecasound -i:/PFAD/WAVE-DATEI.WAV -o:alsa,plug:btL1

dann über den Kopfhörer

Code: Alles auswählen

$ ecasound -i:/PFAD/WAVE-DATEI.WAV -o:alsa,plug:btL2

und schließlich beides gleichzeitig und so synchron wie es geht

Code: Alles auswählen

$ ecasound -a:1,2 -i:/PFAD/WAVE-DATEI.WAV -a:1 -o:alsa,plug:btL1 -a:2  -o:alsa,plug:btL2

Ich hoffe wirklich, dass ich diesmal eine zuverlässig funktionierende Lösung gefunden habe. Wenn das der Fall ist, wird es mir ein Vergnügen sein den Rest für die Nutzung über die Loopback-Soundkarte zu posten.

[fischig]

Du meinst, ich soll die Kommandos mit der asoundrc ausprobieren, die ich am 26.05.2020 12:01:02 gepostet habe?

Oh Mann, es ist zum Mäusemelken! Fummle mir doch bitte mal diese Angleichung der Formate (u8?/S16_LE) und (sampler?)-Raten, also 44100/48000, da hinein. Im Prinzip scheint's zu gehen, aber die eine wav will ecasound nur mit dem Kopfhörer, die andere nur mit dem Lautsprecher spielen.
Mit ffpmpeg auf die Schnelle selbst Umkodieren war nicht erfolgreich.
Ich kann also das letzte entscheidende Kommando nicht testen.
Mit den wavs unter /usr/share/... macht das hier ja wohl wenig Sinn - oder?

Vielleicht liegt hier der Hund begraben: Ich kriege es nicht gebacken, eine wav-Datei so zu formatieren, dass sie mit ecasound von beiden Lautsprechern hintereinander abgespielt wird, ganz zu schweigen von simultan.

Nehme ich deine (mit „schleife“, „dsnooper“ konstruierte) asoundrc, lasse mplayer und übergehe den arecord-Teil bei aplay, dann funktioniert sowohl

Code: Alles auswählen

aplay -r 48000 -f S16_LE -c 2 -D plug:bt_ls audiodump.wav

als auch

Code: Alles auswählen

aplay -r 48000 -f S16_LE -c 2 -D plug:bt_kh audiodump.wav

[smutbert]

Dass die beiden Bluetoothgeräte unterschiedliche Formate unterstützen ist mir schon bei den vorigen Beiträgen aufgefallen. Deswegen habe ich bei der Audioausgabe -o:alsa,plug:btL1/2 angegeben – offensichtlich funktioniert das nicht so recht.

Also schreiben wir das in die .asoundrc:

Code: Alles auswählen

pcm.btL1 {			# Lautsprecher-pcm (für BT-Speaker in bluetoothctl)
  type bluealsa			# Alsa-Plugin für Bluetooth
  interface "hci0"		# vom Kernel eingerichtete BT-Schnittstelle
  device "88:00:00:00:31:F0"	# MAC-Adresse des Lautsprechers (= „BT-Speaker“ in bluetoothctl,
				# Lautsprecher mit Werbeaufdruck für Becks Bier)
  profile "a2dp"		# Bluetooth-Profil
}

pcm.btL2 {			# Lautsprecher-pcm (für „L1“ in bluetoothctl)				
  type bluealsa			# Alsa-Plugin
  interface "hci0"		# vom Kernel eingerichtete BT-Schnittstelle
  device "12:51:02:20:0F:E8"	# MAC-Adresse des Kopfhörers (= „L1“ in bluetoothctl,
				# Kopfhörer)
  profile "a2dp"		# Bluetooth-Profil
}

# plug-Plugins, die an die Bluetoothgeräte weiterleiten

pcm.plugbtL1 {
	type plug
	slave.pcm "btL1"
}

pcm.plugbtL2 {
	type plug
	slave.pcm "btL2"
}

Die Befehle lauten dann

Code: Alles auswählen

ecasound -i /PFAD/WAVE-DATEI.WAV -o alsa,plugbtL1
ecasound -i /PFAD/WAVE-DATEI.WAV -o alsa,plugbtL2

und

Code: Alles auswählen

ecasound -a:1,2 -i /PFAD/WAVE-DATEI.WAV -a:1 -o alsa,plugbtL1 -a:2  -o alsa,plugbtL2

[fischig]

Das gleiche Spielchen. Die Datei die auf btL1 gespielt wird, wird auf btL2 nicht gespielt und umgekehrt.
Für btL2 hängt die Ausgabe hier:

Code: Alles auswählen

$ ecasound -i audiodump.wav -o alsa,plugbtL2
**************************************************************************
*        ecasound v2.9.1 (C) 1997-2014 Kai Vehmanen and others    
**************************************************************************
(eca-chainsetup) Chainsetup "untitled-chainsetup"
(eca-chainsetup) NOTE: Real-time configuration, but insufficient privileges
... to utilize real-time scheduling (SCHED_FIFO). With small buffersizes,
... this may cause audible glitches during processing.
(eca-chainsetup) "rt" buffering mode selected.
(eca-chainsetup) NOTE: using existing audio parameters -f:s16_le,2,48000
... for object 'audiodump.wav' (tried to open with -f:s16_le,2,44100).
(eca-chainsetup) Opened input "audiodump.wav", mode "read". Format: s16_le,
... channels 2, srate 48000, interleaved (locked params).

Mit „hängen“ meine ich, es ist keine Fehlermeldung, ecasound bricht nicht ab, es erscheint kein Prompt, aber man hört auch nichts.
Auf Anhieb sehe ich keinen Unterschied der „Häng“-Meldung für die Ausgabe der anderen Datei auf btL1 . Deswegen poste ich die erstmal nicht.

[smutbert]

[...]
Oh Mann, es ist zum Mäusemelken! [...]

Ja, das ist es. Vor allem, weil sowohl alsa wie auch ecasound das Resampeln übernehmen könn(t)en, aber bei ecasound habe ich nicht herausgefunden wie (oder auch ob) das geht, wenn zwei Ausgabegeräte unterschiedliche Sampleraten wollen und warum das plug-Plugin von Alsa im Zusammenspiel mit ecasound nichts tut ist mir auch nicht klar.
Das was ich auf meinem System testen kann, hilft auch nicht viel, weil sich alsa und/oder ecasound bei mir ein bisschen anders verhalten.

Immerhin habe ich eine neue Version zum Testen für dich ☺
pcm.btL1 und pcm.btL2 bleiben unverändert nur pcm.plugbtL1 und pcm.plugbtL2 habe ich verändert

Code: Alles auswählen

# plug-Plugins, die an die Bluetoothgeräte weiterleiten

pcm.plugbtL1 {
	type plug
	slave {
		rate 48000
		pcm "plug:btL1"
	}
}

pcm.plugbtL2 {
	type plug
	slave {
		rate 48000
		pcm "plug:btL2"
	}
}

Kannst du damit wenigstens eine deiner beiden Testdateien auf beiden Bluetoothgeräten abspielen?

Code: Alles auswählen

ecasound -i datei.wav -o alsa,plugbtL1
ecasound -i datei.wav -o alsa,plugbtL2

[fischig]

Mach ich - morgen.

Zwischenzeitlich war ich auch nicht ganz untätig. Ich habe trotz erheblicher Bauchschmerzen den 2. BT-Lautsprecher, den ich am „Küchenradio“ (eeepc) problemlos nutze, mit der aktuellen Maschine (TP T430) verbunden. Bauchschmerzen deswegen - du erinnerst dich - weil es ziemliche Anstrengungen kostete, nachdem er mit dem Taschenrechner meiner Frau verbunden war, den wieder am „Küchenradio“ zu betreiben. Dieser Lautsprecher ist wesentlich neuer als der „Brauereilautsprecher“ (btL1) mit dem wir bisher hantieren. Ich erhoffe mir, dass der mit 48000 (was ist jetzt die Maßeinheit: KHz?) keine Schwierigkeiten macht. Ich werde den unter alsa als btL3 betreiben. Bisher habe ich damit aber noch keine konkreten Tests unternommen.

[fischig]

So, der nächste Zwischenbericht: Deine Tipps haben nicht funktioniert.
War ziemlich frustriert, hatte gestern auch Dinge im realen Leben zu erledigen und folglich keinen Nerv mich ausdauernd mit dem Bluetooth-Geeiere zu befassen. Eben habe ich dann mal selbständig in der asoundrc die Rate für btL2 auf 41100 gesetzt und mit dieser asondrc konnte ich EINE WAV auf beiden Lautsprechern (nacheinander) hören und das auch reproduzieren:

Code: Alles auswählen

# asoundrc-doppelt2
pcm.btL1 {			# Lautsprecher-pcm (für BT-Speaker in bluetoothctl)
  type bluealsa			# Alsa-Plugin für Bluetooth
  interface "hci0"		# vom Kernel eingerichtete BT-Schnittstelle
  device "88:00:00:00:31:F0"	# MAC-Adresse des Lautsprechers (= „BT-Speaker“ in bluetoothctl,
				# Lautsprecher mit Werbeaufdruck für Becks Bier)
  profile "a2dp"		# Bluetooth-Profil
}

pcm.btL2 {			# Lautsprecher-pcm (für „L1“ in bluetoothctl)				
  type bluealsa			# Alsa-Plugin
  interface "hci0"		# vom Kernel eingerichtete BT-Schnittstelle
  device "12:51:02:20:0F:E8"	# MAC-Adresse des Kopfhörers (= „L1“ in bluetoothctl,
				# Kopfhörer)
  profile "a2dp"		# Bluetooth-Profil
}

# plug-Plugins, die an die Bluetoothgeräte weiterleiten

pcm.plugbtL1 {
	type plug
	slave {
		rate 48000
		pcm "plug:btL1"
	}
}

pcm.plugbtL2 {
	type plug
	slave {
		rate 41100
		pcm "plug:btL2"
	}
}

Der Versuch, eine weitere WAV abzuspielen, scheiterte dann aber vollständig, kein Ton auf beiden Lautsprechern. Und auch der erfolgreiche Versuch mit der 1. WAV ließ sich nicht mehr reproduzieren.
Irgendwann kam mir dann der Einfall, beide Lautsprecher aus- und wieder einzuschalten. Danach konnte ich sie nicht mehr mit dem Controller verbinden (bluealsa „verwirrt“?). btL1 versuchte das mehrfach selbständig, kriegte es aber nicht gebacken. btL2 muss ich zur Zeit via bluetoothctl ständig händisch verbinden (meine Frau hatte zwischenzeitlich von ihrem Recht Gebrauch gemacht und IHREN Kopfhörer mit dem Taschenrechner benutzt) und das klappte auch nicht. Nach einem Rechnerneustart funktionierte dann aber wieder sowohl das Verbinden als auch die asoundrc mit ecasound wieder.
Im gegenwärtigen Stand der Dinge scheint es mir nicht sinnvoll, die Meldungen der Fehlversuche zu posten, zumal ich in dem Chaos auch den Überblick verliere.

[smutbert]

Zuerst den Sampleraten:
Bei 48000 ist die Masseinheit Hertz (Hz), es ist aber genauso üblich sie in kHz anzugeben (48 kHz).
Das andere ist, dass es zwei verschiedene übliche Teiler für die Samplerate gibt, was zu zwei Gruppen führt

1. 22050 Hz, 44100 Hz, 88200 Hz, 176400 Hz
2. 24000 Hz, 48000 Hz, 96000 Hz, 192000 Hz, 384000 Hz

Wobei es viele auch nicht zu genau nehmen und zum Beispiel statt 44,1 kHz oder 44100 Hz einfach 44 kHz schreiben oä.

Mit 41100 Hz erfindest du allerdings eine neue Samplerate, die garantiert von keiner Hardware unterstützt wird. Wenn es funktioniert, dann möglicherweise, weil du damit einen Weg gefunden hast Alsa zum Resampling zu zwingen.

[...] Dieser Lautsprecher ist wesentlich neuer als der „Brauereilautsprecher“ (btL1) mit dem wir bisher hantieren. [...]

Es wäre bestimmt einfacher, wenn es ein Format, insbesondere eine Samplerate gäbe, die beide Geräte unterstützen.
(Außerdem ist es nervig, dass bluealsa so ein Sonderfall ist und deswegen vieles nicht so funktioniert wie mit anderen Audiogeräten oder mit Pulseaudio.)

Es tut mir leid, dass wir bis jetzt auf keine funktionierende Lösung gekommen sind.

[...] Eben habe ich dann mal selbständig in der asoundrc die Rate für btL2 auf 41100 gesetzt und mit dieser asondrc konnte ich EINE WAV auf beiden Lautsprechern (nacheinander) hören und das auch reproduzieren:

Welche wav-Datei ist das denn – interessant ist vor allem die Samplerate?

Code: Alles auswählen

$ file datei.wav 

[fischig]

Tja, smutbert, was soll ich sagen? Ich habe synchronen Ton auf beiden Lautsprechern abwechselnd und mit beiden Test-Dateien!

Der Reihe nach:
Ich hatte zwar richtig angegeben, dass ich die Samplerrate für btL2 auf 41100 geändert hätte, aber das war ein Versehen, denn eigentlich war meine Idee, die von ecasound und auch vorher schon immer mal wieder gemeldete, von 48000 Hz abweichende Rate von 44100 Hz der einen Datei einzutragen 1), ich war aber zu faul, beim Schreiben zu prüfen, ob ich wenigstens die Zahl richtig im Kopf hatte.
Das habe ich jetzt korrigiert und den Rechner (sicherheitshalber wieder mal) neu gestartet. Danach habe ich erst mal beide Dateien nacheinander abgespielt und als das funktionierte, habe ich (mutig, wie ich bin ) dein weiter oben genanntes Kommando gestartet:

Code: Alles auswählen

$ ecasound -a:1,2 -i datei1.wav -a:1 -o alsa,plugbtL1 -a:2 -o alsa,plugbtL2

und als das dann funktionierte, mit datei2.wav wiederholt.
Somit hast du die Frage nach der synchronen Tonwiedergabe auf zwei Ton-Ausgabe-Geräten via bluealsa offenbar im Grundsatz gelöst. Nochmal

Jetzt gehe ich mal daran, mir deinen 1. Vorschlag vom 15.05.2020 23:48:51 wieder vorzunehmen, um weitere Einzelheiten zu verstehen und die aktuell genutzte asoundrc-Version dahingehend zu verbessern, insbesondere videotauglich zu machen.

Zu deiner Frage, „Welche wav-Datei ist das denn“

Code: Alles auswählen

$ file [datei1].wav
[datei1].wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 48000 Hz
~$ file [datei2].wav
[datei2].wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 8 bit, stereo 44100 Hz

2)

Nebenbei: Grundsätzlich bin ich kein „Feind/Hasser“ von pulseaudio. Aber ich hatte bei dem ursprünglichen Vorhaben 3), grundsätzlich bluetooth zu nutzen, im Ergebnis den Eindruck, dass das mit dem bluealsa (deb von Raspian) zuverlässiger und einfacher zu händeln sei als mit pulse. Wenn du meinst, dass dieser Eindruck trügt (du kannst das nun mal erheblich besser einschätzen als ich), dann bin ich auch offen dafür, es wieder mit pulse zu versuchen, aber ich denke, ich sollte das hier erst mal zu Ende bringen. Letztlich geht's um die Tonausgabe von Videos und ich denke DA sind wir noch lange nicht.
In dem Zusammenhang: Dir muss gar nichts leid tun. Es ist mein Problem; bei dem, geholfen zu bekommen, ich dankbar sein will und du dir keinen Kopf zu machen brauchst, wenn ich's nicht hinkriege.

----------------------------------------------------
1) Dass die Raten in beiden Dateien unterschiedlich waren, und dass das ein Problem sein könnte, ging mir ja schon etwas länger durch den Kopf, aber was die entsprechenden Zeilen in der asoundrc eigentlich bewirken, war mir Unbedarftem völlig unklar, siehe meine Bemerkung vom 21.05.2020 12:12:22

Bis ich sie [deine asoundrc] verdaut habe, werde ich wohl noch einiges erfragen müssen

. Deinem letzten Beitrag entnehme ich, dass Alsa mit dieser Zeile gezwungen wird, diese Rate zu benutzen - richtig?
Nebenbei weise ich nochmal darauf hin, dass auch die „Formate“ unterschiedlich sind, Keine Ahnung, ob das auch von Belang ist.

2) Beide Dateien sind wohl (mehr oder weniger bewusstlos angefertigte) Produkte von länger zurückliegenden ffmpeg-Versuchen,die zum Ziel hatten, für Testzwecke etwas besser geeignete, vor allem längere WAVs zu bekommen als die unter /usr/share/sound vorfindlichen.
bei der ersten habe ich dazu vermutlich ein Stück Tonspur eines Videos heraus isoliert, die zweite dürfte eine umgewandelte youtubedl-Datei sein.

3) viewtopic.php?f=25&t=177012