Posts by smutbert

Es war nicht als besonders elegante oder dauerhafte Lösung gedacht, aber eine Pythondatei mit Pfad zu importieren geht nicht und selbst wenn es funktionierte, würde das Programm dabei ja noch nicht zwangsweise ausgeführt.

Gibt es denn etwas anderes, was man als das linuxsche Äquivalent zu Datei→Öffnen in der grafischen Pythonkonsole unter Windows bezeichnen könnte?

Der Unterschied ist, dass du unter Linux ein normales Terminalfenster hast, die grafischen Sachen wie die Menüleiste sind also nur für die Funktionen des Terminalemulators da und nicht für das Programm das darin läuft (in dem Fall python), während unter Windows python offensichtlich als grafisches Programm läuft.

Um ein Programm mit python auszuführen kenne ich zwei Möglichkeiten:

• das Starten des Programms von einer Shell (wieder aus dem Terminal) python2 pfad/zu/meinem/programm.py
• oder aus python2 mit dem Befehl execfile("pfad/zu/meinem/programm.py") oder in python3 mit exec(open("pfad/zu/meinem/programm.py").read())

apt wurde vor allem eingeführt um Alltagsaufgaben mit einem einheitlichen und übersichtlichen Kommando durchführen zu können (statt apt-get, apt-cache,...) und macht bei den gleichen Befehlen dasselbe wie apt-get.

Mit den Informationen, die du gepostet hast, lässt sich nur mutmaßen, dass der ersten Versuch die Paketlisten mit apt-get upzudaten fehlgeschlagen ist, vielleicht wegen (vorübergehenden) Problemen mit der Netzwerkverbindung oder weil in den Repositories gerade gearbeitet wurde und das gewünschte Paket in den Paketlisten beim folgenden apt-get install … gefehlt hat oder der Eintrag nicht (mehr) gestimmt hat.

(Auf jeden Fall halte ich die Probleme für einen unglücklichen Zufall.)

Man kann apt und apt-get auch beliebig kombinieren oder je nach Lust und Laune abwechselnd nutzen. So etwas wie

# apt-get update && apt install eject

oder

# apt update && apt-get upgrade

soll und darf überhaupt kein Problem sein.

aptitude ist ein bisschen etwas anderes, weil es soweit ich weiß seine eigenen von apt abweichenden Methoden hat Abhängigkeiten aufzulösen, aber solange man keine außergewöhnlichen Dinge mit der Paketverwaltung stellt, spielt das auch keine große Rolle und man kann dann auch aptitude weitgehend problemlos mit apt/apt-get kombinieren.

100% bedeuten oft ein Rechenkern ist voll ausgelastet ­→ werden 2 Kerne ausgelastet, kommt es zu 200%, bei 3 300%, u. s. w.

Davon habe ich nicht die geringste Ahnung. Viel mehr als, dass ich weiß, dass es das gibt, weiß ich über java nicht und auch vom Schreiben von Pulseaudio-Clients habe ich keinen Dunst.

Also bei meinem letzten Beispiel kannst du auch direkt in mp3 aufnehmen – ich habe nur wav verwendet, weil mir das Paket für die Unterstützung des mp3-Formats von sox fehlt. Hier also noch einmal ohne, dass eine asound.conf notwendig wäre und mit dem Befehl alsaloop, der arecord | aplay ersetzt:

$ alsaloop -C plug:dsnoop:1 -P plughw:1
$ AUDIODEV=dsnoop:1 rec -b 16 -r 48000 -c 2 -q recording.mp3

Alternativ kannst du natürlich auch so etwas machen (ich habe aber nicht ausprobiert wie gut es funktioniert - ich könnte mir vorstellen, dass es da wieder zu kleineren Knacksern kommt)

$ export AUDIODEV=plughw:1
$ rec -c 1 -q -t mp3 /dev/stdout | tee aufnahme.mp3 | play -q -t mp3 /dev/stdin

Aber auch mit deiner asound.conf habe ich das Problem nicht nachstellen können – auf meinem Raspberry Pi 3 läuft es mit einer USB-Soundkarte problemlos. Ich habe nur ein paar Kleinigkeiten anzumerken

• Kanalzahl
  in "dsnooped" legst du die Kanalzahl mit 2 fest, aber in arecord und sox nimmst du mit einem Kanal auf. Zumindest bei arecord brauchst du dann ein "plug", das die Zahl der Kanäle umrechnet. Du kannst das plug in die asound.conf einbauen oder einfach statt "dsnooped" als Aufnahmegerät "plug:dsnooped" angeben.
• Wiedergabegerät
  Ich habe es schon geschrieben, aber dsnooped eignet sich nur zur Aufnahme und nicht zur Wiedergabe. Du musst bei aplay ein geeignetes Wiedergabegerät angeben und höchstwahrscheinlich auch mit plug dafür sorgen, dass in ein mit Treiber/Soundkarte kompatibles Audioformat umgerechnet wird, zum Beispiel aplay -D plughw:1, wenn die Wiedergabe über die USB-Soundkarte laufen soll.
• Ich nehme an es ist nur ein Copy+Paste Fehler, aber bei deiner asound.conf fehlt eine schließende geschweifte Klammer } und die Zeilenumbrüche sehen so aus als wären sie durcheinander gekommen:

pcm.dsnooped {
    type dsnoop
    ipc_key 234884
    slave {
        pcm "hw:1"
        channels 2
    }
}

Die Konfiguration mittels defaults.ctl.card und defaults.pcm.card schlage ich normalerweise auch als erstes vor, wenn es darum geht die default-Soundkarte festzulegen, aber hier hat mcbo im Eingangspost bereits explizit die Soundkarte angegeben und soweit ich das sehe alles richtig gemacht.

Also entweder versteckt sich irgendwo ein ziemlich subtiler Fehler oder es liegt an seiner Art mit /dev/urandom zu testen.

(Diese Idee, dass es am Test liegen könnte ist mir erst beim Schreiben des letzten Beitrags gekommen, deshalb habe ich auch nach der Ausgabe seines aplay-Befehls mit den Zufalldaten gefragt – es könnte meiner Meinung nach nämlich durchaus sein, dass es zwar funktioniert er aber nur nichts hört weil beim Onboardsound Samplerate und -format so gewählt werden, dass die Zufallsdaten unhörbar sind.)

Dass das Löschen der /var/lib/alsa/asound.state unter Umständen unerklärliche Fehler beseitigen kann, kann ich nachvollziehen, aber an der systemweiten Standardkonfiguration, also /usr/share/alsa/alsa.conf und allem was sonst sonst noch unter /usr/share/alsa zu finden ist würde ich nichts ändern. Viel mehr würde ich diese Standardkonfiguration nutzen um auszuprobieren ob der Fehler nicht doch an der asound.conf liegt. dmix lässt sich mit der Standardkonfiguration auch so nutzen:

$ aplay -D plug:dmix:0 /usr/share/sounds/alsa/Front_Left.wav

Auch die Ausgabe des Befehls

$ cat /dev/urandom | aplay -D plug:dmixer

wäre interessant und zwar sowohl mit der Variante, in der die USB-Soundkarte in die asound.conf eingetragen ist, wie auch die Variante mit dem Onboardsound.

Das muss ich auf meinem RPi nachstellen, denn auf Anhieb sehe ich keinen Fehler bei deiner asound.conf und woanders kann der Fehler ja fast nicht liegen.

Welches Image/System läuft denn auf deinem RPi?

Du könntest einerseits tee verwenden, um die Ausgabe von arecord sowohl in eine Datei zu schreiben als auch an der Standardausgabe auszugeben. Dann sollte es komplett ohne dsnoop funktionieren, ungefähr so

arecord -D plughw:1 -f S16_LE -c 1 -r 192000 - | tee aufnahme.wav | aplay

und Pulseaudio wäre auch eine Möglichkeit, das bietet von Haus die Möglichkeit mit mehreren Programmen aufzunehmen und wiederzugeben und es gibt auch so etwas wie eine eigene virtuelle Soundkarte zum Mithören von Aufnahmen.

dsnoop sollte aber natürlich auch funktionieren. Ich habe es hier gerade ohne eigene asound.conf ausprobiert und hier hat es auf diese Art auf Anhieb geklappt (mit zu meiner Soundkarte passenden Optionen):

$ arecord -D dsnoop:1,0 -f S32_LE -c 2 -r 48000 | aplay
$ export AUDIODEV="dsnoop:1,0"
$ rec -b 32 -r 48000 -c 2 -q recording.wav

Was mir bei dir aufgefallen ist, ist dass du mit aplay auch an dsnooped wiedergibst, aber dsnoop ist ja ein Plugin, das nur der Aufnahme dient. Kommt mir falsch vor, aber es ist wahrscheinlich nicht die eigentliche Fehlerursacher, denn der Fehler kommt ja schon von arecord.

Was bei deiner asound.conf schief läuft, müsste ich mir erst noch ansehen, wenn du es so machen willst.

Eventuell könnte es schon interessant sein ob das nur passiert, wenn Pulseaudio sozusagen aus dem Standby geholt werden muss oder ob das auch passiert, wenn pulseaudio bereits normal läuft und mit der Wiedergabe von Stille beschäftigt ist.

Sonst erinnert mich der Fehler an ein Problem, das aber eigentlich schon seit langem gelöst sein sollte. Bei dem und ähnlichen Schwierigkeiten hat es oft geholfen in der »/etc/pulse/system.pa« bzw. »/etc/pulse/default.pa« (erstere für einen systemweiten Pulseaudiodaemon, zweitere für benutzerspezifische Pulseaudio-Instanzen) die Zeile

load-module module-udev-detect

in

load-module module-udev-detect tsched=0

zu ändern.

Stromversorgungsprobleme können sich auf fast jede erdenkliche Weise äußern.

Bei deiner Beschreibung würde ich aber einmal testen ob das drastische Hinaufsetzen von exit-idle-time in /etc/pulse/daemon.conf etwas ändert (Kommentarzeichen ; nicht übersehen) oder wahlweise ob die parallele Wiedergabe von Stille, um die Soundkarte beschäftigt zu halten, etwas ändert:

$ aplay /dev/zero

Dauerlösung ist das vielleicht zwar keine, weil es die Systemlast und/oder Stromverbrauch erhöht, aber zumindest lässt sich so das Problem vielleicht etwas eingrenzen.

Gibt es bei dir möglicherweise eine Datei »/etc/pulse/daemon.conf.dpkg-new« oder »/etc/pulse/daemon.conf.dpkg-dist« oder so?

funktioniert denn ein einfaches

$ aplay -D plughw:0,0 /usr/share/sounds/alsa/Front_Left.wav

und bist du sicher, dass es nicht an Stecker/Kabel scheitert?

Ob vielleicht ein Lautstärkeregler auf 0 steht oder stumm geschaltet (MM) ist, hast du schon überprüft

$ alsamixer -D hw:0

(zu anderen möglichen Fehlerquellen kann ich vielleicht am Abend mehr schreiben)

entschuldige, dass ich den Thread nur oberflächlich überflogen habe (und dass diese Tatsache so offensichtlich zutage tritt )

Jedenfalls audio-CDs mit mpd funktionieren und das ganz ohne Datenbank. Du musst nur nach dem einlegen der CD dafür sorgen, dass die Tracks der CD in der Wiedergabewarteschlange landen.

Dank der udev-Events sollte das mit einer eigenen udev-Regel funktionieren. Ich würde es in Anlehung an [1] so angehen

• Eine udev-Regel, die beim Einlegen/Auswerfen von beliebigen CDs/DVDs (anders habe ich es nicht zusammengebracht) ausgelöst wird, die etwa so aussieht SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_MEDIA_CD}=="1", RUN+="/usr/local/bin/meinskript"
• Das Skript (/usr/local/bin/meinskript) müsste dann zuerst prüfen ob es sich um eine Audio-CD handelt. Das kann zum Beispiel cd-info aus dem Paket libcdio-utils, ganz holzhammermäßig mit cd-info | grep "Disc mode is listed as: CD-DA"(exit-Status 0 bedeutet Audio-CD, keine Ausgabe und exit-Status ungleich 0 → irgendetwas anderes).
  Handelt es sich um eine Audio-CD lassen sich die Titel der CD leicht in die Wiedergabewarteschlange einreihen mpc add "cdda://"(eventuell wäre es auch eine gute Idee vorher die Warteschlange zu leeren)

[1] http://jctechnotes.blogspot.co…eadless-server-using.html

Also meine erste Idee wäre gewesen, den Auswurftaster des Laufwerks komplett lahmzulegen (eventuell auch einfach nur zu verdecken) und die CD per Software auswerfen zu lassen (zum Beispiel ausgelöst von einem eigenen Taster per gpio, der dann vorher auch Stopp betätigen kann).

Eigentlich meine ich aber, dass sich das Auswerfen nicht so auswirken dürfte, wie du es beschrieben hast. Vielleicht komme ich einmal dazu, das mit mpd auszuprobieren.

Selbst wenn du bei deinem Plan mit dem Relais bleibst, hätte ich zumindest bei mpd eine vage Idee wie du es ohne Anpassung von mpd erledigen kannst (ein zusätzliches Programm muss dann natürlich laufen, aber das muss es bei mpd und allen anderen Playern, die in Client/Frontend und Server/Backend aufgeteilt sind, sowieso).

Ich will dir nichts ausreden, aber wäre es da nicht ungleich einfacher einen Player zu nehmen, um den du nur eine GUI drumherum basteln musst. wenn es nicht sogar ohnehin schon eine passende gibt?

xmms2, mpd, vlc und bestimmt noch viele andere lassen sich jedenfalls einfach von anderen Anwendungen steuern und wenn es dein Wunschplayer nicht auch schon kann, dann lässt sich er sich höchstwahrscheinlich über dbus mittels mpris steuern.

(mich hat es jedenfalls erstaunt, dass ein mpd-Client, der den Status über LEDs und ein LCD anzeigt und auf Taster und Drehimpulsgeber reagiert in python recht einfach zu realisieren ist. Wenn ich mir dagegen das Quellcode-Archive von audacious ansehe...)

Es gibt schon noch einige Alternativen, aber alles unter einen Hut zu bringen wird schwierig. Mir persönlich gefällt mpd sehr gut, das bis auf d) wohl alles erfüllt und mit d) wird es wird es insofern schwierig, als bei den meisten Playern die Tracks einer CD nun einmal in einer Art Playlist (meist Wiedergabewarteschlange genannt) landen. Wobei einige der Punkte (a), b)) vom mpd-Client abhängen – dafür habe ich es als verhältnismäßig einfach empfunden mit python einen kleinen mpd-Client zu schreiben, der auf Taster und Drehimpulsgeber reagiert und ein paar LEDs und ein Display steuert.

Ich bin ja nicht ganz sicher wie du dir die Bedienung vorstellst, aber ich würde eine udev-Regel anlegen, die beim Einlegen einer CD ein Skript oder ähnliches aufruft, das herausfindet ob es sich um eine Audio-CD handelt (eventuell geht das mit der udev-Regel sogar direkt, aber auf Anhieb weiß ich nicht wie) und wenn ja, die Titel zur Wiedergabewarteschlange von mpd hinzufügt (und eventuell sogar gleich zum Spielen anfängt).

Sonst gehst du mit alsaplayer imho schon in die richtige Richtung von etwas einfachereren Programmen, auch wenn ich alsaplayer nicht so gut in Erinnerung in habe (ich habe gedacht, das gibt es schon lange nicht mehr )

Sonst fallen mir noch vlc, goobox und xmms2 (letzteres kenne ich aber nicht) ein.

~/.asound.conf wird meines Wissens von Alsa bzw. den Anwendungen ignoriert - zumindest kenne ich die Datei bis jetzt nicht. Es gibt ~/.asoundrc für die benutzerspezifische und /etc/asound.conf für die systemweite Konfiguration und Neustart sollte eigentlich keiner notwendig sein, außer für speziellere Sachen – es genügt in der Regel die betreffende Anwendung zu beenden und wieder zu starten.

Wenn ich mich einmal auf den ersten Auszug für den RaspiBlaster beschränken darf (die Soundkarte heißt beim zweiten, yamuplay, ohnehin gleich, daher sollte es dort genauso funktionieren):

Es sieht eigentlich alles richtig aus, bis auf das fehlende dmix, damit mehrere Anwendungen Audio wiedergeben können und das kannst du so einbauen (ich habe auch die Namen der definierten pcms etwas vereinfacht)

pcm.dmixer {
    type dmix
    ipc_key 1236
    slave.pcm "hw:sndrpihifiberry"
}

pcm.softvolume {
    type softvol
    slave.pcm "dmixer"
    control.name "Master"
    control.card sndrpihifiberry
}

pcm.!default {
    type       plug
    slave.pcm  "softvolume"
}

Wenn nun über das „Standardgerät“ wiedergegeben wird, durchlaufen die Audiodaten drei Alsa-Plugins

- plug (default) nimmt eventuell notwendige Konvertierungen vor (Samplerate, -format, Kanalzahl)

- softvol (softvolume) macht eine Lautstärkeregelung in Software

- dmix (dmixer) mischt die Audioausgaben mehrerer Anwendungen (der muss immer als letztes kommen, weil dmix nur direkt an Soundkarten, nicht aber andere plugins weiterleitet)

Wenn allerdings kscd bereits bei den vorigen Einstellungen über default wiedergegeben hat, hätte die Lauststärkeregelung auch schon vorher funktionieren sollen.

Ich könnte mir vorstellen, dass das daran liegt, dass kscd als KDE-Programm wahrscheinlich eine kde-typische Abstraktionsschicht zur Audiowiedergabe nutzt (phonon) und gerade phonon habe ich als etwas störrisch in Erinnerung, wenn es darum geht, dass es die eigene Alsakonfiguration nutzen soll. Eigentlich glaube ich, dass ein KDE-Programm wie kscd eine etwas ungünstige Wahl für die Wiedergabe von Audio-CDs ist und das gilt umso mehr, als man ohne weitere KDE-Pakete erst einmal keine einfache Möglichkeit hat phonon irgendwie zu konfigurieren und das ganze dann auf ein System hinausläuft, das alles andere als schlank und übersichtlich ist, was auf dem RPi aber bestimmt von Vorteil wäre.

Falls auch andere Programme in Frage kommen: Hast du KSCD wegen der grafischen Oberfläche ausgewählt oder anders gefragt, welche Kriterien muss denn das CD-Abspielprogramm denn erfüllen?

Also wenn es darum geht die Softwarelautstärkeregelung zum Funktionieren zu bringen willst, bekommen wir das hin.

Bei der verlinkten Anleitung ist das Problem vermutlich, dass auf "plughw:0" verwiesen wird, also auf die in der Alsa-Nummerierung erste Soundkarte. Die Nummerierung ist aber nicht vorhersagbar und kann sich im Grunde von Systemstart zu Systemstart ändern. (Es gibt zwar einige Maßnahmen, dass die Nummerierung doch etwas vorhersagbarer wird, aber wie man sieht funktioniert das nicht immer.)

Besser wäre es also die Namen zu verwenden.

Es wäre nur ganz interessant zu wissen ob du auch mit mehreren Anwendungen gleichzeitig Audio wiedergeben willst (dafür fehlt bei der verlinkten Anleitung noch etwas) und für die Namen der Soundkarten die Ausgabe von

$ aplay -l