(gelöst) bluealsa, ~/.asoundrc

[smutbert]

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]

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.

[smutbert]

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 sox) 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]

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]

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.

[smutbert]

ich lese interessiert mit

[fischig]

Mann o Mann, es bleibt ein endloses Geraffel. Der versuchte Umzug des Lautsprechers (nicht des Controllers) hat nicht funktioniert. Zitieren von (Felermeldungen) erspare ich mir einstweilen, waren für mich zu verwirrend. Und die Wiederanbindung an den eeepc habe ich dann erwartungsgemäß auch nur noch über eine komplette Neukonfiguration zuwege gebracht. Irgendwie kommt es mir so vor, dass der Lautsprecher (auf den ich keinen Einfluss habe), je nachdem womit er zuletzt verbunden war, Einstellungen an Debian-Systeme rückmeldet, die diese dann durcheinanderbringen. Erschwerend hinzu kam, dass diese eeepcs die unangenehme Eigenschaft haben, beim Booten im Bios gelegentlich die Camera ein- und zum Ausgleich das wlan auszuschalten Hat ne Weile gedauert, bis ich's realisiert hatte. Ich werde mich wieder melden, wenn ich das Thinkpad erneut in Angriff nehme. Mittlerweile ist es mir ziemlich egal, welche Klimmzüge ich anschließend wieder mit dem eeepc anstellen muss. Und eine für mich befriedignede bluetooth-Lösung mit Debian erwarte ich schon gar nicht mehr.

[fischig]

So, was den eeepc betrifft: es bleibt unzuverlässig. Die Einrichtung an sich ist simpel und funktioniert. Warum sie mitunter den Geist aufgibt und dann womöglich komplett neu aufgezogen werden muss, kann ich momentan nicht sagen, da sie z.Z. (leider! ) funktioniert.

Ich habe aber noch ein paar Fragen zur .asoundrc, deren Beantwortung ich gerne als Kommentar reinschriebe.
1. Die asoundrc sieht jetzt so aus:

Code: Alles auswählen

pcm.GO2_SOFTVOL {
  type softvol
  slave.pcm "GO2"
  control.name "GO2_Laut"
  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
}

Der Bezeichner „GO2_SOFTVOL“ ist beliebig und kann unter Beachtung von Regeln geändert werden - richtig?

„softvol“ ist eines dieser alsa-plugins und zuständig für Lautstärkeregelung - richtig?
„slave.pcm "GO2"“ Wer ist hier Herr und wer Sklave und wie hat man sich dieses Herr-Knecht-Verhältnis vorzustellen?
„control.name "GO2_Laut"“ „GO2_Laut“ ist Name des Reglers, und unter diesem Namen erscheint er dann auch in der Mixersoftware, hier benutzt: alsa- und qasmixer. Der Name ist wieder (relativ) frei wählbar - richtig?
„control.card 0“ Der Regler arbeitet auf der 1. Soundkarte. Statt der 0 hätte ich auch den in eckigen Klammern hinter der 0 stehenden Namen verwenden können, wie er mit

Code: Alles auswählen

cat /proc/asound/cards

angegeben wird und smutbert präferiert letzteres - richtig?

Ich hatte im Abschnitt pcm.GO2_SOFTVOL auch mal den Namen "GO2_s" verwendet. Der erscheint (funktionslos) auch nach Neustart immer noch in den beiden Mixern, genauso wie „GO2“. Was soll/wie kommt das? Ich hatte zwischenzeitlich mal eine Datei entdeckt, von der ich annahm, dass da die Reglernamen drinstehen, weiß aber jetzt nicht mehr wo. Kann's mir jemand veraten und könnte ich die beiden überflüssigen da rauswerfen, vielleicht auch die restlichen Namen sinnvoller ordnen? Zumindest mit GO2_s sollte das doch möglich sein, das Rauswerfen?

Bei meinen eigenen Recherchen bin ich auf folgendes gestoßen:

Nehmen wir mal an, das Kommando

Code: Alles auswählen

cat /proc/asound/cards

meldet mir drei Soundkarten:

Code: Alles auswählen

0 ...
1 [schneewittchen   ] ...
2 ...

dann machte ich mit der Anlage einer ~/.asoundrc mit diesem Inhalt:

Code: Alles auswählen

pcm.!default {
    type hw
    card schneewittchen
}

diese Karte (Nr.1, schneewittchen) zur voreingestellten Soundkarte, wobei „voreingestellt“ hier meint: Unabhängig davon, welche Karte alsa ohne diese asoundrc womöglich als voreingestellte Soundkarte benutzte, griffe alsa, wann immer ich was mit sound anfangen wollte, auf diese Karte Nr.1 zu, vorausgesetzt ich gäbe nicht explizit an, dass eine andere benutzt werden soll.
Entscheidend dabei ist „!default“ womit ich alsas default überschriebe.

Im df-wiki passiert das gleiche mit

Code: Alles auswählen

defaults.pcm.!card 1

?
Sind diese Überlegungen soweit korrekt?

edit:
Ach ja, und noch was was mir wichtig ist: kann man/wie kann man denselben Ton einer Anwendung an zwei (Bluetooth-Kopfhörer weiterreichen)?

[smutbert]

Der Bezeichner „GO2_SOFTVOL“ ist beliebig und kann unter Beachtung von Regeln geändert werden - richtig?

ja

„softvol“ ist eines dieser alsa-plugins und zuständig für Lautstärkeregelung - richtig?

ja

„slave.pcm "GO2"“ Wer ist hier Herr und wer Sklave und wie hat man sich dieses Herr-Knecht-Verhältnis vorzustellen?

Herr ist (pcm.)GO2_SOFTVOL und dessen Sklave GO2 ist das pcm-Ding, an das das lautstärkegeregelte Signal weitergeleitet wird.

„control.name "GO2_Laut"“ „GO2_Laut“ ist Name des Reglers, und unter diesem Namen erscheint er dann auch in der Mixersoftware, hier benutzt: alsa- und qasmixer. Der Name ist wieder (relativ) frei wählbar - richtig?

ja

„control.card 0“ Der Regler arbeitet auf der 1. Soundkarte. Statt der 0 hätte ich auch den in eckigen Klammern hinter der 0 stehenden Namen verwenden können, wie er mit

Code: Alles auswählen

cat /proc/asound/cards

angegeben wird und smutbert präferiert letzteres - richtig?

ja

Ich hatte im Abschnitt pcm.GO2_SOFTVOL auch mal den Namen "GO2_s" verwendet. Der erscheint (funktionslos) auch nach Neustart immer noch in den beiden Mixern, genauso wie „GO2“. Was soll/wie kommt das? Ich hatte zwischenzeitlich mal eine Datei entdeckt, von der ich annahm, dass da die Reglernamen drinstehen, weiß aber jetzt nicht mehr wo. Kann's mir jemand veraten und könnte ich die beiden überflüssigen da rauswerfen, vielleicht auch die restlichen Namen sinnvoller ordnen? Zumindest mit GO2_s sollte das doch möglich sein, das Rauswerfen?

Das Rauswerfen ist etwas verzwickt
Die Existenz des Reglers merkt sich Alsa einerseits während Linux läuft und andererseits werden die Reglerstellungen beim Herunterfahren in der »/var/lib/alsa/asound.state« gespeichert.

Ich glaube es ist gar nicht so einfach einen Regler aus der »/var/lib/alsa/asound.state« zu entfernen, aber das Verzwickte liegt daran, dass der Regler, selbst wenn du im laufenden System die »/var/lib/alsa/asound.state« löscht, immer noch in Alsa existiert und beim Herunterfahren neu in dieser Datei gespeichert wird. Beim nächsten Systemstart ist er dann erst wieder da, wenn die Werte aus der »/var/lib/alsa/asound.state« eingelesen werden.

Ich kenne zwei Möglichkeiten den Regler trotzdem loszuwerden:

1. Ein anderes Linux von USB, CD/DVD, Diskette,... starten und von dem aus die »/var/lib/alsa/asound.state« löschen oder
2. Das Startskript von alsa-utils (»/etc/init.d/alsa-utils«) vorübergehend deaktivieren, so das System starten die »/var/lib/alsa/asound.state« löschen und einen Neustart später das alsa-utils-Startskript wieder aktivieren.

(Statt dem Löschen von »/etc/init.d/alsa-utils« würde es in beiden Fällen auch genügen nur den unerwünschten Regler rauszulöschen, aber ich muss zugeben, dass ich noch nie in die »/var/lib/alsa/asound.state« gesehen habe und nicht einmal sicher bin, dass sie „menschenlesbar“ ist.)

[...]
dann machte ich mit der Anlage einer ~/.asoundrc mit diesem Inhalt:

Code: Alles auswählen

pcm.!default {
    type hw
    card schneewittchen
}

diese Karte (Nr.1, schneewittchen) zur voreingestellten Soundkarte, wobei „voreingestellt“ hier meint: Unabhängig davon, welche Karte alsa ohne diese asoundrc womöglich als voreingestellte Soundkarte benutzte, griffe alsa, wann immer ich was mit sound anfangen wollte, auf diese Karte Nr.1 zu, vorausgesetzt ich gäbe nicht explizit an, dass eine andere benutzt werden soll.
Entscheidend dabei ist „!default“ womit ich alsas default überschriebe.

Im df-wiki passiert das gleiche mit

Code: Alles auswählen

defaults.pcm.!card 1

?
Sind diese Überlegungen soweit korrekt?

Es erfüllt denselben Zweck ist aber nicht ganz genau das gleiche:

• Code: Alles auswählen

  pcm.!default {
  	type hw
  	card schneewittchen
  }

  legt direkt hw:schneewittchen als Standard fest. Die Ausgabe von einem Alsaprogramm läuft dann, wenn nicht explizit etwas anderes angegeben wird, direkt an das Hardwareplugin von Alsa (hw).
  Sollten Hardware/Treiber das Audioformat der Anwendung nicht unterstützen, dann scheitert die Wiedergabe.

• Code: Alles auswählen

  defaults.pcm.!card schneewittchen

  Verwendet nach wie vor die systemweite Standardkonfiguration von Alsa, es wird Alsa nur mitgeteilt, dass der Ton doch am Ende bitte an der angegeben Soundkarte schneewitchen landen möge. Das bedeutet dass das Audiosignal den systemweit vorkonfigurierten Pfad durch mehrere Alsaplugins nimmt, das wären zumindest plug zum Konvertieren des Audioformats und dmix, damit mehrere Anwendungen gleichzeitig Töne wiedergeben können, je nach Audiohardware ist ja auch noch ein softvol-Plugin dazwischen (dessen Regler dann PCM heißt).

edit:
Ach ja, und noch was was mir wichtig ist: kann man/wie kann man denselben Ton einer Anwendung an zwei (Bluetooth-Kopfhörer weiterreichen)?

Mit dem Thema geht es unter dem Titel „Bluealsa mit simultaner Tonausgabe auf zwei Geräten“ hier weiter: viewtopic.php?f=25&t=177552