Wiki-Artikel zu ALSA? Gedankensammelthread!

Diskussion rund um unser Wiki.
outis
Beiträge: 395
Registriert: 07.10.2005 12:28:01

Re: Wiki-Artikel zu ALSA? Gedankensammelthread!

Beitrag von outis » 01.08.2016 11:14:13

Magst du noch was zum unsäglichen (und für mich undurchschaubaren) Thema bluetooth-Audio mit/ohne pulseaudio schreiben?
LG

Jochen

Benutzeravatar
smutbert
Moderator
Beiträge: 8311
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Wiki-Artikel zu ALSA? Gedankensammelthread!

Beitrag von smutbert » 01.08.2016 14:39:09

Ohne Pulseaudio gehts ja nicht mehr seit jessie, weil es gar keine ALSA-Bluetoothtreiber mehr gibt. Ich hab gelegentlich versucht ibei dem Thema im Raspberry Pi-Forum zu helfen, habe dann aber oft nicht weiter gewusst - solange ich also selbst kein Bluetooth-Audiogerät mein eigen nenne, kommt da aus meiner Richtung eher nichts.

Ein, zwei andere Kleinigkeiten kommen aber vielleicht noch - beim vorläufig letzten Pulseaudio-Kapitel kämpfe ich momentan noch mit der Formatierung/Darstellung.

guennid

Re: Wiki-Artikel zu ALSA? Gedankensammelthread!

Beitrag von guennid » 01.08.2016 17:27:43

smutbert hat geschrieben:wohin lädt man die - in die Bildergalerie des Forums
Da bist du nicht der Einzige, der dieses "Versteckspielchen" ziemlich bescheuert findet. Liegt aber wohl an der Forensoftware, nicht deren Anwendern. :wink:

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Wiki-Artikel zu ALSA? Gedankensammelthread!

Beitrag von scientific » 04.09.2016 22:44:32

Hi smutbert!

Ganz großes Kino, dein Artikel!!! :THX:

Ich würde auch gerne etwas beisteuern... :)
Wie du ja weißt, hab ich ziemlich lange herumgedoktert, wie ich einen systemweiten mpd mit User-Instanzen von Pulseaudio zum Laufen kriege. Und das läuft hier jetzt ziemlich gut - auch ohne Netzwerkverbindung.

Solange da kein Bluetooth mit im Spiel ist, würd ich sagen, ist das eine gut gewordene Config geworden, die es auch wert ist, im Wiki aufgenommen zu werden.

Das Setting:
mpd läuft als user mpd und hat nur einen Output - nämlich einen Pulse-Output.

Code: Alles auswählen

audio_output {
	type		"pulse"
	name		"local stream"
#	server		"remote_server"		# optional
#	sink		"remote_server_sink"	# optional
#	server		"localhost"
	sink		"rtp_localhost"
	audio_output_format	"44100:16:2"
	mixer_type	"software"

}
mpd bekommt in seinem $HOME eine eigene default.pa, welche lediglich eine minimale Konfiguration mit einem RTP-Sender enthält:

Code: Alles auswählen

# cat /var/lib/mpd/.config/pulse/default.pa 
#! /usr/bin/pulseaudio -nF

load-module module-native-protocol-unix
load-module module-suspend-on-idle timeout=1

load-module module-null-sink sink_name=rtp_localhost
load-module module-rtp-send source=rtp_localhost.monitor rate=48000 channels=2 format=s16be port=46102 loop=1 source_ip=127.0.0.1 destination_ip=224.0.0.56
set-default-sink rtp_localhost

load-module module-zeroconf-publish
Für alle anderen User ist die /etc/pulse/default.pa zuständig:

Code: Alles auswählen

# cat /etc/pulse/default.pa 
#!/usr/bin/pulseaudio -nF
#
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see <http://www.gnu.org/licenses/>.

# This startup script is used only if PulseAudio is started per-user
# (i.e. not in system mode)

.fail

### Automatically restore the volume of streams and devices
load-module module-device-restore
load-module module-stream-restore
load-module module-card-restore

### Automatically augment property information from .desktop files
### stored in /usr/share/application
load-module module-augment-properties

### Should be after module-*-restore but before module-*-detect
load-module module-switch-on-port-available
#load-module module-switch-on-connect

### Load audio drivers statically
### (it's probably better to not load these drivers manually, but instead
### use module-udev-detect -- see below -- for doing this automatically)
#load-module module-alsa-sink
#load-module module-alsa-source device=hw:1,0
#load-module module-oss device="/dev/dsp" sink_name=output source_name=input
#load-module module-oss-mmap device="/dev/dsp" sink_name=output source_name=input
#load-module module-null-sink
#load-module module-pipe-sink

### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
load-module module-udev-detect tsched=0
.else
### Use the static hardware detection module (for systems that lack udev support)
load-module module-detect
.endif

### Automatically connect sink and source if JACK server is present
.ifexists module-jackdbus-detect.so
.nofail
load-module module-jackdbus-detect channels=2
.fail
.endif

### Automatically load driver modules for Bluetooth hardware
.ifexists module-bluetooth-policy.so
load-module module-bluetooth-policy
.endif

.ifexists module-bluetooth-discover.so
load-module module-bluetooth-discover
.endif

# automatically switch to newly-connected devices
.ifexists module-switch-on-connect.so
load-module module-switch-on-connect
.endif

#.ifexists module-bluez5-device.so
#load-module module-bluez5-device
#.endif
#
#.ifexists module-bluez5-discover.so
#load-module module-bluez5-discover
#.endif

### Load several protocols
.ifexists module-esound-protocol-unix.so
load-module module-esound-protocol-unix
.endif
load-module module-native-protocol-unix

### Network access (may be configured with paprefs, so leave this commented
### here if you plan to use paprefs)
#load-module module-esound-protocol-tcp
#load-module module-native-protocol-tcp
load-module module-zeroconf-publish

.ifexists module-combine-sink.so
.fail
load-module module-combine-sink sink_name=combined_sys sink_properties="device.description='System-combined-sink'"
.nofail
.endif


### Load the RTP receiver module (also configured via paprefs, see above)
#load-module module-rtp-recv sap_address=224.0.0.56 sink=combined_sys
load-module module-rtp-recv sink=combined_sys

### Load the RTP sender module (also configured via paprefs, see above)
#load-module module-null-sink sink_name=rtp format=s16be channels=2 rate=44100 sink_properties="device.description='RTP Multicast Sink'"
#load-module module-rtp-send source=rtp.monitor

### Load additional modules from GConf settings. This can be configured with the paprefs tool.
### Please keep in mind that the modules configured by paprefs might conflict with manually
### loaded modules.
.ifexists module-gconf.so
.nofail
load-module module-gconf
.fail
.endif

### Automatically restore the default sink/source when changed by the user
### during runtime
### NOTE: This should be loaded as early as possible so that subsequent modules
### that look up the default sink/source get the right value
load-module module-default-device-restore

### Automatically move streams to the default sink if the sink they are
### connected to dies, similar for sources
load-module module-rescue-streams

### Make sure we always have a sink around, even if it is a null sink.
load-module module-always-sink

### Honour intended role device property
load-module module-intended-roles

### Automatically suspend sinks/sources that become idle for too long
load-module module-suspend-on-idle

### If autoexit on idle is enabled we want to make sure we only quit
### when no local session needs us anymore.
.ifexists module-console-kit.so
load-module module-console-kit
.endif
.ifexists module-systemd-login.so
load-module module-systemd-login
.endif

### Enable positioned event sounds
load-module module-position-event-sounds

### Cork music/video streams when a phone stream is active
load-module module-role-cork

### Modules to allow autoloading of filters (such as echo cancellation)
### on demand. module-filter-heuristics tries to determine what filters
### make sense, and module-filter-apply does the heavy-lifting of
### loading modules and rerouting streams.
load-module module-filter-heuristics
load-module module-filter-apply

### Make some devices default
#set-default-sink output
#set-default-source input

.fail
set-default-sink combined_sys
.nofail
Und damit das Interface lo auch für das rechnerinterne Multicast genutzt werden kann, benötige ich noch eine systemd-unit, welche beim Booten lo auf multicast switcht und eine entsprechende Route setzt:

Code: Alles auswählen

# cat /etc/systemd/system/network-multicast-lo.service 
[Unit]
Description=Configure loopback-interface for multicast (mpd-RTP-stream)

[Service]
Type=oneshot
ExecStart=/sbin/ifconfig lo multicast
ExecStart=/sbin/route add -net 224.0.0.0 netmask 240.0.0.0 dev lo
#ExecStart=/sbin/route add 224.0.0.56 netmask 255.255.255.0 dev lo

[Install]
WantedBy=basic.target
Bekannte Probleme bei diesem Setup:
Pulseaudio verursacht offenbar über das RTP-Modul (Send? Receive?) einen "Queue overrun". Ein "sudo killall pulseaudio" und manchmal ein "sudo systemctl restart mpd.service" behebt dies für eine Weile. Eine dauerhafte Lösung konnte ich bislang noch nicht finden.

Ein weiteres Problem ergibt sich bei der Verwendung von Bluetooth-Geräten. Egal ob Handy, Tastatur oder Lautsprecher. Die erste gestartete pulseaudio-Instanz krallt sich das Bluetooth-Device und gibt es nicht mehr frei. Das ist meistens entweder der pa-Server von mpd oder Debian-gdm.
Es funktioniert dann weder das Erkennen noch das Pairing geschweige denn die Wiedergabe von Musik über den Bluetooth-Lautsprecher.

In anderen Foren wird bei diesem Problem die vollkommene Deaktivierung von Pulseaudio für Debian-gdm als Workaround empfohlen. Dieser Workaround hilft aber bei diesem Setup nichts, da ja genau dieser zweite pa-Server von mpd bzw. die Sesseion von pa in GDM erwünscht ist, damit auch ohne Login die Musik wiedergegeben werden kann - in dem Fall wird mpd per Handy-App oder ähnlichem ferngesteuert.

Ich würde mich sehr freuen, wenn du noch einmal über meine default.pa drüberschaust, oder gar dieses Setup auch einmal ausprobierst - und wenn es dir gefällt, dass du es auch in das Wiki aufnimmst. Ich würd dich auch mit Rat und Tat dabei unterstützen.

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Benutzeravatar
smutbert
Moderator
Beiträge: 8311
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Wiki-Artikel zu ALSA? Gedankensammelthread!

Beitrag von smutbert » 06.09.2016 20:07:25

Danke!
Ja, den Aufwand, den du betrieben hast um zu dieser Konfiguration zu kommen, habe ich mitbekommen und ich werde deine Konfiguration noch ausprobieren.


Ich wäre allerdings glaub ich fast eher dafür das ganze in einen eigenen Wiki-Artikel zu packen - der Artikel, den ich begonnen habe und für den ich eigentlich noch ein oder zwei Abschnitte, zB ein kurzes Kapitel über jack geplant habe, ist jetzt schon auf Platz 8 der längsten Artikel und es sollte ein kurzer Artikel werden, der eine Übersicht der linuxschen Audiosysteme bietet...

Den Artikel, den du schon geschrieben hast Wiki-Artikel zum Thema MPD als Systemdienst mit ALSA und Pulseaudio wollte ich sowieso auch noch verlinken und auch Beispiele für das echo-Cancelling oder das automatische stumm/leiser schalten (klick) wollte ich vielleicht noch schreiben - immerhin denke ich habe ich in diesem oder jenem Forum das meiste eh schon gepostet - sollte also eigentlich nicht allzu schwierig sein.

Bei deiner Lösung versteh ich ehrlich gesagt (noch?) nicht, wieso du Pulseaudio nicht als systemweiten Dienst laufen lässt - vielleicht hab ich den Grund auch nur vergessen. Jedenfalls gäbe es dann hoffentlich keine Probleme beim Umschalten zwischen dem PA von gdm und dem eines Nutzers und vielleicht würde das auch das Problem mit Bluetooth lösen?
Ich war was dein Problem und die passende Lösung angeht faul, weil mein mpd direkt über Alsa auf die Soundkarte zugreift und unmusikalische Töne auf dieser Soundkarte ohnehin nichts verloren haben.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Wiki-Artikel zu ALSA? Gedankensammelthread!

Beitrag von scientific » 14.09.2016 17:41:20

Nun... Ich hab auch schon an einen eigenen Artikel gedacht, da bin ich über deinen gestolpert...

Warum ich keinen System-pa laufen lasse?
Ich möchte möglichst nah an der originalen Konfig bleiben.

Zugegeben... lo auf Multicast schalten, für mpd eine eigene default.pa speichern und /etc/pulse/default.pa anpassen ist auch nicht wenig...

Beim Bluetooth-Problem bin ich nicht der einzige. Das haben offenbar einige, die pa in der Originalkonfig laufen lassen. Dann krallt sich der gdm das bluetooth-device und lässt es nicht mehr los.
Das muss also sowieso gelöst werden...
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Wiki-Artikel zu ALSA? Gedankensammelthread!

Beitrag von scientific » 14.09.2016 17:42:59

Wenn jemand 2 bt-soundkarten hat, hakt es übrigens auch mit pa...
Ich verfolge die Mailingliste ein wenig...
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Benutzeravatar
smutbert
Moderator
Beiträge: 8311
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Wiki-Artikel zu ALSA? Gedankensammelthread!

Beitrag von smutbert » 19.09.2016 22:00:48

scientific hat geschrieben:[…]
Zugegeben... lo auf Multicast schalten, für mpd eine eigene default.pa speichern und /etc/pulse/default.pa anpassen ist auch nicht wenig...
[…]
Hihi, genau darauf wollte ich hinaus. Ein schnell eingerichteter systemweiter pulseaudio sollte die Probleme verschwinden lassen (glaube ich) - vor allem dass mit der unterschiedlichen Pufferung.


Aber egal, denn deine Konfiguration ist es auf jeden Fall wert dokumentiert zu werden.
Eigentlich denke ich, dass wir am besten einen allgemeinen Artikel über mpd+Pulseaudio schreiben - schließlich gibt es bei der Kombination des typischerweise systemweit laufenden mpd und dem normalerweise benutzerspezifischen pulseaudio, ja sogar Hindernisse, wenn man keinen Wert darauf legt, bereits im unangemeldeten Zustand Musik hören zu können, wie man zB hier sieht: viewtopic.php?f=25&t=162310
Ganz grob hätte ich mir zumindest diese Kapitel vorgestellt:
- mpd als benutzerspezifischer Dienst
- pulseaudio als systemweiter Dienst
- mpd mit Netzwerkzugriff auf Pulseaudio (des Benutzers)
- deine Konfiguration

Antworten