Audio-Abspielgerät funktioniert nicht

Linux Clients
#1

Hallo,

unter UCS 2.4, UCD 3.1 mit der Komponente ucd-kde4pim installiert bekommen wir ständig die Systemmeldung “Das Audio-Abspielgerät HDA Intel PCH funktioniert nicht”.

Mittels alsaconf jedoch scheint das Gerät erkannt zu werden und alsamixer ermöglicht die Regelung der Lautstärke. Jedoch kann das Gerät in KDE nicht verwendet werden.

Die in diversen Quellen zu findende Empfehlung das Xine-Backend für Phonon zu installieren bewirkt nichts, da es schon installiert ist. Andere Backends scheinen in den Univention-Paketquellen nicht verfügbar zu sein.

Ist dieses Problem bekannt bzw. gibt es dazu eine Lösung?

Grüße
bwsn

#2

Hallo,

könnten Sie uns bitte die Ausgabe folgender Befehle auf der Konsole als Anhang schicken?

aplay -l cat /proc/asound/cards head -n 1 /proc/asound/card0/codec* dpkg -l pulseaudio

Darüberhinaus würde ich Sie bitten einmal zu schauen, welche Geräte, in welcher Reihenfolge aufgeführt sind, wenn Sie über die Systemeinstellungen unter dem Punkt “Multimedia” zu Gerätepriorität -> Audio-Ausgabe wechseln.

Mit freundlichen Grüßen,
Tim Petersen

#3

Hallo,

die Kommandos wurden ausgeführt und die Ausgaben befinden sich im Anhang.

Die Reihenfolge der Audiogeräte:

HDA Intel PCH (HDA Generic)
Jack Audio Connection Kit

Grüße
bwsn
univention-audio.txt (953 Bytes)

#4

Hallo,

könnten Sie uns bitte ein System-Info Archiv von einem betroffenen System zukommen lassen, um das Modell und die Hardware näher prüfen zu können?
Hierzu können Sie auf dem System über die Univention-Management-Console den Punkt “Systeminformationen” verwenden.

Außerdem wäre noch die Datei “/etc/modprobe.d/alsa-base.conf” interessant, um eventuell fehlerhaft geladene Audiomodule ausschließen zu können.

Mit freundlichen Grüßen,
Tim Petersen

#5

Hallo,

anbei die gewünschten Informationen. Leider hatten wir auf die Hardwareentscheidung keinen Einfluss.

Grüße
bwsn
alsa-base.txt (22.3 KB)
44454C4C-3500-1046-8034-B1C04F4D5131.tar.gz (10.7 KB)

#6

Hallo,

eine kurze Internet Recherche hat ergeben, dass Probleme mit der von Ihnen eingesetzten Audio-Hardware und ALSA bekannt sind. Es wäre dahingehend möglich, dass lediglich der Audioausgang, welcher zur Wiedergabe auf den internen Lautsprechern eingesetzt wird, betroffen ist. Sie könnten hier einmal prüfen, ob der Kopfhörerausgang verwendbar ist.

Es scheint allgemein so zu sein, dass die Probleme mit dem eingesetzten Audio-Chip in ALSA 1.0.24 behoben sind.Leider kann hier keine Aussage getroffen werden, wann diese Version in einem kommenden UCD-Release Verwendung finden wird - gern habe ich aber einen Eintrag in unserem Bugtracking System erstellt: [bug]24932[/bug]

Mit freundlichen Grüßen,
Tim Petersen

#7

Hallo,

leider waren wir ein paar Tage beschäftigt, aber hier der neue Stand der Dinge. Wir konnten mittels aplay nachvollziehen, dass wirklich nur der Kopfhörerausgang funktioniert. Allerdings im KDE nur die Meldung “Audio-Abspielgerät funktioniert nicht”. Auch der Test unter den Multimedia-Einstellungen schlägt mit dieser Meldung fehl.

Wir haben dann die aktuellen ALSA-Quellen (1.0.24) genommen und kompiliert. Das klappte reibungslos. Nach Reboot lieferte ein Test mit aplay auch die Ausgabe über die integrierten Lautsprecher. Leider unter KDE weiter das Problem “Audio-Abspielgerät funktioniert nicht”.

Haben Sie noch eine Ansatz?

Grüße und ein schönes Wochenende

bwsn

#8

Hallo,

ich möchte nochmal zur Info und Klärung meines vorherigen Beitrags ein paar Zeilen schreiben. Der Sound war nun über die integrierten Lautsprecher hörbar. Allerdings nur mit dem Tool aplay. Unter KDE erhielten wir weiter die oben genannte Meldung.

Ein kurzer Test mit Amarok ergab die Meldung “xine konnte keine Audio-Treiber initialisieren”. Dies nur zur Info, da wir auch schon telefonisch mit einem Kollegen weitere Optionen besprochen haben.

Grüße

bwsn

#9

Hallo nochmal,

auf einen Tip per Telefon hin haben wir einen Benutzer in die lokale Gruppe “audio” aufgenommen. Nun funktioniert auch der Sound unter KDE. Mittlerweile haben wir auch folgenden Artikel gefunden:

http://wiki.univention.de/index.php?title=Berechtigungsverwaltung_%C3%BCber_lokale_Gruppen

Wir konnten die Zuordnung zur Gruppe nur per direktem Editieren der Datei /etc/group erreichen. Das Kommando usermod funktionierte nicht, da der Benutzer nicht in der lokalen Nutzerdatenbank gefunden wurde.

Wie können wir am geschicktesten die Gruppenzuordnungen realisieren?

Grüße

bwsn

#10

Hm der bessere Befehl wäre wohl schon mal adduser $user $group. Allerdings wäre es jetzt noch interessant wie die entsprechende LDAP-Abfrage aussehen müßte.

#11

Hallo,

für die Umsetzung des von Ihnen gewünschten Verhaltens finden Sie zwei dynamische Möglichkeiten innerhalb des von Ihnen erwähnten Wiki-Artikels .

@SirTux:
Welche LDAP-Abfrage meinen Sie an dieser Stelle?

Mit freundlichen Grüßen,
Tim Petersen

#12

Hm die Abfrage welche User in der Gruppe “Domain Users” sind.

Und gibt es dieses Addon eigentlich auch noch in UCS 3.0?

#13

Ja, das habe ich auch schon gelesen. Vielleicht wäre ein Beispiel für ein solches Skript hilfreich. Also wie eben die Domain Users abgefragt werden und die lokalen Gruppenzugehörigkeit entsprechend gesetzt werden. Ich denke, das ist es auch was SirTux meint.

Grüße

#14

Hallo,

eine mögliche LDAP-Abfrage wäre zum Beispiel:

ldapsearch -xLLL cn="Domain Users" memberUid

Ein Hinzufügen der Benutzer in lokale Gruppen kann dann beispielsweise mit dem Befel useradd erfolgen:

"adduser $user $group"

Ein entsprechendes Beispiel wurde am bereits erwähnten Wiki-Artikel ergänzt.

In UCS 3.0 ist das Paket “univention-ldap-localgroups” aktuell nicht enthalten.
Beachten Sie hierbei aber bitte auch folgenden Auszug aus dem Wiki-Artikel:

[quote][…] Das Paket ist für UCS 1.3 entstanden und setzt einige ältere Konventionen voraus, da es derzeit nicht unter Maintenance steht wurden diese Änderungen nicht nachgepflegt. Auf Systemen die mit UCS 2.x installiert wurden sind daher folgende Anpassungen notwendig: […]
[/quote]

Mit freundlichen Grüßen,
Tim Petersen

#15

Danke, das ist doch schon viel besser so. Noch besser wäre es IMO, wenn diese Funktion standardmäßig vorhanden wäre, da diese doch sehr wichtig ist sofern UCS auch als Desktop eingesetzt wird.

EDIT: Der Befehl useradd user group scheint nicht zu funktionieren. Er gibt nur seinen Hilfetext aus

#16

Ich hab mir mal angeguckt wie es das Listener-Script macht: gpasswd -a user group geht

#17

[quote=“SirTux”]
EDIT: Der Befehl useradd user group scheint nicht zu funktionieren. Er gibt nur seinen Hilfetext aus[/quote]

Gemeint war natürlich der Befehl “adduser” - Ich habe dies entsprechend korrigiert.

Mit freundlichen Grüßen,
Tim Petersen

#18

Stimmt so gehts. Das hätte mir eigentlich auch selber auffallen müssen

#19

Hallo,

danke für das Beispiel.

Um aber auch ehrlich zu sein, haben wir den Ansatz nicht ganz verstanden. Technisch gesehen schon, aber nicht warum dies nicht grundsätzlich funktioniert oder per UDM konfigurierbar ist.

Wir hatten ja ursprünglich auch Probleme mit den Treibern, aber selbst ohne diese hätte es ja nicht funktionieren können. Es ist jetzt zwingend nötig, dass ein Administrator ein Skript schreibt oder unmaintained Pakete verwendet werden um grundlegende Funktionen zu nutzen.

Vielleicht habe wir nun auch etwas übersehen, missverstanden oder es gibt Gründe die sich uns nicht erschließen, aber diesen Ansatz sollten Sie überdenken.

Grüße

#20

Hallo,

eine komfortablere Umsetzung dieses Szenarios ist bereits für UCD 3.2 vorgesehen - sehen Sie hierzu auch gern die Roadmap für den Zeitrahmen künftiger Veröffentlichungen .

Die notwendigen Berechtigungen werden hierbei vermutlich über pam_group realisiert werden.

Mit freundlichen Grüßen,
Tim Petersen