(gelöst) bluealsa, ~/.asoundrc

[fischig]

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]

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?

[smutbert]

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]

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.

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]

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

[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