(gelöst) bluealsa, ~/.asoundrc

[fischig]

Ich mach' das Ding mal wieder auf.
Wenn ich unsere asoundrc aus dem Weg schaffe, dann kommt mit

Code: Alles auswählen

/usr/bin/mplayer -really-quiet -prefer-ipv4 -playlist .system/radiosender/hrinfo_2.m3u

der Ton aus dem internen Lautsprecher.
Aktiviere ich die Datei wieder und ändere den Mplayer-Aufruf ab:

Code: Alles auswählen

/usr/bin/mplayer -ao alsa:device=GO2* -really-quiet -prefer-ipv4 -playlist .system/radiosender/hrinfo_2.m3u

dann kommt der Ton erwartungsgemäß aus dem BT-Lausprecher. In beiden Fällen lese ich im Terminal:

Code: Alles auswählen

do_connect: could not connect to socket

Kann man das ignorieren?
Ich bin andererseits soweit, dass ich via shellscript in einer Variablen lesen kann, ob der BT-Lautsprecher aktiv (connected) ist.

* Ich habe meinen Namen für den BT-Lautsprecher nochmal von btgo auf GO2 geändert, aus Gründen, die hier irrelevant sein dürften.

[smutbert]

[...]
In beiden Fällen lese ich im Terminal:

Code: Alles auswählen

do_connect: could not connect to socket

Kann man das ignorieren?
[...]

Das hängt davon ab, ob die Funktion, die für diese Fehlermeldung verantwortlich ist, brauchst. Das ist die Steuerung mittels lirc. Das ist u.a. ein Dämon zur Steuerung mittels IR-Fernbedienungen, der die Befehle über einen Socket anderen Programmen zur Verfügung stellt.
Wenn der nicht läuft, etwa weil du lirc nicht installiert hast, ist der Socket natürlich nicht vorhanden und du kannst die Meldung getrost ignorieren.

[...]
Aktiviere ich die Datei wieder und ändere den Mplayer-Aufruf ab:

Code: Alles auswählen

/usr/bin/mplayer -ao alsa:device=GO2* -really-quiet -prefer-ipv4 -playlist .system/radiosender/hrinfo_2.m3u

dann kommt der Ton erwartungsgemäß aus dem BT-Lausprecher.

Das „-ao alsa:device=GO2“ sollte ja eigentlich notwendig sein, wenn ich mit der »~/.asoundrc« am aktuellen Stand bin, weil wir dort bluetooth ja zum Default machen. Zum Umschalten sowohl »~/.asoundrc« wie auch den mplayer-Befehl zu ändern ist irgendwie doppelt gemoppelt.


Es sollte genügen, entweder

1. die »~/.asoundrc« zu deaktivieren/ändern oder
2. in der »~/.asoundrc« nur das Gerät GO2 zu definieren

   Code: Alles auswählen

   pcm.GO2 {
   	type		bluealsa				# für Bluetooth zuständiges Alsa-Plugin
   	interface	"hci0"				# Name des Bluetooth-Adapters
   	device	"30:C0:1B:72:63:8E"	# MAC-Adresse des Bluetoothgeräts (via bluetoothctl)
   	profile	"a2dp"				# Bluetooth-Profil
   }
   

   sie immer so zu lassen und dafür die beiden unterschiedlichen mplayer-Befehle zu nutzen, also einmal mit und einmal ohne „-ao alsa:device=GO2“

Wenn du mehr Aufwand treiben willst, wäre durchaus auch noch eine Lösung denkbar, mit der du halb- oder ganz automatisch auch bei laufender Wiedergabe zwischen den beiden Wiedergabegeräten umschalten kannst. (Eine Idee hätte ich...)

[fischig]

„Steuerung mittels lirc“. Dass lirc bei dieser Meldung involviert ist, hatte ich bei meinen Recherchen bereits bemerkt. Hier wird lirc z.Z. nicht benutzt. Ignoriere ich also.

Zum Umschalten sowohl »~/.asoundrc« wie auch den mplayer-Befehl zu ändern ist irgendwie doppelt gemoppelt.

Wenn Ziel ist, im Bedarfsfall den internen Lautsprecher zu benutzen, dann sehe ich bei der gegebenen asoundrc (pcm_!default ...) nur die Möglichkeit des „doppelt Gemoppelten“:
Wenn ich asoundrc deaktiviere, kriege ich mit „-ao alsa:device=GO2“ in mplayer keinen Ton
daktiviere ich sie nicht, dann kriege ich ohne „-ao alsa:device=GO2“ in mplayer auch keinen Ton.
Ich muss also die asoundrc deaktivieren UND das mplayer-Kommando ohne die genannte Funktion benutzen.
Will ich dagegen den BT-Lautsprecher benutzen, ist es wieder „doppelt gemoppelt“: asoundrc muss aktiviert sein UND die Option muss im mplayer-Kommando stehen, sonst funktioniert's nicht. Korrigier' mich, wenn ich einen Denkfehler gemacht habe.

Sympathischer ist dein zweiter Vorschlag. Damit reduziert sich der Aufwand tatsächlich auf's Mplayer-Kommando.

Unabhängig davon:
Kann man die für BT vorgesehene Option des Mplayer-Kommandos in eine Variable packen? Ich stelle mir vor: leere Variable für intern, und „-ao alsa:device=GO2“ für BT.

Wenn du mehr Aufwand treiben willst, wäre durchaus auch noch eine Lösung denkbar, mit der du halb- oder ganz automatisch auch bei laufender Wiedergabe zwischen den beiden Wiedergabegeräten umschalten kannst. (Eine Idee hätte ich...)

Darauf bin ich schon gespannt! Vordringlicher erscheint mir aber eine Lösung für die softwareseitige Lautstärkeregelung. Wenn ich den BT-Lautsprecher benutze, muss ich die dessen Lautstärkeregelung (Druckknöpfe für lauter/leiser) benutzen. Weder alsa- noch qasmixer funktionieren. Eine feste Lautstärke-Vorgabe im Mplayer-Kommando meine ich schon angelesen - aber als unpraktisch beiseite gelegt zu haben.

Noch 'ne Beobachtung am Rande: Ich hatte hier oder im anderen Thread erwähnt, dass ich bei bluealsa den gepaarten BT-Lautsprecher lediglich einschalten, ihn nicht mehr per bluetoothctl verbinden muss (was ich bei Verwendung von pulse zumindest glaubte tun zu müssen). Heute morgen war das aber auch bei bluealsa erforderlich. War das Zufall? Als ich es reproduzieren wollte, war das händische Verbinden wieder unnötig.Kann es sein, dass das automatische Verbinden keine Sitzung überlebt?

[smutbert]

[...]
Wenn Ziel ist, im Bedarfsfall den internen Lautsprecher zu benutzen, dann sehe ich bei der gegebenen asoundrc (pcm_!default ...) nur die Möglichkeit des „doppelt Gemoppelten“:
Wenn ich asoundrc deaktiviere, kriege ich mit „-ao alsa:device=GO2“ in mplayer keinen Ton

Das ist normal, immerhin gibt es dann für Alsa kein Gerät GO2.

[...]
daktiviere ich sie nicht, dann kriege ich ohne „-ao alsa:device=GO2“ in mplayer auch keinen Ton.

Wenn das bei verbundenen Bluetoothlautsprecher so ist, müssten wir an dieser Stelle anfangen den Fehler zu suchen. Vielleicht hast du wieder einen Tippfehler eingebaut (dfault?) oder ich habe schon beim Posten irgendeinen Unsinn eingebaut.

Im allgemeinen Fall braucht man (ohne Pulseaudio) immer eine .asoundrc bzw. asound.conf um das Defaultgeräte festzulegen. (Man kann ja auch ohne Bluetooth nicht davon ausgehen, dass hw:0,0, so es denn überhaupt existiert, das gewünschte Standardaudioausgabegerät ist.)

[...]
Sympathischer ist dein zweiter Vorschlag. Damit reduziert sich der Aufwand tatsächlich auf's Mplayer-Kommando.

Ja, ist möglicherweise übersichtlicher. Selbst bei dieser zweiten Variante kann es sinnvoll sein, für beide Szenarien (Bluetooth und interner Lautsprecher) selbst Geräte in der .asoundrc zu definieren

[...]
Unabhängig davon:
Kann man die für BT vorgesehene Option des Mplayer-Kommandos in eine Variable packen? Ich stelle mir vor: leere Variable für intern, und „-ao alsa:device=GO2“ für BT.

Natürlich. Es gibt einmal die offensichtliche Möglichkeit

Code: Alles auswählen

$ MPLAYER_OPTIONS="-ao alsa:device=GO2"
$ /usr/bin/mplayer ${MPLAYER_OPTIONS} -really-quiet -prefer-ipv4 -playlist .system/radiosender/hrinfo_2.m3u

Für die Wiedergabe ohne Bluetooth kannst du die Variable einfach löschen oder ihr einen leeren String zuweisen und danach denselben Befehl verwenden

Code: Alles auswählen

$ MPLAYER_OPTIONS=""

oder

Code: Alles auswählen

$ unset MPLAYER_OPTIONS

und danach

Code: Alles auswählen

$ /usr/bin/mplayer ${MPLAYER_OPTIONS} -really-quiet -prefer-ipv4 -playlist .system/radiosender/hrinfo_2.m3u

[...]

Wenn du mehr Aufwand treiben willst, wäre durchaus auch noch eine Lösung denkbar, mit der du halb- oder ganz automatisch auch bei laufender Wiedergabe zwischen den beiden Wiedergabegeräten umschalten kannst. (Eine Idee hätte ich...)

Darauf bin ich schon gespannt!

Die Idee wäre eine virtuelle Soundkarte zu verwenden, über die wiedergegeben wird. Dann hört man erst einmal nichts.

Aber die virtuelle Soundkarte stellt den Ton über ein virtuelles Aufnahmegerät wieder zu Verfügung. Dann muss man nur noch diesen Ton aufnehmen und gleich wieder über die echte Audiohardware (eingebaute oder Bluetooth Lautsprecher) wiedergeben.
Das schöne an dieser etwas umständlichen Lösung wäre, dass weder mplayer beendet und neu gestartet, noch die .asoundrc verändert werden muss - ja es muss nicht einmal die Wiedergabe mit mplayer angehalten werden.

[...]
Vordringlicher erscheint mir aber eine Lösung für die softwareseitige Lautstärkeregelung.

Wenn mplayer selbst keine Softwarelautstärkeregelung bietet (ich glaube das tut mplayer mit der Option „-softvol“) dann gäbe es die Möglichkeit das softvol-Plugin von alsa zwischenzuschalten. Den Lautstärkeregler kann man aber nur bei einem vorhanden Audiogerät zusätzlich „einblenden“ – das ist auf den ersten Blick nicht so leicht zu durchschauen.

Du hast ja jetzt schon einige Plugins selbst hintereinander geschaltet (plug und bluealsa). Vielleicht hilft dir „mein“ Wiki-Artikel ja schon ein Stück weit weiter:
https://wiki.debianforum.de/Audiokonfig ... .C3.BCsten
(Das soll aber nicht heißen, dass ich dir hier nicht mehr weiterhelfe.)

[...]
Noch 'ne Beobachtung am Rande: Ich hatte hier oder im anderen Thread erwähnt, dass ich bei bluealsa den gepaarten BT-Lautsprecher lediglich einschalten, ihn nicht mehr per bluetoothctl verbinden muss (was ich bei Verwendung von pulse zumindest glaubte tun zu müssen). Heute morgen war das aber auch bei bluealsa erforderlich. War das Zufall? [...]

Meines Wissens ist das Zufall.
Manchmal funktioniert das automatische Verbinden sehr schnell, manchmal dauert es länger und gelegentlich scheint es gar nicht funktionieren zu wollen. Es sollte immer funktionieren, aber Bluetooth war meiner Erfahrung nach unter GNU/Linux immer schon eine etwas „wackelige“ Angelegenheit.

[fischig]

Schon mal vorab, mit dem Übrigen bin ich noch beschäftigt und habe aktuell wenig Zeit, mich länger als geschätzt eine Dreiviertelstunde damit zu beschäftigen:

Im allgemeinen Fall braucht man (ohne Pulseaudio) immer eine .asoundrc bzw. asound.conf um das Defaultgeräte festzulegen.

Ich weiß nicht, ob man allgemein ein Defaultgerät festlegen muss, aber ich habe hier zumindest eine Maschine, die weder über eine /etc/asound.conf noch über eine ~/.asoundrc verfügt und deren audiovisuellen Programme dennoch Töne von sich geben.

Die Variablisierung funktioniert nach etlichen Schreibversuchen!
Ich liebe Shell-Syntax!

Damit könnte man schon mal grob leben.

Deinen Wiki-Artikel besuche ich häufig bei Fragen zum Sound. Wenn wir hiermit fertig sind, hätte ich da noch ein paar Anmerkungen. Mach ich dann aber per PN.

edit:

Wenn mplayer selbst keine Softwarelautstärkeregelung bietet (ich glaube das tut mplayer mit der Option „-softvol“) dann gäbe es die Möglichkeit das softvol-Plugin von alsa zwischenzuschalten.

Das vermag ich mir einstweilen hier noch nicht plastisch vorzustellen.
Zum Mplayer: Ich benutze den als Radio, Keine GUI. (Die Sender stehen in menu.xml von openbox). Ich habe keine Vorstellung, wie ich dabei durch Aktivieren der softvol-Option die Lautstärke regeln könnte.
Zum alsa-plugin. Wo müsste das hin und würde das wieder eine Lautstärkereglung via alsamixer/qasmixer erlauben?

[smutbert]

[...]aber ich habe hier zumindest eine Maschine, die weder über eine /etc/asound.conf noch über eine ~/.asoundrc verfügt und deren audiovisuellen Programme dennoch Töne von sich geben.

Dass es so ist habe ich schon mitbekommen, aber das ist reines Glück.
Abhängig von Hardware und Kernel könnte das auch anders sein, sich etwa mit Kernelupdates ändern oder auch nur rein zufällig von Systemstart zu Systemstart. (Im wesentlichen ist es dasselbe Problem, wie früher mit mehreren Netzwerkschnittstellen (eth0, eth1,...) oder den Gerätedateien für Festplatten/SSDs, da hängt es auch oft vom Zufall ab welches Gerät /dev/sda, /dev/sdb,... wird. Und ganz ähnlich wie man deswegen bei Dateisystemen auf die gleich bleibenden UUIDs oder Label ausweicht, kann man auch in der .asoundrc Namen statt Nummern eintragen.)

Deinen Wiki-Artikel besuche ich häufig bei Fragen zum Sound. Wenn wir hiermit fertig sind, hätte ich da noch ein paar Anmerkungen. Mach ich dann aber per PN.

Ich bitte darum – vielleicht kann ich mich dann auch endlich einmal aufraffen den Artikel zu ergänzen.

edit:

Wenn mplayer selbst keine Softwarelautstärkeregelung bietet (ich glaube das tut mplayer mit der Option „-softvol“) dann gäbe es die Möglichkeit das softvol-Plugin von alsa zwischenzuschalten.

Das vermag ich mir einstweilen hier noch nicht plastisch vorzustellen.
Zum Mplayer: Ich benutze den als Radio, Keine GUI. (Die Sender stehen in menu.xml von openbox). Ich habe keine Vorstellung, wie ich dabei durch Aktivieren der softvol-Option die Lautstärke regeln könnte.
Zum alsa-plugin. Wo müsste das hin und würde das wieder eine Lautstärkereglung via alsamixer/qasmixer erlauben?

irgendwie musst du ihn ja trotzdem steuern, zB um zwischen den Sendern umschalten zu können?
(Ich bemühe mich ja schon lange und ganz besonders im Debianforum niemanden von einem bestimmten Programm abzuraten oder ihm etwas aufzuschwatzen, aber ich mag und kenne mplayer nicht besonders gerne/gut und so wie du es beschreibst ist es mich DAS Einsatzgebiet von mpd. Läuft im Hintergrund, lässt sich bequem mit grafischen oder Textclients steuern. Skripte zur Steuerung lassen sich vergleichsweise einfach schreiben. mpd hat eine Softwarelautstärkeregelung eingebaut und das Umschalten zwischen unterschiedlichen Wiedergabegeräten ist auch ziemlich einfach.)

Aber, ja mit dem Alsaplugin sollte man in qasmixer und alsamixer einen weiteren Regler erhalten, mit dem man die Lautstärke natürlich nach belieben regeln kann (also im Vergleich zur nicht vorhandenen Alsalautstärkeregelung kann man damit desn Ton nach belieben leiser machen - lauter als ohne Softwarelautstärkeregelung wird es nicht).

[fischig]

irgendwie musst du ihn ja trotzdem steuern, zB um zwischen den Sendern umschalten zu können?

Das funktioniert völlig simpel: Rechtsklick auf die openbox-GUI und im (selbsterstellten) Untermenü „Sender“ erscheint dann meine Senderauswahl. Und mit Linksklick auf einen derselben wird dann eines der enstsprechenden mplayer-Kommandos gestartet. (Ich glaube, ich habe das abgewandelt mal bei uname geklaut). Nichtsdestotrotz: deine mpd-Empfehlung habe ich auf dem Schirm. Und wenn ich hier fertig bin, probiere ich den Transfer.

Wo muss das alsa-plugin hin? Ich recherchiere zwischenzeitlich selber, frage aber schon mal prophylaktisch.

[fischig]

Mittlerweile beschleicht mich eine Idee, wo das alsa-plugin hin soll, nämlich nach ~/.asoundrc - richtig?

Allerdings erschließt sich mir die Syntax immer noch nicht. Ich fang mal am Anfang an: Jede asoundrc/asound.conf, die ich bisher gesehen habe, beginnt mit pcm und jede Anleitung für asoundrc/asound.conf, die ich eingesehen habe, drückt sich darum herum, zu erklären, was zur Hölle alsa damit zu schaffen hat. Aus dem wikipedia-Artikel für PCM bleibt bei mir nur hängen, dass da was Analoges in was Digitales umgewandelt wird. Ob ich mehr wissen muss, kann ich momentan nicht beurteilen. Unabhängig davon ist mir der Begriff beim alsamixer ins Auge gefallen, da verstehe ich ihn als einen der Lautstärkeregler, den ich mit einer Ausnahme (vergessen, welche das war) nie benutzt habe. Und hier fällt er mir ständig auf die Füße.

edit:
Wenn ich mir im Wiki den Absatz „Lautstärkeregelung bei digitalen Ausgängen nachrüsten“ anschaue, finde ich mich nicht wieder.

[smutbert]

Keine Angst ich habe schon angefangen einen Beitrag zu schreiben, aber dein letzter Beitrag zeigt, dass ich falsch einschätzt habe wo ich mit der Hilfe ansetzen muss ☺. (Ja .asoundrc/asound.conf ist richtig.)
Um die Zeit werde ich mich so kurz wie möglich halten (mehr Erklärungen folgen bei Gelegenheit):

Wenn ich mir im Wiki den Absatz „Lautstärkeregelung bei digitalen Ausgängen nachrüsten“ anschaue, finde ich mich nicht wieder.

Es ist fast dasselbe. Im Grunde müsstest du nur ein paar Details ändern

Code: Alles auswählen

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

pcm.GO2 {
	type		bluealsa		# für Bluetooth zuständiges Alsa-Plugin
	interface	"hci0"			# Name des Bluetooth-Adapters
	device		"30:C0:1B:72:63:8E"	# MAC-Adresse des Bluetoothgeräts (via bluetoothctl)
	profile		"a2dp"			# Bluetooth-Profil
}

und in mplayer dann für die Wiedergabe

Code: Alles auswählen

/usr/bin/mplayer -ao alsa:device=GO2_SOFTVOL ...

bzw. eben die Variable entsprechend setzen

Code: Alles auswählen

MPLAYER_OPTIONS="-ao alsa:device=GO2_SOFTVOL"

Der Regler sollte dann in

Code: Alles auswählen

$ alsamixer -D hw:0

aufscheinen, aber erst nachdem (!) du schon einmal über dieses neu definierte Gerät wiedergegeben hast. (Meiner Erfahrung nach kann das auch etwas zickig sein, bevor der Regler tatsächlich auftaucht.)

Möglicherweise gibt es noch weitere Fallstricke.

[fischig]

Einstweilen wieder danke sehr! Umsetzungsversuche leider erst heute nachmittag/abend möglich.

[fischig]

Funktioniert ganz hervorragend! Sowohl mit alsamixer als auch mit qasmixer
Die Zeile

Code: Alles auswählen

control.name	"Bluetooth"

Habe ich nochmal umbenannt in

Code: Alles auswählen

control.name	"GO2"

funktioniert ebenfalls problemlos. Die Pazierung finde ich in beiden Mixern ziemlich daneben, aber das ist (piefeklike ) Jammern auf hohem Niveau.

Ich hätte damit erst mal so ziemlich alles, was ich für zweckmäßig halte. Ich zeige den konkreten Ablauf mal, wenn ich's fertig verscriptet habe.

So schön ich das hier fände:

Aber die virtuelle Soundkarte stellt den Ton über ein virtuelles Aufnahmegerät wieder zu Verfügung. Dann muss man nur noch diesen Ton aufnehmen und gleich wieder über die echte Audiohardware (eingebaute oder Bluetooth Lautsprecher) wiedergeben.
Das schöne an dieser etwas umständlichen Lösung wäre, dass weder mplayer beendet und neu gestartet, noch die .asoundrc verändert werden muss - ja es muss nicht einmal die Wiedergabe mit mplayer angehalten werden.

scheint es mir doch sinnvoller, bevor ich mich diesem Projekt zuwende, zunächst mal innezuhalten und zu versuchen, zu kapieren, was ich da eigentlich die ganze Zeit tue. Und in diesem Zusammenhang wiederhole ich meine Frage: Warum beginnt jede asaoundrc, ich denke auch jede asound.conf, die mir bisher untergekommen ist, mit pcm?

Und mal so ganz nebenbei, wann endlich entscheidet sich debian, dieses exzellente bluealsa zu übernehmen? Ich habe bisher mit der Paketsuche keine Treffer bekommen. Ich habe da ja so einen Verdacht, aber ich werde mich hüten, denn öffentlich zu äußern.

[smutbert]

PCM ist die Pulsecodemodulation und schlicht das üblichste Format in dem die Audiodaten vorliegen, egal ob wav, flac, mp3,... Der Ton wird dabei mit aneinandergereihten Werten/Zahlen beschrieben, die einfach ausgedrückt in einem fixen zeitlichen Raster der Auslenkung der Lautsprechermembran aus der Ruhelage entsprechen.
In dem Zusammenhang hier ist eigentlich nur wichtig, dass es bei pcm um Audiodaten geht, die Alsa versteht und manipulieren kann. In der asound.conf/.asoundrc definiert man mit

Code: Alles auswählen

pcm.X {
	...
}

also ein Gerät oder besser eine Instanz eines Alsaplugins, die irgendetwas mit Audiodaten macht. Dabei können die Audiodaten in beide Richtungen fließen (Wiedergabe und Aufnahme) und was mit den Audiodaten passiert ist Sache des Plugins. Die wichtigsten Plugins kennst du wahrscheinlich schon

• hw
  „Liefert“ die Audiodaten bei der Hardware ab (Wiedergabe) bzw. „holt“ sie ab (Aufnahme).
• plug
  Konvertiert zwischen unterschiedlichen Sampleraten, -formaten und Anzahlen der Kanäle (zB Stereo → Mono)
• dmix
  mischt mehrere Audiodatenströme zu einem

Innerhalb der geschwungenen Klammern steht zuallererst das gewünschte Plugin

Code: Alles auswählen

pcm.X {
	type plug
	...
}

und danach können noch die Parameter für dieses Plugin folgen. Lässt man sie weg, gelten die Standardeinstellungen für das Plugin. Wie man diese Standardeinstellungen ändern kann ist dir auch schon untergekommen – das war in deiner ersten Variante der .asoundrc.




pcm ist aber nicht das einzige was es gibt. Es gibt auch Steuergeräte:

Code: Alles auswählen

ctl.X {
	...
}

Definiert ein „Gerät X“ mit dem man etwas steuert. Dieses Steuern beschränkt sich typischerweise auf die Lautstärkeregler, daher nennt man die ctl-Instanzen auch Mixer. Eigentlich dienen solche Absätze auch nur dazu die automatisch vorhandenen Mixer der Audiohardware unter einem neuen Namen zugänglich zu machen.
Einige Programme erwarten nämlich, wenn sie beispielsweise etwas über "pcm.X" wiedergeben sollen, einen gleichnamigen Mixer "ctl.X". Daher war es üblich, dass neben einem "pcm.X" auch immer ein zugehöriges "ctl.X" in der Konfiguration hat.
Bei dir könnte ein solcher zusätzlicher Absatz so aussehen

Code: Alles auswählen

ctl.GO2_SOFTVOL {
	type		hw
	card	0
}

[fischig]

PCM ist die Pulsecodemodulation und schlicht das üblichste Format in dem die Audiodaten vorliegen, egal ob wav, flac, mp3,... Der Ton wird dabei mit aneinandergereihten Werten/Zahlen beschrieben wird, die einfach ausgedrückt in einem fixen zeitlichen Raster die/der Auslenkung der Lautsprechermembran aus der Ruhelage entsprechen.

Sind die Durchstreichungen im Zitat korrekt? Oder habe ich was falsch verstanden?
Das kann ich verstehen, beantwortet aber meine Frage nicht.

Was mich irritiert: Ich habe noch keine alsa-config gesehen, die nicht auf diesen drei Buchstaben basierte, während die im Alsamixer unter "ferner liefen" und für mich bisher eher irrelevant waren. Also nochmal: Wird auf pcm insistiert/warum wird darauf insistiert? Kann man das als so'n Initialisierungscode wie

Code: Alles auswählen

#!/bin/sh

verstehen? (ohne pcm mach' ich gar nichts)

Ich vermute, das Beispiel

Code: Alles auswählen

ctl.X {
	...
}

zieht nicht, weil es nur optionaler Bestandteil einer solchen config ist, während „pcm“ ein notwendiger ist. Korrigier mich, wenn ich falsch liege.

[smutbert]

Sind die Durchstreichungen im Zitat korrekt?

Ja, das Umformulieren des Satz kurz vor dem Absenden des Beitrags ist daneben gegangen.

Also nochmal: Wird auf pcm insistiert/warum wird darauf insistiert? Kann man das als so'n Initialisierungscode wie

Code: Alles auswählen

#!/bin/sh

verstehen? (ohne pcm mach' ich gar nichts)

Jein, eigentlich nicht.
Die Shebang (zB #!/bin/sh) sagt Linux ja nur wie es die Datei ausführen soll, erfüllt also dieselbe Funktion wie die Dateiendung unter Windows.

Das pcm dagegen gibt an, das im folgenden ein Ding definiert wird, das aus Audiodaten entweder entgegennehmen und/oder abgeben kann. Für die Aufnahme oder Wiedergabe brauchst du immer ein pcm-Dings. (Du merkst, dass ich eigentlich keinen guten Namen für diese Dinger kenne, weder auf deutsch noch auf englisch.)

Das heißt noch nicht, dass du das notwendigerweise in deiner .asoundrc haben musst. Viele pcm-Dinger werden bereits in den zahlreichen systemweiten alsa-Konfigurationsdateien unterhalb von »/usr/share/alsa« definiert.
Die Ausgabe von

Code: Alles auswählen

aplay -L

zeigt dir alle wiedergabefähigen pcm-Dinger, genauso wie

Code: Alles auswählen

arecord -L

alle aufnahmefähigen pcm.X zeigt.

[...] zieht nicht, weil es nur optionaler Bestandteil einer solchen config ist, während „pcm“ ein notwendiger ist. Korrigier mich, wenn ich falsch liege.

Du liegst falsch, zumindest theoretisch. Wenn einem ohne weitere Konfiguration zwar das Default-Ausgabegerät passt, nicht aber der Default-Mixer, dann wird man dementsprechend in die asound.conf/.asoundrc vielleicht nur einen Absatz "ctl.!default { … }" und gar nichts mit pcm schreiben.
Es ließen sich auch Situationen konstruieren, in denen man gar nichts wiedergeben oder aufnehmen will, also keine pcm.X braucht sondern nur den Mixer und irgendwelche anderen Funktionen einer Soundkarte, beispielsweise einen früher nicht so unüblichen wavetable-Synthesizer einer Soundkarte nutzen will. Das ist zwar sehr konstruiert, aber trotzdem würde man in diesem Fall eher ctl.X-Abschnitte in die .asoundrc schreiben und könnte pcm.X optional der Vollständigkeit halber hinzufügen.


Oft oder sogar meistens genügt es die Defaultwerte der vielen bereits systemweit konfigurierten pcm-Dinger anzupassen. Dazu genügen in der asound.conf/.asoundrc wenige Zeilen Zeilen, wie zB:

Code: Alles auswählen

defaults.pcm.!card 1
defaults.pcm.!device 0
defaults.ctl.!card 1

[fischig]

Danke für die ausführliche Info!

Ja, das Umformulieren des Satz kurz vor dem Absenden des Beitrags ist daneben gegangen.

Nicht der Rede wert, passiert wohl den meisten, dem einen häufig, dem anderen weniger häufig. Wo ich mich da einordne, sag' ich lieber nicht!

Das pcm dagegen gibt an, das im folgenden ein Ding definiert wird, das Audiodaten entweder entgegennehmen und/oder abgeben kann.

Finde ich gut! und glaube wieder was ansatzweise verstanden zu haben.

Kommen wir aus den Höhen der Theorie wieder auf den konkreten Sachverhalt zurück:
Mit aplay _L entdecke ich jetzt auch meine beiden Elemente in der assoundrc (ich lass' das "~./") im folgenden weg, das kann sich mittlerweile wohl jeder selber dazudenken.

Code: Alles auswählen

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

Mal sehen, wie weit mein Verständnis reicht:

Code: Alles auswählen

pcm.GO2_SOFTVOL {

1. Es wird ein für Ton-Ein- und/oder -ausgabe bestimmtes „Ding1“ mit Namen „GO2_SOFTVOL“ eingerichtet und alles, was jetzt folgt, bezieht sich solange auf dieses Ding, bis eine schließende Schweifklammer: "}" erscheint?

Code: Alles auswählen

type softvol

2. Das „Ding1“ ist eins aus der Gattung alsa-plugin und dieses plugin (softvol) beschäftigt sich mit Lautstärke (vol --> volume --> Lautstärke)?

Code: Alles auswählen

slave.pcm "GO2"

3. Ding1 gehört irgendwie zusammen („slave“) mit einem anderen Ding2 namens GO2?

Code: Alles auswählen

control.name "GO2"

4. Da es um Lautstärke geht, soll ein Regler („control“) eingerichtet werden, der ebenfalls den Namen GO2 tragen soll?

Code: Alles auswählen

control.card Intel

5.Der Regler wird der Soundkarte mit dem Namen „Intel“ (diesen erfährt man via aplay -l) zugeordnet? (Wenn ich recht sehe, dann empfiehlst du im Wiki, den Namen der Soundkarte statt seiner Nummer zu verwenden.

Code: Alles auswählen

}

6. o.a. schließende Klammer

Code: Alles auswählen

pcm.GO2

7. Einrichtung von Ding2 mit Namen GO2, auf das bei der Einrichtung von Ding1 in der dritten Zeile Bezug genommen wurde?

Code: Alles auswählen

type bluealsa

8.Ding2 ist wieder eins aus der Gattung alsa-plugins, aber das plugin bluealsa beschäftigt sich mit Bluetooth-Ton„geräten“?

Code: Alles auswählen

interface "hci0"

9. Für Ding2 ist eine Bluetooth-Schnittstelle/-Gerätedatei mit Namen hci0 (erfahrbar via rfkill list oder in den Untiefen von/sys/devices/...) eingerichtet?

Code: Alles auswählen

device "30:C0:1B:72:63:8E"

10. Angabe der MAC-Adresse des realen BT-Gerätes, vermutlich zusätzlich zu „hci0“ benötigt für Autorisierungszwecke?

Code: Alles auswählen

profile "a2dp"

11. Beschreibt das Verfahren zur Behandlung der durch Ding1 und Ding2 laufenden Daten?

Kurzfassung: Diese asoundrc beschreibt die Konfiguration eines Bluetooth-Lautsprechers (Ding2) nebst zugehöriger softwaregeseuerter Lautstärkeregelung (Ding1) für Alsa?

Wenn das soweit stimmt, neue Frage: Könnte man die beiden Abschnitte vertauschen? Erschiene mir leichter fasslich?

[smutbert]

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

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

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

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

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

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



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

Code: Alles auswählen

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

pcm.GO2.type			bluealsa		# für Bluetooth zuständiges Alsa-Plugin
pcm.GO2.type.interface		"hci0"			# Name des Bluetooth-Adapters
pcm.GO2.type.device		"30:C0:1B:72:63:8E"	# MAC-Adresse des Bluetoothgeräts (via bluetoothctl)
pcm.GO2.type.profile		"a2dp"			# Bluetooth-Profil

[fischig]

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

Sollte er das nicht schon durch „hci0“ wissen?

[smutbert]

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

[fischig]

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

[fischig]

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

[fischig]

So, fasse ich mal zusammen:

rfkill:

Code: Alles auswählen

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

.asoundrc:

Code: Alles auswählen

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

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

bluetoothctl:

Code: Alles auswählen

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

aplay:

Code: Alles auswählen

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

ebenso:

Code: Alles auswählen

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

Un' nu?

[smutbert]

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


Ansonsten fällt mir nur ein mit dem Pairing von vorne anzufangen, vielleicht hilft das

• Während der Bluetoothlautsprecher außer Reichweite oder ausgeschaltet ist, am Computer das Verzeichnis »/var/lib/bluetooth/00:1A:7D:DA:71:13/30:C0:1B:72:63:8E« oder wenn du Bluetooth nur für den Lautsprecher nutzt, dann gleich das komplette „/var/lib/bluetooth/00:1A:7D:DA:71:13“ löschen und den Computer herunterfahren
• Falls möglich den Bluetoothlautsprecher auf die Werkseinstellungen zurücksetzen und Ausschalten
• Dann neu Pairen und Verbinden (falls letzteres nicht automatisch passiert).

An der Konfiguraton von Alsa (~/.asoundrc) oder mplayer solltest du jedenfalls natürlich nichts ändern müssen.

[fischig]

Hast du versucht den bluealsa-Dämon mit der Option --disable-hfp zu starten

Hab' ich. Ich versuch's nochmal, man weiß ja nie, insbesondere bei mir!
Übrigens, es gibt da im Rasperry-Netz-Umfeld noch andere Optionen für bluealsa, mit denen da rumjongliert wird. Links habe ich leider nicht notiert.

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

[smutbert]

Etwas ist mir noch eingefallen:
bluealsa, also der Dämon gibt Meldungen aus. Wenn den also einmal in einem Terminalfenster starten könntest oder wahlweise die Ausgaben in einer Logdatei umleitest, dann sehen wir ob sich PC und Lautsprecher mit A2DP verbinden oder nicht und/oder möglicherweise auch andere Hinweise auf die Fehlerursache.

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

Dazu hätte ich etwas geschrieben, sobald du den Lautsprecher auf dem ersten PC wieder zum laufen bekommen hast. Im Prinzip ist es zweifelsohne vorgesehen, aber nicht alles was vorgesehen ist funktioniert auch. ☺

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

[fischig]

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

Hier die Meldung:

Code: Alles auswählen

# /usr/bin/bluealsa: Couldn't initialize controller thread: Bad file descriptor

Es gibt dazu ein paar (nicht besonders taufrische) Threads im Netz, z.B :
https://github.com/Arkq/bluez-alsa/issues/126

Code: Alles auswählen

https://github.com/Arkq/bluez-alsa/issues/149

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

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