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

[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

[smutbert]

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

Endlich, mir fällt ein Stein vom Herzen ☺

[...]
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.

Da sollte nicht mehr viel fehlen. Ich würde zwei Dinge machen:

Erstens ist dir vielleicht schon aufgefallen, dass ich ein merkwürdiges Konstrukt in die asoundrc geschrieben habe, damit meine ich die grundsätzlich Struktur

Code: Alles auswählen

pcm.plugbtL {
	type plug
	slave {
		pcm "plug:btL"
	}
}

hier definiere ich ein Plug-Plugin, das den Ton erst an ein weiteres Plug-Plugin weiterleitet, das ihn erst dann bluealsa übergibt (ecasound→plug→plug→bluealsa).
Der Grundgedanke dahinter war, dass nachdem das Aushandeln der Samplerate mit dem einfachen ecasound→plug→bluealsa gescheitert ist ein weiteres plug möglicherweise hilft das Problem zu umgehen, ganz besonders, wenn man die Samplerate des ersten Plugins festlegt und Alsa so zum Resampeln zwingt.

Es scheint aber viel mehr das manuelle Festlegen der Samplerate auf 44100 Hz geholfen zu haben.
Ich würde also ausprobieren ob du auch mit der etwas simpleren Variante zum Ziel kommst, wenn wir die Samplerate auf 44100 Hz festlegen.

Code: Alles auswählen

# der bluealsa-Teil wie gehabt
# ...

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

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

(Ich muss mich etwas wundern, dass ich das nicht schon viel früher vorgeschlagen habe, aber hinterher ist man immer gescheiter,)

Zweitens würde ich die Ausgabe von ecasound auf ein bestimmtes Format festlegen, damit das Format der Audio- oder Videodateien keinen Einfluss auf das Funktionieren unserer gesamten Konstruktion mehr haben kann.

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 [...]

Da bin ich der letzte der dir etwas einreden will.
Die Konfiguration und die Eigenheiten von bluealsa sind nervig, aber die Probleme, die Bluetooth mit pulseaudio bereiten kann sind auch nicht von schlechten Eltern.

Ich würde wahrscheinlich dazu tendieren bei einem Mediacenter PC oder einem headless laufenden System bluealsa zu verwenden und auf einem normalen Desktop PC eher pulseaudio.

----------------------------------------------------
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.

Zu Samplerate, ja.
Wobei wir wie gesagt in der Reihe ecasound→plug→plug→bluealsa nur die Samplerate des ersten Plug-Plugins festgelegt haben. Dem zweiten haben wir die Wahl gelassen die Rate wieder zu ändern – möglicherweise mit ein Grund, dass es trotz deines Verschreibers mit 41100 Hz funktioniert hat.

Formate lassen sich vergleichsweise einfach konvertieren und sind deswegen nur selten ein Problem. Da geht es im wesentlichen nur darum die Reihenfolge der Bits umzudrehen und/oder ein paar Bit abzuschneiden oder ein paar 0 anzuhängen.
Trotzdem würde ich am Ende auch dieses Format der ecasound-Ausgabe auf ein verlässlich funktionierendes festnageln (das gehört dann oben zu „Zweitens“).

[fischig]

Ich verstehe dich nur ansatzweise.
Vielleicht fang' ich mal mit dem ecasound-Kommando an, von dem ich glaube, noch am meisten zu verstehen.

Code: Alles auswählen

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

-a: die manpage sagt, zu diesem Parameter werden hinter einem Doppelpunkt „chainnames“ aufgezählt.
chain übersetze ich allgemeinsprachlich mit „Kette“. Dann würden hier Kettennamen aufgezählt. Ich erkenne hier keine Kette. Passt hier nicht der Begriff „Ziel“, folglich „Zielnamen“ besser?

:1,2: Du hast Kardinalzahlen als Namen gewählt. Wie beliebig sind die Namen? hätte man auch „Hans“ und „Grete“ nehmen können?

-i: datei1.wav -i für input? Scheint klar zu sein, danach folgt der zu verarbeitende Dateinamen

-a:1: die erste Kette/das erste Ziel wird angesprungen

-o: für output, bei „1“ soll was ausgegeben werden

alsa: für die Ausgabe soll alsa benutzt werden, wenn alsa benutzt werden soll, muss nach einem Komma ein für alsa konfiguriertes pcm-Ding angegeben werden, sagt die manpage

,plugbtL1: hier kommt jetzt die asoundrc ins Spiel: alsa soll auf diesen Abschnitt darin zugreifen:

Code: Alles auswählen

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

Habe ich das soweit richtig verstanden? Wie gesagt der Begriff Chain/Kette leuchtet mir bis hierher nicht ein.

Sollte ich das Kommando dennoch im Wesentlichen wider Erwarten richtig interpretiert haben, dann wird's für mich hier haarig:

Code: Alles auswählen

pcm "plug:btL1"

Ich ahne, dass das sein könnte, was du im letzten Beitrag mit plug->plug->bluealsa ansprachst. Sollte das auch zutreffen, dann versteh' ich's aber leider noch nicht.

Vielleicht klärt sich mein Unverständnis auch mit der Beantwortung dieser Frage:
Wenn da gestanden hätte: pcm "btL1", von dem ich vermute, dass es gleichbedeutend wäre mit slave.pcm "btL1" (wie in deinem Beitrag vom 31.05.2020 14:22:32), hätte ich gesagt ok, jetzt wird von plugbtL1 letztmals weitergeleitet auf pcm.btL1 und damit den via hci0 und MAC bestimmten Lautsprecher.
Was passiert jetzt mit pcm "plug:btL1" stattdessen?

[smutbert]

Du hast das meiste schon richtig geschrieben.

Wie gesagt der Begriff Chain/Kette leuchtet mir bis hierher nicht ein.

Mit Kette ist wohl einfach eine Folge von Schritten gemeint. Eine solche Kette beginnt mit einer Eingabe, endet mit einer Ausgabe und zwischen den beiden kann ecasound eine ganze Menge mit den Audiodaten anstellen.
Wir nutzen von ecasounds Fähigkeiten fast nichts und haben zwei einfache Ketten 1 und 2 (ich glaube die Ketten dürften auch Franz und Sisi heißen).

• -a:1,2 -i datei.wav
  definiert die Eingabe/Quelle von Kette 1 und 2
• -a:1 -o alsa,plugbtL1
  definiert die Ausgabe von Kette 1 und
• -a:2 -o alsa,plugbtL2
  definiert die Ausgabe von Kette 2

[...]
alsa: für die Ausgabe soll alsa benutzt werden, wenn alsa benutzt werden soll, muss nach einem Komma ein für alsa konfiguriertes pcm-Ding angegeben werden, sagt die manpage

Für pcm-Dinger habe ich zuletzt gleich mehrere Male den Namen pcm-Gerät gelesen. Dabei bleibe ich jetzt anstelle von Ding ☺
Es muss kein pcm-Gerät angegeben werden, sondern es kann eines angegeben werden. Wird keines angegeben sondern einfach nur -o alsa dann erfolgt die Ausgabe am pcm-Gerät namens default (dem Standardgerät).

[...]
Sollte ich das Kommando dennoch im Wesentlichen wider Erwarten richtig interpretiert haben, dann wird's für mich hier haarig:

Code: Alles auswählen

pcm "plug:btL1"

Ich ahne, dass das sein könnte, was du im letzten Beitrag mit plug->plug->bluealsa ansprachst. Sollte das auch zutreffen, dann versteh' ich's aber leider noch nicht.

plug:btL1 ist eine übliche kurze Schreibweise für das plug-Plugin mit der anschließenden Ausgabe über das pcm-Gerät btL1.
Ich glaube zumindest zwei ganz ähnliche Schreibweisen kennst du bereits:

• hw:PCH für die direkte Wiedergabe über die Soundkarte PCH und
• plughw:PCH für die Wiedergabe über ein plug-Plugin und in weiterer Folge die Soundkarte PCH

[fischig]

plug:btL1 ist eine übliche kurze Schreibweise für das plug-Plugin mit der anschließenden Ausgabe über das pcm-Gerät btL1.

Ein plugin vom Typ plug? Ich muss schon sagen, Das wirkt auf mich schon ziemlich schräg! Unter einem Alsa-Plugin vom Typ bluealsa vermag ich mir in etwa etwas vorzustellen, unter einem Plugin vom Typ plug gelingt mir das nicht. Aber nun ja, wir haben's uns nicht ausgedacht.

Also kann ich mir das in etwa so vorstellen:
ecasound leitet eine Tondatei weiter zur Ausgabe an ein PCM-„Gerät“ namens plugbtL1. dieses PCM-„Gerät“ ist vom Typ plug und beschäftigt ein weiteres PCM-„Gerät“ vom Typ plug, das dann weiterleitet an ein neues PCM-„Gerät“ namens btL1 vom Typ bluealsa und dieses leitet dann endgültig weiter an ein real existierendes Gerät (Lautsprecher) an der Software-Schnittstelle hci0 und der jeweiligen MAC-Adresse?

Wie sähe das Konstrukt denn jetzt in unüblich langer Schreibweise aus? Vielleicht fällt mir da die Vorstellung leichter.

Es muss kein pcm-Gerät angegeben werden, sondern es kann eines angegeben werden.

Ich lese die manpage so, dass, wenn hinter -o „alsa“ angegeben wird, dann auch ein Alsa-„Gerät“ angegeben werden muss.

Eine Änderung der asoundrc möchte ich erstmal vermeiden (never change a running system).

Zweitens würde ich die Ausgabe von ecasound auf ein bestimmtes Format festlegen, damit das Format der Audio- oder Videodateien keinen Einfluss auf das Funktionieren unserer gesamten Konstruktion mehr haben kann.

An welches denkst du da, S16_LE?

Und wie übergibt man das ganze jetzt an ein Programm, das u.a. Videos abspielen kann, z.B. vlc. Wenn ich recht sehe, dann erwartet vlc, wenn in den Audio-Einstellungen Alsa gewählt wird, die Angabe eines PCM-„Gerätes“. Unser ecasound-Kommando in ein script zu schreiben dürfte damit ausscheiden? Fehlt in der asoundrc noch eine Hierarchie-Ebene?

[smutbert]

[...]
Ein plugin vom Typ plug? Ich muss schon sagen, Das wirkt auf mich schon ziemlich schräg! Unter einem Alsa-Plugin vom Typ bluealsa vermag ich mir in etwa etwas vorzustellen, unter einem Plugin vom Typ plug gelingt mir das nicht. Aber nun ja, wir haben's uns nicht ausgedacht.

Bei Alsa ist so manches ein bisschen schräg, nicht nur der Name dieses Plugins, aber das Plugin, das zwischen unterschiedlichen (Sample-)formaten, Kanalzahlen und Sampleraten konvertiert heißt tatsächlich plug.

Also kann ich mir das in etwa so vorstellen:
ecasound leitet eine Tondatei weiter zur Ausgabe an ein PCM-„Gerät“ namens plugbtL1. dieses PCM-„Gerät“ ist vom Typ plug und beschäftigt ein weiteres PCM-„Gerät“ vom Typ plug, das dann weiterleitet an ein neues PCM-„Gerät“ namens btL1 vom Typ bluealsa und dieses leitet dann endgültig weiter an ein real existierendes Gerät (Lautsprecher) an der Software-Schnittstelle hci0 und der jeweiligen MAC-Adresse?

Ja

Wie sähe das Konstrukt denn jetzt in unüblich langer Schreibweise aus? Vielleicht fällt mir da die Vorstellung leichter.

Eine längere Schreibweise kenne ich nur als Eintrag in der asoundrc/asound.conf und wie es dort aussehen würde, weißt du ja bereits

Code: Alles auswählen

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

Es muss kein pcm-Gerät angegeben werden, sondern es kann eines angegeben werden.

Ich lese die manpage so, dass, wenn hinter -o „alsa“ angegeben wird, dann auch ein Alsa-„Gerät“ angegeben werden muss.

Die manpage ist an der Stelle vielleicht ein bisschen irreführend. In der Dokumentation [1] gibt es Beispiele, wie man die Alsaausgabe nutzen kann

• ecasound -i somefile.mp3 -o alsa Ausgabe über das Standardgerät (default)
• ecasound -i somefile.mp3 -o alsahw,0,0 Ausgabe über das erste Gerät der ersten Soundkarte (hw:0,0)
• ecasound -i somefile.mp3 -o alsaplugin,0,0 Ausgabe über das plug-Plugin und das erste Gerät der ersten Karte (plughw:0,0)
• ecasound -i somefile.mp3 -o alsa,btL1 Ausgabe über das pcm-Gerät btL1

Eine Änderung der asoundrc möchte ich erstmal vermeiden (never change a running system).

Kann ich verstehen, aber wenn du eine Kopie der funktionierenden asoundrc behältst, kannst du ohne bleibende Nebenwirkungen jederzeit wieder zu dieser funktionierenden Konfiguration zurückkehren.
Im Gegensatz zu bluetooth gibt es da keine Konfiguration oder sonstige Information, die irgendwo anders gecached oder sonstwie gespeichert wird.

Zweitens würde ich die Ausgabe von ecasound auf ein bestimmtes Format festlegen, damit das Format der Audio- oder Videodateien keinen Einfluss auf das Funktionieren unserer gesamten Konstruktion mehr haben kann.

An welches denkst du da, S16_LE?
[/quote]
Ja, wobei LE (little endian, das gibt die Reihenfolge der Bits an) schon zu viel ist. Bei ecasound genügt eine Angabe wie -f:16,2,48000 mit der wir das Format auf 16 Bit Sampletiefe, 2 Kanäle und 48 kHz Samplerate festlegen.

Und wie übergibt man das ganze jetzt an ein Programm, das u.a. Videos abspielen kann, z.B. vlc. Wenn ich recht sehe, dann erwartet vlc, wenn in den Audio-Einstellungen Alsa gewählt wird, die Angabe eines PCM-„Gerätes“. Unser ecasound-Kommando in ein script zu schreiben dürfte damit ausscheiden? Fehlt in der asoundrc noch eine Hierarchie-Ebene?

Wir lassen den Videospieler, mplayer oder welches Programm auch immer gerade Ton ausgeben soll, über die Loopback-Soundkarte ausgeben und lesen das Signal von der Loopback-Soundkarte wieder mit ecasound.
In erster Linie müssen wir also das -i datei1,wav ändern.

Wenn das

Code: Alles auswählen

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

verlässlich funktioniert, könnten wir dasselbe mit dem festgelegten Format testen

Code: Alles auswählen

ecasound -a:1,2 -f 16,2,48000 -i resample,auto,datei1.wav -a:1 -o alsa,plugbtL1 -a:2 -o alsa,plugbtL2

am besten testest du das mit Dateien verschiedener Format und auch einmal mehrere Minuten lang um sicher sein zu können, dass dieser Teil funktioniert.
Falls es zum Beispiel zu underruns, xruns oder ähnlichem kommt, können (sollten) wir den Pufferspeicher vergrößern.


[1] https://ecasound.seul.org/ecasound/Docu ... mples.html

[fischig]

Ich habe

Code: Alles auswählen

ecasound -a:1,2 -f 16,2,48000 -i resample,auto,datei1.wav -a:1 -o alsa,plugbtL1 -a:2 -o alsa,plugbtL2

sowohl mit
datei1.wav als auch mit datei.wav getestet, ebenso mit 44100. Funktioniert in allen Fällen, allerdings kommt's zu den vermuteten underruns. Über "Pufferspeicher" und wie man den eventuell händelt, weiß ich noch nichts. Obwohl..., ich erinnere mich, hatten wir das nicht schon mal im Zusammenhang mit dem Begriff Latenz? Die letzte funktionierende asoundrc habe ich aus den folgenden Gründen noch nicht geändert. (Über Sicherungskopien brauchen wir hier nicht zu reden, das ist mir schon klar, dass es bei der komplexen Testerei nicht ohne geht.)

Mir ist unklar, wie ich mit dem Inhalt der folgenden drei Zitate (in Kombination?) umgehen soll:

Wobei wir wie gesagt in der Reihe ecasound→plug→plug→bluealsa nur die Samplerate des ersten Plug-Plugins festgelegt haben. Dem zweiten haben wir die Wahl gelassen die Rate wieder zu ändern

wenn wir die Samplerate auf 44100 Hz festlegen.

Eine längere Schreibweise kenne ich nur als Eintrag in der asoundrc/asound.conf und wie es dort aussehen würde, weißt du ja bereits

Code: Alles auswählen

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

Dass es mir um die längere Schreibweise genau dort, d.h. in asoundrc/asound.conf ging hatte ich bei meiner Frage stillschweigend vorausgesetzt und nein, wie ich das mit dem Festlegen der Samplerrate auf 44100 Hz jetzt in Bezug auf das zweite plug-plugin (das bisher nur in verkürzter Schreibweise in der asoundrc vorliegt?) auf die asoundrc umsetzen soll ist mir nicht klar. Etwa so:

Code: Alles auswählen

[...]
pcm.plugbtL1
	type plug
	slave {
		rate 44100
		pcm.meinPlug {
			type plug
			rate 44100
			slave.pcm "plugbtL1"
		}
	}
}

oder so

Code: Alles auswählen

[...]
pcm.meinPlug {
	type plug
	rate 44100
	slave.pcm "plugbtL1"
}

pcm.plugbtL1
	type plug
	slave {
		rate 44100
		pcm "plug:meinPlug"
	}
}

Habe ich den Inhalt deiner Zitate falsch kombiniert?
andere Vorschläge?

[smutbert]

Ich habe

Code: Alles auswählen

ecasound -a:1,2 -f 16,2,48000 -i resample,auto,datei1.wav -a:1 -o alsa,plugbtL1 -a:2 -o alsa,plugbtL2

sowohl mit
datei1.wav als auch mit datei.wav getestet, ebenso mit 44100. Funktioniert in allen Fällen, allerdings kommt's zu den vermuteten underruns. Über "Pufferspeicher" und wie man den eventuell händelt, weiß ich noch nichts. Obwohl..., ich erinnere mich, hatten wir das nicht schon mal im Zusammenhang mit dem Begriff Latenz?

Ja, es hängt mit der Latenz und den Anforderungen an das System zusammen.

Je kleiner der Pufferspeicher um so niedriger die Latenz, aber umso höher die Anforderungen an das System. Ohne weitere Optionen verwendet ecasound wohl einen sehr kleinen Pufferspeicher. Bei mir hat es mit

Code: Alles auswählen

ecasound -b:non-rt -B:8192 -a:1,2 -f:16,2,48000 -i resample,auto,datei1.wav -a:1 -o alsa,plugbtL1 -a:2 -o alsa,plugbtL2

sehr gut funktioniert.
Wenn die Latenz (bei Videos) störend wird, kannst du es mit 4096 statt 8192 probieren oder sollten die 8192 nicht genügen, dann mit 16384.

Allerdings ist die Synchronisation zwischen Audio und Video sowieso schon einer Herausforderung, der sich meines Wissens erst Pulseaudio und Wayland soweit möglich vollständig stellen.

Mit X11 und mit unseren Umwegen über die Loopbacksoundkarte und ecasound, zu denen dann auch noch die prinzipbedingte Latenz von Bluetooth dazukommt, lässt es sich möglicherweise gar nicht vermeiden, dass der Ton schon störend dem Bild hinterherhinkt. Zumindest lässt sich das aber in vlc kompensieren (durch Drüclen von <k> kann man das Bild in 50ms-Schritten solange verzögern bis es zum Ton passt).
Aber soweit sind wir ja noch nicht ☺

Die letzte funktionierende asoundrc habe ich aus den folgenden Gründen noch nicht geändert. (Über Sicherungskopien brauchen wir hier nicht zu reden, das ist mir schon klar, dass es bei der komplexen Testerei nicht ohne geht.)

Mir ist unklar, wie ich mit dem Inhalt der folgenden drei Zitate (in Kombination?) umgehen soll:

Das habe ich nur zur Erklärung geschrieben, weil die Idee mit den zwei plugs hintereinander an sich schon etwas merkwürdig ist (und offensichtlich gar nicht zum Erfolg beigetragen hat).

[...]

oder so

[...]

Habe ich den Inhalt deiner Zitate falsch kombiniert?
andere Vorschläge?

Die erste Idee kann nicht funktionieren. Es ungefähr so zu formulieren könnte zwar funktionieren, aber ich bin mir jetzt gar nicht sicher wie es korrekt aussehen könnte.

Das zweite stimmt fast, allerdings würdest du damit sogar 3 plugs hintereinander schalten von denen zwei hintereinander lediglich auf 44100 Hz umrechnen, das in der Verarbeitungsreihenfolge mittlere Plugin kann also gar nichts zu tun bekommen.
(Und obendrein wird auch das dritte nichts mehr tun.)

Richtig sähe es so aus

Code: Alles auswählen

[...]
pcm.meinPlug {
	type plug
	slave.rate 44100
	slave.pcm "plugbtL1"
}

pcm.plugbtL1
	type plug
	slave {
		rate 44100
		pcm "meinPlug"
	}
}

Was aber immer noch unsinnig ist, weil die beiden plugs genau dasselbe machen.

wobei

Code: Alles auswählen

slave.rate a
slave.pcm "x"

dasselbe ist wie

Code: Alles auswählen

slave {
	rate a
	pcm "x"
}

Ich würde also bei der bereits funktionierenden Variante bleiben und nur das "plug:" aus plugbtL1 und 2 entfernen, sodass aus

Code: Alles auswählen

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

Code: Alles auswählen

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

wird. (Dasselbe auch für btL2, nur eben mit 48000 Hz.)

[fischig]

Code: Alles auswählen

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

(Dasselbe auch für btL2, nur eben mit 48000 Hz.)

Das funktioniert nicht, wobei ich noch überlege, ob's möglicherweise daran liegt, dass du die Zahlen verwechselt hast (in der funktionieren Version steht unter plugbtL1 48000 und unter plugbtL2 44100).

Ansonsten frage ich mich, wenn wir aus

Code: Alles auswählen

 pcm "plug:btL1"

,

Code: Alles auswählen

pcm "btL1"

machen, wo in der neuen Variante jetzt das zweite plug-Plugin bleibt, von dem du meintest, dass es nötig sei.

Weiterhin ist mir ein Rätsel, wieso ausgerechnet bei plugbtL2 die 44100 verlangt werden. Das repräsentiert den Kopfhörer und den halte ich qualitativ für deutlich besser als den Billig-Werbelautsprecher an plugbtL1.

Ich denke, im ecasound-Kommando etwas mit den Raten und Formaten zu machen ist zwecklos, zumindest habe ich da bisher nichts Funktionierendes gehört.

[fischig]

Code: Alles auswählen

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

(Dasselbe auch für btL2, nur eben mit 48000 Hz.)

Das funktioniert nicht, wobei ich noch überlege, ob's möglicherweise daran liegt, dass du die Zahlen verwechselt hast (in der funktionieren Version steht unter plugbtL1 48000 und unter plugbtL2 44100).

Ansonsten frage ich mich, wenn wir aus

Code: Alles auswählen

 pcm "plug:btL1"

,

Code: Alles auswählen

pcm "btL1"

machen, wo in der neuen Variante jetzt das zweite plug-Plugin bleibt, von dem du meintest, dass es nötig sei.

Weiterhin ist mir ein Rätsel, wieso ausgerechnet bei plugbtL2 die 44100 verlangt werden. Das repräsentiert den Kopfhörer und den halte ich qualitativ für deutlich besser als den Billig-Werbelautsprecher an plugbtL1.

Ich denke, im ecasound-Kommando etwas mit den Raten und Formaten zu machen ist zwecklos, zumindest habe ich da bisher nichts Funktionierendes gehört.

Um Missverständnissen vorzubeugen hier nochmal die letzte funktioniernde asoundrc:

Code: Alles auswählen

# asoundrc-doppelt3
# Diese asoundrc bringt das Gewünschte: Mit „ecasound -a:1,2 -i [datei1].wav -a:1 -o alsa,plugbtL1 -a:2 -o alsa,plugbtL2“
# wird der Ton von [datei1].wav synchron auf beiden Lautsprechern ausgegeben.

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 {			# Kopfhörer-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 44100
		pcm "plug:btL2"
	}
}

[smutbert]

Ja, hab 1 und 2 verwechselt. Ich meine es so herum, wie ich es davor schon gepostet hatte

Code: Alles auswählen

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

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

Das zweite plug fällt dann weg. Vielleicht habe ich mich missverständlich ausgedrückt, aber das mit dem zweiten Plug war nur ein Versuch, der wie ich meine nichts gebracht hat.
Funktioniert hat es ja erst als du bei btL1 48000 Hz und bei btL2 44100 Hz eingetragen hast und ich hoffe sehr, dass das genauso mit nur einem plug funktioniert.

Das kannst du dann wie gehabt mit

Code: Alles auswählen

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

testen.

Ich denke, im ecasound-Kommando etwas mit den Raten und Formaten zu machen ist zwecklos, zumindest habe ich da bisher nichts Funktionierendes gehört.

ecasound übernimmt das Format von der Eingabe, wenn nichts angegeben wird und wir hatten schon jede Menge, zum Teil mir nicht vertraute, Sampleformate, die dann zu Problemen geführt haben.
Daher würde ich ecasound die Eingabe schon auf ein bestimmtes Format umrechnen lassen. Wenn also der obige, vetraute ecasound-Befehl funktioniert, wäre der nächste Test

Code: Alles auswählen

ecasound -b:non-rt -B:8192 -a:1,2 -f:16,2,48000 -i resample,auto,datei1.wav -a:1 -o alsa,plugbtL1 -a:2 -o alsa,plugbtL2

Wenn auch das funktioniert, können wir wieder die Loopbacksoundkarte „einbauen“ und damit den Ton von beliebigen Programmen an plugbtL1 oder plugbtL2 oder beide weiterleiten.

[...]
Weiterhin ist mir ein Rätsel, wieso ausgerechnet bei plugbtL2 die 44100 verlangt werden. Das repräsentiert den Kopfhörer und den halte ich qualitativ für deutlich besser als den Billig-Werbelautsprecher an plugbtL1.
[...]

Das hat nichts mit der Qualität zu tun. Der Unterschied ist, dass mit 44100 Frequenzen bis zu 22050 Hz und mit 48000 Hz bis zu 24000 Hz dargestellt werden können (jeweils die halbe Samplerate), aber beides ist weit genug über der höchsten Frequenz angesiedelt, die ein Mensch hören kann, dass das keine Rolle spielt.

Sonst hält es eher vom Zufall an ob ein Bluetoothlautsprecher oder -kopfhörer oder sonstige Audiohardware 44100 oder 48000 oder beide Sampleraten unterstützt.