Seite 1 von 3

Linux-Optimierung für die Wiedergabe digitaler Audiodaten

Verfasst: 12.05.2015, 10:04
von huscape
Betriebssystemoptimierungen für die Wiedergabe digitaler Audiodaten unter Linux
Über die digitale Audioausgabe unter Linux wurde ja bereits einiges in diesem Forum geschrieben. Ich habe versucht mich diesem Thema mit Linux-Borbmitteln zu nähern und letztlich einen Audiopc aufzubauen, den ich mittels graphischer Front-Ends auch über Tablet-PCs oder Touch-Phones steuern kann.
Selbstverständlich stand auch bei mir die möglichst bitgenaue Wiedergabe der gespeicherten Audiodaten im Vordergrund.
Hinzu kommt, dass ich auch auf die Einbindung von Firewire Audio Interfaces eingegangen bin, was evtl. tatsächlich für den Ein- oder Anderen eine Hilfestellung sein könnte, da diesbezüglich hier noch nicht viel geschrieben wurde.
Da ich auch Platten digitalisiere gibt es auch einen Abschnitt über die Aufnahme analoger Audiodaten und deren digitaler Speicherung.
Über Anregungen und Verbesserungsvorschläge freue ich mich jederzeit. Falls jemand sich an dem von mir beschriebenen Setup orientieren möchte, stehe ich gerne jederzeit mit Rat und Tat zur Verfügung.

Keywords
Linux, Audio, Realtime, Bitperfect, low latency

Resources
http://ccrma.stanford.edu/planetccrma/software
http://music.tutsplus.com/articles/work ... udio-20601
http://stufs4u.wordpress.com/2014/02/25 ... fedora-20/
https://spins.fedoraproject.org/lxde/
http://wiki.linuxmusicians.com/doku.php
http://wiki.linuxaudio.org/wiki/system_configuration
http://wiki.ubuntuusers.de/Tonstudio/Konfiguration
https://access.redhat.com/documentation ... rnors.html
http://lwn.net/Articles/143397
http://docs.fedoraproject.org/en-US/Fed ... erVNC.html
http://stufs4u.wordpress.com/2014/02/25 ... fedora-20/

Hardware

Computer
Jeder beliebige Computer mit einer geeignetten Schnittstelle für eine anständige Soundkarte der mit einem Linuxbetriebssystem lauffähig ist (ich kenne mich nur mit Linux aus).

getestete Soundkarten
EDIROL FA-66
Gustard U12 mit USB-Kabel VS-04-2X2X26C7/7-SDA/SDB/2,0
Musical Fidelity V-Link 192kHz mit USB-Kabel VS-04-2X2X26C7/7-SDA/SDB/2,0
und externem Netzteil Squeeze-Upgrade BOTW Linearnetzteil 5V USB-B
Musical Fidelity V90-DAC 24/96 mit USB-Kabel VS-04-2X2X26C7/7-SDA/SDB/3,0
M Audio Audiophile 24/96

DAC
Naim DAC / Naim 555 PS DR

Vorverstärker
Naim NAC 552 / Naim SuperCap DR

Endstufe
Naim NAP 500

Lautsprecher
Naim DBL

Betriebssystem-Installation
- Installation von Fedora 21 Workstation x86_64
Als Unterlage für unser Audio-Linux System soll Fedora in der aktuellen Version, aber mit möglichst wenig Schnickschnack herhalten.
Fedora bietet sog. Spins an, die vorkonfiguriert die Distribution für unterschiedliche Anwendergruppen bereitstellen. Ich habe mich für den schlanken LXDE Desktop Spin entschieden, siehe:
https://spins.fedoraproject.org/lxde/

Vorgehensweise
→ durchgeführte Maßnahmen bei der Betriebssysteminstallation:
> - booten von Live-Medium
> - sobald Arbeitsoberfläche betriebsbereit: Install to Hard Drive
> - Installationssprache: Deutsch
> - Datum und Uhrzeit: Europa/Berlin
> - Tastatur: Deutsch
> - Installationsziel:
> - ich werde die Partitionierung konfigurieren
> - Partitionierungsschema: Standard-Partition
> + Einhängepunkt: / , Kapazität: 32 GB, Dateisystem: ext4, Label: root
> + Einhängepunkt: swap , Kapazität: 16 GB, Dateisystem: swap, Label: swap
> + Einhängepunkt: local , Kapazität: Rest, Dateisystem: ext4, Label: swap
> Netzwerk & Hostname: pc-wohnzimmer
> Root-Password: ***
← durchgeführte Maßnahmen bei der Betriebssysteminstallation:

booten, dann als root:

→ Benutzer anlegen nach erfolgreicher Intallation un dem ersten Booten:

Code: Alles auswählen

mkdir /local/home
echo "scc:x:750:" >> /etc/group
useradd -d /local/home/hu -u 7513 -g 750 hu
passwd hu
← Benutzer anlegen nach erfolgreicher Intallation un dem ersten Booten:

Nachinstallation bei Verwendung von Firewire Audio Devices
nur wenn das Sounddevice ein Firewire Device ist:

Code: Alles auswählen

yum install ffado libffado
yum install jack-audio-connection-kit qjackctl
Hardwarecheck

Hardwarecheck bei Firewire Devices

Karte 1

Code: Alles auswählen

lspci | grep -i firewire
> 08:03.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02)

ffado-test ListDevices
> -----------------------------------------------
> FFADO test and diagnostic utility
> Part of the FFADO project -- www.ffado.org
> Version: 2.2.1-Unversioned directory
> (C) 2008, Daniel Wagner, Pieter Palmers
> This program comes with ABSOLUTELY NO WARRANTY.
> -----------------------------------------------
> 
> === 1394 PORT 0 ===
>   Node id  GUID                  VendorId     ModelId   Vendor - Model
>    0       0x00000e1003b3b456  0x0000000E  0x00000000   Linux Firewire - 
>    1       0x0040ab0000c33b85  0x000040AB  0x00010049   EDIROL - EDIROL FA-66
Karte 2

Code: Alles auswählen

lspci | grep -i firewire
> 01:07.0 FireWire (IEEE 1394): NEC Corporation uPD72874 [Firewarden]
>	IEEE1394a OHCI 1.1 Link/3-port PHY Controller (rev 01)

ffado-test ListDevices
> -----------------------------------------------
> FFADO test and diagnostic utility
> Part of the FFADO project -- www.ffado.org
> Version: 2.2.1-Unversioned directory
> (C) 2008, Daniel Wagner, Pieter Palmers
> This program comes with ABSOLUTELY NO WARRANTY.
> -----------------------------------------------
> 
> === 1394 PORT 0 ===
>   Node id  GUID                  VendorId     ModelId   Vendor - Model
>    0       0x0040ab0000c33b85  0x000040AB  0x00010049   EDIROL - EDIROL FA-66
Hardwarecheck bei allen anderen Audio Devices

Code: Alles auswählen

more /proc/asound/cards
>  0 [x20            ]: USB-Audio - xCORE USB Audio 2.0
>                       XMOS xCORE USB Audio 2.0 at usb-0000:00:1d.7-2, high speed
>  1 [M192kHz        ]: USB-Audio - Musical Fidelity V-Link 192kHz
>                       Musical Fidelity Musical Fidelity V-Link 192kHz
>                       at usb-0000:00:1d.7-2, high spead
>  2 [Intel          ]: HDA-Intel - HDA Intel
>                       HDA Intel at 0xfe220000 irq 50
>  3 [M2496          ]: USB-Audio - M Audio Audiophile 24/96
>                       M Audio Audiophile 24/96 at at usb-0000:00:1d.7-3, high spead
>  4 [M2496          ]: USB-Audio - Musical Fidelity V90-DAC 24/96
>                       Musical Fidelity Musical Fidelity V90-DAC 24/96
>                       at usb-0000:00:1d.0-1, full speed
> 29 [ThinkPadEC     ]: ThinkPad EC - ThinkPad Console Audio Control
>                       ThinkPad Console Audio Control at EC reg 0x30, fw 7KHT24WW-1.08
CCRMA Kernel (Realtime Kernel)

Repositories

Code: Alles auswählen

yum localinstall http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/21/x86_64/planetccrma-repo-1.1-3.fc21.ccrma.noarch.rpm
yum localinstall http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-21.noarch.rpm
yum localinstall http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-21.noarch.rpm
Real-Time Kernel
Um Musik unter Linux anständig wiedergeben zu können müssen wir den sog.
realtime kernel verwenden.

Code: Alles auswählen

vi /etc/yum.conf
→ /etc/yum.conf:
...
installonly_limit=0
...
← /etc/yum.conf:

vi /etc/yum.repos.d/fedora-updates.repo
→ /etc/yum.repos.d/fedora-updates.repo:
...
[updates]
...
exclude=kernel-[0-9]* kernel-devel-[0-9]* kernel-headers-[0-9]* kernel-tools-* kernel-tools-libs-* kernel-core-* kernel-modules-* kernel-modules-extra-* pulseaudio-*
...
← /etc/yum.repos.d/fedora-updates.repo:

yum install planetccrma-core kernel-rt kernel-headers kernel-tools kernel-tools-libs
Standard Kernel
Um bei zukünftigen Betriebssystem Updates den Realtime Kernel nicht durch den Standardkernel zu ersetzen, klammern wir die entsprechenden Pakete aus.

Code: Alles auswählen

vi /etc/yum.repos.d/fedora-updates.repo
→ /etc/yum.repos.d/fedora-updates.repo:
...
[updates]
...
exclude=kernel-[0-9]* kernel-devel-[0-9]* kernel-headers-[0-9]* kernel-tools-* kernel-tools-libs-* kernel-core-* k
ernel-modules-* kernel-modules-extra-* pulseaudio-*
...
← /etc/yum.repos.d/fedora-updates.repo:
Sicherheitshalber löschen wir nun auch die Standard Kernel.

Code: Alles auswählen

yum erase kernel kernel-core kernel-modules kernel-modules-extra
Und jetzt den Betriebssystem Update um zu schauen, ob der Standard-Kernel nicht wieder zurückkehrt.

Code: Alles auswählen

yum update
Den Realtime Kernel zum Grub Standardkernel werden zu lassen können wir uns sparen, da es keine Standardkernel mehr gibt, aber trotzdem als Anmerkung der Vollständigkeit halber:

Code: Alles auswählen

grub2-set-default  "Fedora (3.14.25-200.rt22.1.fc21.ccrma.x86_64+rt) 21 (Twenty One)"
reboot
Weitere Betriebssystem-Anpassungen

selinux deaktivieren

Code: Alles auswählen

vi /etc/sysconfig/selinux
→ /etc/sysconfig/selinux:
...
SELINUX=disabled
...
← /etc/sysconfig/selinux:
Prozesse abschalten

Code: Alles auswählen

systemctl disable auditd.service
systemctl stop auditd.service

systemctl disable avahi-daemon.socket
systemctl stop avahi-daemon.socket
systemctl disable avahi-daemon.service
systemctl stop avahi-daemon.service

systemctl disable bluetooth.service
systemctl stop bluetooth.service

systemctl disable smartd.service
systemctl stop smartd.service

systemctl disable tcsd.service
systemctl stop tcsd.service

Prozesse einschalten
--------------------
systemctl enable sshd.service
systemctl start sshd.service
Benutzer mit Superuserrechten ausstatten

Code: Alles auswählen

visudo
→ /etc/yum.conf:
...
root    ALL=(ALL)       ALL
hu      ALL=(ALL)       NOPASSWD: ALL
...
← /etc/yum.conf:
Video Card Driver
Der von mir verwendete Laptop ist mit einer Nvidia Grafikkarte ausgestattet.

Code: Alles auswählen

lspci | grep -i vga
> 01:00.0 VGA compatible controller: NVIDIA Corporation G86M [Quadro NVS 140M] (rev a1)
Ich möchte nicht den Freeware Treiber nouvea verwenden, sondern vertraue auf den proprietären Hersteller-Treiber. Der für meine Karte ist der Linux x64 (AMD64/EM64T) Display Driver, Version 340.xx

Code: Alles auswählen

vi /etc/yum.conf
→ /etc/yum.conf:
...
exclude=xorg-x11-drv-nouveau-*
...
← /etc/yum.conf:
yum erase xorg-x11-drv-nouveau

vi /etc/modprobe.d/nouveau.conf 
→ /etc/modprobe.d/nouveau.conf:
blacklist nouveau
← /etc/modprobe.d/nouveau.conf:

vi /etc/default/grub
→ /etc/default/grub:
...
GRUB_CMDLINE_LINUX="rhgb quiet rdblacklist=nouveau"
...
← /etc/default/grub:

grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/sda

systemctl set-default multi-user.target
yum install akmod-nvidia-340xx xorg-x11-drv-nvidia-340xx-libs kernel-rt-devel acpid
reboot
Wer behauptet ich wäre paranoid veranlagt, weil ich den nouveau Treiber doppelt und dreifach unterbunden habe, hat recht. So ist es leider.

Code: Alles auswählen

vi /etc/X11/xorg.conf
→ /etc/X11/xorg.conf:
# RPM Fusion - nvidia-xorg.conf
# 
Section "Device"
	Identifier  "Videocard0"
	Driver      "nvidia"
EndSection
← /etc/X11/xorg.conf:
Falls "startx" klappt:

Code: Alles auswählen

systemctl set-default graphical.target
reboot
Benutzer anlegen (falls noch nicht geschehen)

Code: Alles auswählen

mkdir /local/home
echo "scc:x:750:" >> /etc/group
useradd -d /local/home/hu -u 7513 -g 750 hu
passwd hu
Audiouser "hu" den richtigen Gruppen zuordnen
Damit keine Rechte-Probleme beim Zugriff auf die Audio-Devices durch Benutzer entstehen müssen diese den entsprechenden Gruppen hinzugefügt werden.

Code: Alles auswählen

sudo usermod -a -G audio hu 
sudo usermod -a -G jackuser hu 
grep hu /etc/group
> audio:x:63:hu
> jackuser:x:981:hu
disable pulse audio
Es existiert die Möglichkeit die Verwendung von Pulsaudio pro Benutzer zu steuern.

Code: Alles auswählen

mkdir ~/.pulse
echo ‘autospawn = no’ > ~/.pulse/client.conf
Meine Erfahrung ist, das Pulsaudio vom System trotzdem gestartet wird. Ich bevorzuge deshalb Pulsaudio systemweit für alle Zeiten den Garaus zu machen. Aus audiophiler Sicht ist das Pulsaudiosystem der größte Quatsch, den man sich vorstellen kann.

Code: Alles auswählen

chmod -x /usr/bin/pulseaudio
vi /etc/yum.repos.d/fedora-updates.repo
→ /etc/yum.repos.d/fedora-updates.repo:
...
[updates]
...
exclude=kernel-[0-9]* kernel-devel-[0-9]* kernel-headers-[0-9]* kernel-tools-* kernel-tools-libs-* kernel-core-* k
ernel-modules-* kernel-modules-extra-* pulseaudio-*
...
← /etc/yum.repos.d/fedora-updates.repo:
Reihenfolde der Soundkarten im System (nicht für Firewire Devices)
Zunächst einmal die Liste der Soundkarten aufrufen, die Alsa gefunden hat:

Code: Alles auswählen

cat /proc/asound/cards
> 0 [Intel          ]: HDA-Intel - HDA Intel
>                      HDA Intel at 0xfe220000 irq 49
> 1 [M2496          ]: USB-Audio - Musical Fidelity V90-DAC 24/96
>                      Musical Fidelity Musical Fidelity V90-DAC 24/96
>                      at usb-0000:00:1d.0-1, full spe
>29 [ThinkPadEC     ]: ThinkPad EC - ThinkPad Console Audio Control
>                      ThinkPad Console Audio Control at EC reg 0x30,
>                      fw 7KHT24WW-1.08
Welches sind die entsprechenden Kernel-Module?

Code: Alles auswählen

cat /proc/asound/modules 
>  0 snd_hda_intel
>  1 snd_usb_audio
> 29 thinkpad_acpi
Die Reihenfolge ändern:

Code: Alles auswählen

vi /etc/modprobe.d/sound-cards-order.conf
→ /etc/modprobe.d/sound-cards-order.conf:
options snd_usb_audio index=0
options snd_hda_intel index=1
options thinkpad_acpi index=29
← /etc/modprobe.d/sound-cards-order.conf:

reboot
Kontrolle:

Code: Alles auswählen

cat /proc/asound/modules
Alsa Konfiguration (nicht für Firewire Devices)
Ziel ist es von der Anwendung direkt auf den Alsa-Kernellayer zuzugreifen. Dabei soll unter Anderem ein Resampling unterbunden werden, d.h. die Audiodaten sollen 1:1 vom Sounddevice wiedergegeben werden.
Ein Mixer (so dass z.B. mehrere Anwendungen gleichzeitig auf das Sound-Device zugreifen können) soll nicht bereitgestellt werden.

Sound Device mit Namen "default" erstellen:

Code: Alles auswählen

vi ~/.asoundrc
→  ~/.asoundrc:
pcm.snd_usb_audio {
    type hw
    card 0
    device 0
}

ctl.snd_usb_audio {
    type hw
    card 0
    device 0
}

ctl.!default {
    type hw
    card 0
    device 0
}

# Create a default pcm, use the "plug" wrapper
# to wrap the named PCM we created above.
#
# Plug will adjust sample format as needed; we can
# force it to never change the sample rate! Nice.
#
pcm.!default {
    type plug
    slave {
        pcm "snd_usb_audio"
        rate "unchanged"
    }
}
←  ~/.asoundrc:

Autologin für den neuen Audio Benutzer

Code: Alles auswählen

vi /etc/lxdm/lxdm.conf
→ /etc/lxdm/lxdm.conf:
...
[base]
autologin=hu
...
← /etc/lxdm/lxdm.conf:
Bei den nun folgenden Optimiereungen hat mir das Perl-Script "realTimeConfigQuickScan" geholfen.
Installiert wird es durch:

Code: Alles auswählen

yum install realTimeConfigQuickScan
X-Server für lokales Display abschalten
Eine feine Sache ist es den Audio-PC über Laptop oder Touch-Pad bzw. Handy fernsteuern zu können. Dies geschieht am einfachsten über das sog. VNC-Protokoll (siehe unten).
In diesem Fall ist es denkbar, auf einen lokalen X-Server gänzlich zu verzichten. Ich mache das so.
Zum deaktivieren des lokalen X-Servers folgenden Befehl absetzen:

Code: Alles auswählen

systemctl set-default multi-user.target
reboot
Kernel and real-time capabilities
Der Sinn in der Verwendung eines Kernel mit Echtzeitfähigkeiten liegt in dessen Fähigkeit niedrige Latzenzen für die Widergabe von Audio-Dateien zu ermöglichen.
Der Realtime-Kernel-Test im Script "realTimeConfigQuickScan" fragt leider nicht die richtigen Kernel-Config-Parameter ab. Ob der Kernel über entsprechende Fähigkeiten verfügt findet man heraus durch:

Code: Alles auswählen

grep CONFIG_PREEMPT= /boot/config-`uname -r`; \
grep CONFIG_PREEMPT_RT_BASE= /boot/config-`uname -r`; \
grep CONFIG_PREEMPT_RT_FULL= /boot/config-`uname -r`
> CONFIG_PREEMPT=y
> CONFIG_PREEMPT_RT_BASE=y
> CONFIG_PREEMPT_RT_FULL=y
filesystem (noatime)
Weitere Informationen unter: http://wiki.linuxmusicians.com/doku.php ... ilesystems

Code: Alles auswählen

vi /etc/fstab
→ /etc/fstab:
...
/dev/sda1	/		ext4	defaults,noatime	1 1
/dev/sda5	/local		ext4	defaults,noatime	1 2     
...
← /etc/fstab:
CPU Frequenzy
Oft wird unter Fedora die CPU nicht mit ihrer maximalen Taktrate betrieben, sondern erst im Bedarfsfall hochgetaktet. Darauf sollte man sich nicht verlassen und stattdessen den Rechner /sollte die CPU dies unterstützen) immer mit vollem CPU-Takt betreiben.
siehe: https://access.redhat.com/documentation ... rnors.html und http://linuxmusicians.com/viewtopic.php?f=27&t=844

Achtung bei Laptops! Kann tüchtig in die Hose gehen.

Code: Alles auswählen

yum install cpupowerutils
cpupower frequency-info --hwfreq
> analysiere CPU 0:
> 1000000
Falls der Rechner kein "cpupower frequency-set" unterstützt wird der Folgende Befehl schlimmstenfalls mit einem Kernel-Dump enden. Also sicherheitshalber vorher alle geöffneten Dateien schließen.

Code: Alles auswählen

cpupower frequency-set -g performance
> Setting cpu: 0
> Setting cpu: 1

cpupower frequency-info --hwfreq
> analysiere CPU 0:
> 2600000

vi /etc/rc.d/rc.local
→ /etc/rc.d/rc.local:
...
cpupower frequency-set -g performance
...
← /etc/rc.d/rc.local:
Falls noch nicht geschehen:

Code: Alles auswählen

chmod 755 /etc/rc.d/rc.local
Prozesse mit chrt priorisieren
Um Prozesse wie unter Anderem den Jack-Daemon priorisieren zu dürfen müssen folgende Anpassungen durchgeführt werden:

Code: Alles auswählen

mv /etc/security/limits.d/95-jack.conf /etc/security/limits.d/95-jack.conf.do_not_use
vi /etc/security/limits.conf
→ /etc/security/limits.conf:
...
# Optimization for Jack-Daemon and realtimepriority
# see: http://wiki.ubuntuusers.de/Tonstudio/Konfiguration
@audio - rtprio  99
@audio - nice   -19
@audio - memlock unlimited
@jackuser - rtprio  99
@jackuser - nice   -19
@jackuser - memlock unlimited
...
← /etc/security/limits.conf:
Die Änderungen werden erst nach einem relogin wirksam.

Swap abschalten
Sobald nicht genügend Hauptspeicher für alle Programme auf dem Rechner bereitsteht, beginnt normalerweise das Betriebssystem virtuellen Hauptspeicher auf der Festplatte zu verwenden, also zu swappen. Dies ist für eine Audioworkstation unbrauchbar.
Ich schalte das swapping deshalb vollständig aus.

Code: Alles auswählen

vorher:
sysctl vm.swappiness
vm.swappiness = 60

vi /etc/sysctl.d/99-sysctl.conf
→ /etc/sysctl.d/99-sysctl.conf:
...
vm.swappiness = 0
...
← /etc/sysctl.d/99-sysctl.conf:

reboot

nachher:
sysctl vm.swappiness
vm.swappiness = 0
Hardware Timer
Dieser Abschnitt betrifft vorwiegend ALSA-Midi. Evtl benutzen ja einige dieses, deshalb
sollen die Hardware-Timer nicht unerwähnt bleiben.

Code: Alles auswählen

vi /etc/udev/rules.d/40-timer-permissions.rules
→ /etc/udev/rules.d/40-timer-permissions.rules:
KERNEL=="rtc0", GROUP="audio"
KERNEL=="hpet", GROUP="audio"
← /etc/udev/rules.d/40-timer-permissions.rules:
Nun können Benutzer aus der "audio"-Gruppe timer verwenden. Dies aber nur mit einer zu niedrigen Priorität, siehe:

Code: Alles auswählen

cat /proc/sys/dev/hpet/max-user-freq 
> 64
cat /sys/class/rtc/rtc0/max_user_freq 
> 64
Es herrscht leider keine Einigkeit über den "richtigen" Wert für die Priorisierung der Hardware Timer. Sinnvoller Weise sollte sich diese wohl zwischen 1024 und 8192 bewegen.

Code: Alles auswählen

vi /etc/rc.d/rc.local
→ /etc/rc.d/rc.local:
#!/bin/sh

...
echo -n 3072 > /sys/class/rtc/rtc0/max_user_freq
echo -n 3072 > /proc/sys/dev/hpet/max-user-freq
...
← /etc/rc.d/rc.local:
Falls noch nicht geschehen:

Code: Alles auswählen

chmod 755 /etc/rc.d/rc.local

reboot

cat /proc/sys/dev/hpet/max-user-freq 
> 3072
cat /sys/class/rtc/rtc0/max_user_freq 
> 3072
Software Timer
Über threadet IRQs möchte ich an dieser Stelle keine Worte verlieren. Wer sich für die Hintergründe interessiert, dem empfehle ich eine Recherche im Internet. Wichtig ist dieser Abschnitt auf jedenfall mindestens für alle, die den Jack-Daemon für die Soundausgabe verwenden. Allgemein sollten jedoch alle mit USB-Sounddevices ihren Augenmerk auf diese Optimierung lenken.

Zunächst einmal prüfe ich, welchen IRQ meine Firewire-Soundkarte denn verwendet. Ein Blick
auf folgende URLs sei empfohlen:

http://lwn.net/Articles/143397
http://wiki.linuxaudio.org/wiki/system_ ... ng_devices

Code: Alles auswählen

grep firewire /proc/interrupts
>  22:          0         84   IO-APIC  22-fasteoi   ehci_hcd:usb1, firewire_ohci
OK ... den IRQ 22. Den teilt sie sich dann auch noch mit dem USB Controller 1. Nicht so gut.
Das wollen wir dem System zunächsteinmal abgewöhnen.

Code: Alles auswählen

vi /etc/rc.d/rc.local
→ /etc/rc.d/rc.local:
#!/bin/sh

...
echo -n "0000:00:02.1" > /sys/bus/pci/drivers/ehci-pci/unbind
...
← /etc/rc.d/rc.local:
Falls noch nicht geschehen:

Code: Alles auswählen

chmod 755 /etc/rc.d/rc.local

Code: Alles auswählen

reboot

grep firewire /proc/interrupts
>  22:          0         83   IO-APIC  22-fasteoi   firewire_ohci
Schon besser!

Und hier mal ein Beispiel für einen wirklich übervölkerten Interrupt:

Code: Alles auswählen

grep firewire /proc/interrupts
> 16:        105        121   IO-APIC  16-fasteoi   uhci_hcd:usb5, yenta, i915, firewire_ohci, yenta, mmc0
Hier wird es etwas komplizierter. Das hwinfo Skript aus der Suse-Distribution könnte uns weiterhelfen.

Code: Alles auswählen

yum install wget
wget http://download.opensuse.org/repositories/home:/zhonghuaren/Fedora_21/home:zhonghuaren.repo -O /etc/yum.repos.d/rpm-sphere.repo
yum install hwinfo
Wir fangen ganz herkömmlich wie schon in Beispiel zuvor mit demusb5 an:

Code: Alles auswählen

tree /sys/bus/usb/drivers/usb/ | grep usb5
> └── usb5 -> ../../../../devices/pci0000:00/0000:00:1d.3/usb5
also:
echo -n "0000:00:1d.3" > /sys/bus/pci/drivers/uhci_hcd/unbind
Als nächstes yenta ... Wirklich blöd, dass der PCMCIA Slots sich den IRQ mit dem Firewire-Interface teilt. Aber was solls, weg damit.

Code: Alles auswählen

hwinfo > /tmp/hwinfo
grep yenta_cardbus: /tmp/hwinfo
>    yenta_cardbus: /devices/pci0000:00/0000:00:1e.0/0000:08:03.0
>    yenta_cardbus: /devices/pci0000:00/0000:00:1e.0/0000:08:03.1
also:
echo -n "0000:08:03.0" > /sys/bus/pci/drivers/yenta_cardbus/unbind
echo -n "0000:08:03.1" > /sys/bus/pci/drivers/yenta_cardbus/unbind
Nun zum SD-Kartenleser:

Code: Alles auswählen

grep mmc0 /tmp/hwinfo | grep /devices/pci
>   P: /devices/pci0000:00/0000:00:1e.0/0000:08:03.2/leds/mmc0::
>   E: DEVPATH=/devices/pci0000:00/0000:00:1e.0/0000:08:03.2/leds/mmc0::
>   P: /devices/pci0000:00/0000:00:1e.0/0000:08:03.2/mmc_host/mmc0
>   E: DEVPATH=/devices/pci0000:00/0000:00:1e.0/0000:08:03.2/mmc_host/mmc0
> /devices/pci0000:00/0000:00:1e.0/0000:08:03.2/leds/mmc0::
> /devices/pci0000:00/0000:00:1e.0/0000:08:03.2/mmc_host/mmc0
also:
echo -n "0000:08:03.2" > /sys/bus/pci/drivers/sdhci-pci/unbind
Und letztlich zur Grafikkarte:
Das ist natürlich ärgerlich, das sich die Grafikkarte und die Firewire-Karte den gleichen IRQ teilen. Damit müssen wir dann wohl leben.

Code: Alles auswählen

grep i915 /tmp/hwinfo | grep /devices/pci
>             i915: /devices/pci0000:00/0000:00:02.0
>             i915: /devices/pci0000:00/0000:00:02.0
>             i915: /devices/pci0000:00/0000:00:02.0
also:
echo -n "0000:00:02.0" > /sys/bus/pci/drivers/i915/unbind
Und tschüß Grafik. Den Befehl lassen wir dann wohl besser.

Um das Ganze auch beim nächsten Neustart wieder vorzufinden muss alles
in die rc.local eingetragen werden.

Code: Alles auswählen

vi /etc/rc.d/rc.local
→ /etc/rc.d/rc.local:
#!/bin/sh

...
echo -n "0000:00:1d.3" > /sys/bus/pci/drivers/uhci_hcd/unbind
echo -n "0000:08:03.0" > /sys/bus/pci/drivers/yenta_cardbus/unbind
echo -n "0000:08:03.1" > /sys/bus/pci/drivers/yenta_cardbus/unbind
echo -n "0000:08:03.2" > /sys/bus/pci/drivers/sdhci-pci/unbind
...
← /etc/rc.d/rc.local:
Falls noch nicht geschehen:

Code: Alles auswählen

chmod 755 /etc/rc.d/rc.local

Code: Alles auswählen

reboot

grep firewire /proc/interrupts
>  16:        103          0   IO-APIC  16-fasteoi   firewire_ohci, i915
Schon besser! Mit dem shared-IRQ der Grafikkartemüssen werden wir leider leben müssen.

Als letztes ein Beispiel für eine USB-Soundkarte:

Auf welchem Interface befindet sich das USB-Sound Device?

Code: Alles auswählen

hwinfo | grep snd-usb-audio | grep /usb
>    snd-usb-audio: /devices/pci0000:00/0000:00:1d.7/usb2/2-2/2-2:1.0
>    snd-usb-audio: /devices/pci0000:00/0000:00:1d.7/usb2/2-2/2-2:1.1
>    snd-usb-audio: /devices/pci0000:00/0000:00:1d.7/usb2/2-2/2-2:1.0
>    snd-usb-audio: /devices/pci0000:00/0000:00:1d.7/usb2/2-2/2-2:1.1
Wie verhält es sich mit dem entsprechenden IRQ?

Code: Alles auswählen

grep usb2 /proc/interrupts
>    19:         79         74   IO-APIC-fasteoi   ehci_hcd:usb2
Wunderbar, es muss nichts optimiert werden.

als nächstes wird das Script zur Verwendung sog. threadet IRQs von Rui Nuno Capela installiert:

Code: Alles auswählen

yum install rtirq
Die Konfiguration erfolgt über die Datei /etc/sysconfig/rtirq.

Code: Alles auswählen

vi /etc/sysconfig/rtirq
→ /etc/sysconfig/rtirq:
#
# Copyright (c) 2004-2013 rncbc aka Rui Nuno Capela.
#
#   This program is free software; you can redistribute it and/or
#   modify it under the terms of the GNU General Public License
#   as published by the Free Software Foundation; either version 2
#   of the License, or (at your option) any later version.
#
#   This program 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 General Public License along
#   with this program; if not, write to the Free Software Foundation, Inc.,
#   51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
#
# /etc/sysconfig/rtirq
# /etc/default/rtirq
#
# Configuration for IRQ thread tunning,
# for realtime-preempt enabled kernels.
#
# This program is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License version 2 or later.
#

# IRQ thread service names
# (space separated list, from higher to lower priority).
# For ALSA supported Hardware:
# RTIRQ_NAME_LIST="rtc snd i8042"
# For not ALSA supported Hardware like firewire snd-devicer for example:
RTIRQ_NAME_LIST="rtc firewire usb"

# Highest priority.
# RTIRQ_PRIO_HIGH=70
RTIRQ_PRIO_HIGH=90

# Priority decrease step.
RTIRQ_PRIO_DECR=5

# Lowest priority.
RTIRQ_PRIO_LOW=65

# Priority for udev rules
RTIRQ_PRIO_UDEV=70

# Default priority for irq processes
RTIRQ_PRIO_DEFAULT=50

# Whether to reset all IRQ threads to SCHED_OTHER.
RTIRQ_RESET_ALL=0

# On kernel configurations that support it,
# which services should be NOT threaded 
# (space separated list).
# For ALSA supported Hardware:
# RTIRQ_NON_THREADED="rtc snd"
# For not ALSA supported Hardware like firewire snd-devicer for example:
RTIRQ_NON_THREADED="rtc firewire usb"

# Process names which will be forced to the
# highest realtime priority range (99-91)
# (space separated list, from highest to lower priority).
# RTIRQ_HIGH_LIST="timer"
← /etc/sysconfig/rtirq:

systemctl enable rtirq.service
systemctl start rtirq.service
Muteproblem beheben bei Verwendung vom XMOS-Chipsatz wie z.B. mit einer Gustard U12
Nachdem auch meine Gustard urplötzlich stumm blieb fand ich hier im Forum die Lösung des Problems.
Ich unmute die Karte nun jedesmal beim Systemstart.

Code: Alles auswählen

vi /etc/rc.d/rc.local
→ /etc/rc.d/rc.local:
...
CARD=0
amixer -c $CARD scontrols | sed -e 's/^Simple mixer control //' | while read line; do
amixer -c $CARD sset "$line" unmute;
done
...
← /etc/rc.d/rc.local:

Bildschirmschoner deaktivieren
Über das Startmenü:
Einstellungen; Bildschirmschoner; Bildschirmschoner deaktivieren

Jack konfigurieren und starten (bei Verwendung von Firewire Devices)
Der Soundserver Jackd benötigt zum zuverlässigen Betrieb besondere Rechte. Diese Rechte kann man der Gruppe audio zuweisen, indem man mit einem Editor mit Root-Rechten die Datei /etc/security/limits.conf bearbeitet (wie ja oben schon beschrieben, hier aber nochmal als Hinweis).

Code: Alles auswählen

vi /etc/security/limits.conf
→ /etc/security/limits.conf:
...
# Optimization for Jack-Daemon and realtimepriority
# see: http://wiki.ubuntuusers.de/Tonstudio/Konfiguration
@audio          -       rtprio          99
@audio          -       nice            -19
@audio          -       memlock         unlimited
@jackuser       -       rtprio          99
@jackuser       -       nice            -19
@jackuser       -       memlock         unlimited
...
← /etc/security/limits.conf:
Die Rechte stehen erst nach einer Neuanmeldung am System zur Verfügung. Siehe auch: "Audiouser den richtigen Gruppen zuordnen" weiter oben.

Mit dem Programm "qjackctl" existiert eine graphische Anwendung, über die sich der Jack-Daemon
einfach konfigurieren und steuern lässt.

Code: Alles auswählen

qjackctl
> Server Präfix:		/usr/bin/jackd
> Treiber:			firewire
> Echtzeit:			ja
> Priorität:			80
> Ausführliche Meldungen:	ja (während der Testphase)
> Frames/Periode:		64 (WICHTIG: spiel damit und schau wie hoch du kommst)
> Abtastrate:			96000 (evtl auch: 192000)
> Perioden/Puffer:		3
> Maximaler Port:		128
> Timeout (ms):			500
> Schnittstelle:		hw:1 (evtl auch: hw:M192kHz oder hw:0)
> Audio:			Duplex
> Startverzögerung:		2ms
> Latenz:			2ms

ps -ef | grep -i jackd
> hu        1715  1711 30 07:49 ?        00:00:04 /usr/bin/jackd -v -P80 -p128 -dfirewire
>							-dhw:0 -r96000 -p64 -n3
Musik Player

Audacious
Audacious ist ein Fork des Beep Media Player (BMP). Die Arbeiten am BMP, der wiederum auf XMMS basierte, wurden schon vor längerer Zeit eingestellt.
Winamp "Classic Skins" können aber mit Audacious weiter benutzt sowie Winamp-Equalizer-Einstellungen importiert werden.
Zu den unterstützten Formaten gehören unter anderen MP3, MP4, MPEG-Audio, CD-Audio, AAC, SID, MOD, Ogg Vorbis, FLAC, WAV, WMA und NSF. Darüber hinaus unterstützt Audacious Internetradio, LIRC und LastFM/Audioscrobbler.

Das Ziel der Entwickler war es, mit Audacious einen entschlackten, schnellen, stabilen und funktionellen Audioplayer zu erstellen. Den nehme ich.

Code: Alles auswählen

yum install audacious audacious-libs audacious-plugins audacious-plugins-jack
Ein paar Sachen müssen in Audacious konfiguriert werden. Dazu in Audacios die Einstellungen wählen:

Audacios Konfiguration für Firewire Audiodevices

Code: Alles auswählen

audacious
→  Audacious Konfiguration:
> Datei; Einstellungen
>	Audio:	Ausgabe-Plugin:	JACK Ausgabe
>		
> 		Bittiefe:	32
>		
> 		Softwareseitige Amplitudenbegerenzung:	nein
> 		Softwareseitige Lautstärkeregelung:	nein
> 		Wiedergabeverstärkung aktivieren:	nein
←  Audacious Konfiguration:
Audacious Konfiguration für USB und PCI Audiodevices

Audacious soll über das neu geschaffene "default" Audio-device Musikdateien
abspielen.

Code: Alles auswählen

audacious
→  Audacious Konfiguration:
> Datei; Einstellungen
>	Audio:	Ausgabe Plugin:	ALSA Ausgabe
>				Einstellungen:	PCM-Gerät:	default
>						Mixer-Gerät:	hw:1 (HDA-Intel)
>		Bittiefe:	32
>		Puffergröße:	1500 ms
>		
> 		Softwareseitige Amplitudenbegerenzung:	nein
> 		Softwareseitige Lautstärkeregelung:	nein
> 		Wiedergabeverstärkung aktivieren:	nein
←  Audacious Konfiguration:
Wer genau hinschaut bemerkt, dass ich unter den ALSA-Einstellungen als Mixer-Gerät auf die interne Soundkarte meines Laptops verwiesen habe.
Für die zu verwendende Soundkarte habe ich absichtlich kein Mixer-Element definiert doch Audacious verlangt bei der Konfiguration zwingend nach einem.
Wenn ich in Audacious unter Mixer-Gerät auf mein "default" Sounddevice verweise (also: "default (Standard-Mixer-Gerät)"), so erscheint (bei manchen der von mir getesteten Soundkarten) bein Starten von Audacious immer die Fehlermeldung "ALSA error: snd_mixer_attach failed: Das Argument ist ungültig".
Das nervt natürlich. Mit der beschriebenen Vorgehensweise vermeide ich aber die Fehlermeldung. Nicht schön? Finde ich auch. Über sachdienliche Hinweise würde ich mich freuen.

DeaDBeeF - Ultimate Music Player For GNU/Linux

DeaDBeeF hat mir auch auf Anhieb gefallen. Den verwende ich also auch.
Installation:

Code: Alles auswählen

cd /etc/yum.repos.d
wget https://copr.fedoraproject.org/coprs/polarbear/deadbeef/repo/fedora-21/polarbear-deadbeef-fedora-21.repo
yum install deadbeef
DeaDBeeF Konfiguration für Firewire Audiodevices

Zunächst muss das Plugin zur Wiedergabe von Musik über den Jack-Daemon installiert werden. Die findet sich, neben anderen Plugins auf folgender Internet-Seite:

http://deadbeef.sourceforge.net/plugins.html

Ich habe es in den /tmp Systemordner kopiert. Zur Installation als Audio-Benutzer (nicht root!) dann wie folgt vorgehen:

Code: Alles auswählen

cd /tmp
unzip jack-62d1e6a-x86_64.zip
mkdir -p ~/.local/lib/deadbeef
cp ./plugins/jack.so ~/.local/lib/deadbeef
rm -fr ./jack-62d1e6a-x86_64.zip ./plugins

Code: Alles auswählen

→  DeaDBeeF Konfiguration:
> Bearbeiten; Einstellungen
> Audio-Tab;
>       Ausgabe-Plugin: Jack output plugin
> Bearbeiten; Einstellungen
> Erweiterungen-Tab;
>       JACK-Output-Plugin; Einstellungen;
>               Start JACK server automaticaly if not already running: NEIN!
←  DeaDBeeF Konfiguration:
DeaDBeeF Konfiguration für USB und PCI Audiodevices

Code: Alles auswählen

→  DeaDBeeF Konfiguration:
> Bearbeiten; Einstellungen
> Audio-Tab;
>	Ausgabe-Plugin: ALSA
>	Ausgabe-Gerät:	Standard Ausgabegerät
> Bearbeiten; Einstellungen
> Erweiterungen-Tab;
>	ALSA-Output-Plugin; Einstellungen;
>		ALSA resampling verwenden: NEIN!
←  DeaDBeeF Konfiguration:
gnome-mplayer
Der gnome-mplayer ist kein eigentlicher Mediaplayer, sondern vielmehr nur ein graphisches Front/End für den kommandozeilenbasierenden mplayer. Gnome-mplayer übernimmt die Benutzerinteraktion und führt im Betrieb einzeln die selektierten Mediadateien an den mplayer weiter.
Dies brachte mich auf die Idee ein kleine Script zu erstellen, dass anstelle von mplayer durch den gnome-mplayer aufgerufen wird, die Mediendaten auf eine Ramdisk kopiert und danach erst den eigentlichen mplayer aufruft.
Die Funktionalität von gnome-mplayer wird dadurch nicht beeinträchtigt. Lediglich die Pausen zwischen den einzelnen Musiktracks werden etwas länger.

Installation:

Code: Alles auswählen

yum install gnome-mplayer
Erzeugung des Wrapper-Scriptes:

Code: Alles auswählen

mkdir ~/etc
vi ~/etc/mplayer-wrapper.sh
→ ~/etc/mplayer-wrapper.sh:
#!/bin/sh

#################################
#
# Name: mplayer-wrapper.sh
# Date: Di 12. Mai 07:22:42 CEST 2015
# Version: 0.1
#
# Wrapper for the mplayer used from gnome-mplayer.
#
# Files are copied to a ramdisk and played afterwards with a realtime enhanced
# call of mplayer.
#
#################################

DEBUG=1
LOGFILE=/tmp/mplayer-wrapper.log
DELETELOGFILE=1
RAMDIKSIZE=768M
RAMDISKPATH="/run/media/`id -n -u`/audio"
MPLAYER="/bin/chrt 50 /bin/mplayer"
DELETESOFTVOL=1

# do some debugging
#
if [ "$DELETELOGFILE" -eq "1" ]; then
  if [ -f "$LOGFILE" ]; then
    rm $LOGFILE
  fi
fi

if [ "$DEBUG" -gt "0" ]; then
  if [ ! -f "$LOGFILE" ]; then
    touch $LOGFILE
  fi
fi

# Create a bash array for all the arguments passed to this script
#
i=0
argv=()
for arg in "$@"; do
    if [ "$DELETESOFTVOL" == "1" ] && [ "$arg" == "-softvol" ]; then
      argv[$i]=""
    else
      argv[$i]="$arg"
    fi
    i=$((i + 1))
done

NumberOfArguments=$i

if [ "$DEBUG" -gt "0" ]; then
  printf "Arguments\n---------\n" >> $LOGFILE
  echo $@ >> $LOGFILE

  printf "\nnumber of arguments\n-------------------\n" >> $LOGFILE
  echo $NumberOfArguments >> $LOGFILE

  printf "\nMediafile\n---------\n" >> $LOGFILE
  echo ${argv[$((NumberOfArguments - 1))]} >> $LOGFILE
fi

if [ ! -d "$RAMDISKPATH" ]; then
  sudo mkdir -p "$RAMDISKPATH"
  sudo chown "`id -n -u`.`id -n -g`" "$RAMDISKPATH"
fi 

# mount ramdisk directory
#
if [ -z "`mount | grep "$RAMDISKPATH"`" ]; then
  sudo mount -t tmpfs -o size="$RAMDIKSIZE" none "$RAMDISKPATH"
fi

# clean ramdisk
#
rm "$RAMDISKPATH"/*

# copy mediafile to ramdisk
#
cp "${argv[$((NumberOfArguments - 1))]}" "$RAMDISKPATH"

# Create a changed bash array for all the arguments passed to this script
# with new path to ramdisked mediafile
#
i=0
newargs=""
for newarg in "${argv[@]}"; do
    newargs="$newargs $newarg"
    if [ "$i" -eq "$(($NumberOfArguments-2))" ]; then
      break
    fi
    i=$((i + 1))
done
RamdiskedMediaFile="$RAMDISKPATH/`basename "${argv[$((NumberOfArguments - 1))]}"`"

if [ "$DEBUG" -gt "0" ]; then
  printf "\nnew Arguments\n-------------\n" >> $LOGFILE
  printf "$newargs\n" >> $LOGFILE
  printf "\nmplayer call\n------------\n" >> $LOGFILE
  printf "$MPLAYER $newargs $RamdiskedMediaFile" >> $LOGFILE
fi

# call mplayer
#
$MPLAYER $newargs "$RamdiskedMediaFile"

# clean ramdisk
#
rm "$RAMDISKPATH"/*
← ~/etc/mplayer-wrapper.sh:
Konfiguration gnome-mplayer:

Code: Alles auswählen

gnome-mplayer
→  gnome-mplayer Konfiguration:
> Bearbeiten; Einstellungen
>   Wiedergabe Reiter:
>	Audioausgabe:	Standard
>  MPlayer Reiter:
>	Benutzung MPlayer-Software-Lautstärgeregelung: NEIN!
>	Ausführbare Datei von MPlayer: mplayer-wrapper.sh
←  gnome-mplayer Konfiguration:
Obwohl ich innerhalb der Konfiguration des gnome-mpayers die Verwendung der MPlayer-Software-Lautstärgeregelung abgeschaltet hatte, wurde diese immer wieder beim Aufruf des mpayer aktiviert.
Ich habe deshalb einen Schalter in des Wrapper-Script eingefügt, der der nachträglich den Schalter für die Software-Lautstärgeregelung aus der Argumentenliste nimmt (siehe: "DELETESOFTVOL=1" im Wrapper-Script).

Musikaufnahme

Audacity

Zum digitalisieren meiner Plattensammlung verwende ich seit Jahren Audacious. Das Programm ist einfach zu bedienen und erfüllt alle meine Abforderungen.

Die Installation erfolgt wie gehabt via yum:

Code: Alles auswählen

yum install audacity
Konfiguration für Firewire Devices

Code: Alles auswählen

audacity
→  Audacity Konfiguration:
> Bearbeiten; Einstellungen
>	Geräte:	Soundarchitektur:	JACK Audio Connection Kit
>		Wiedergabe Gerät:	firewire_pcm
>		Aufnahme Gerät;		firewire_pcm
>		Aufnahme Kanäle:	Stereo
>	Qualität:
>		Standard-Samplefrequenz:	96000 Hz
>		Standard-Sampleformat:		32-bit float
>		Echtzeit-Umwandlung
>			Samplefrequenz:		Medium Quality
>			Dither:			keiner
>		Hochwertige-Umwandlung
>			Samplefrequenz:		Best Quality
>			Dither:			Shaped
←  Audacity Konfiguration:
Den Stream kontrollieren bei USB Audiodevices

Wenn man so weit gekommen ist, so sollte man am Besten verschiedene Audiodateien mit Audacious abspielen und kontrollieren wie die Daten des Streams zum USB-Audio-Device geartet sind.
Z.B. sollte dies wärend der Wiedergabe eines Musikstücks, dass mit 24bit/96kHz gesampelt wurde als Output generiert werden:

Code: Alles auswählen

→  cat /proc/asound/card0/stream0:
Musical Fidelity Musical Fidelity V90-DAC 24/96 at usb-0000:00:1d.0-1, full spe : USB Audio

Playback:
  Status: Running
    Interface = 1
    Altset = 1
    Packet Size = 582
    Momentary freq = 96007 Hz (0x60.01e8)
    Feedback Format = 10.14
  Interface 1
    Altset 1
    Format: S24_3LE
    Channels: 2
    Endpoint: 1 OUT (ASYNC)
    Rates: 32000, 44100, 48000, 88200, 96000
←  cat /proc/asound/card0/stream0:
Remote login über VNC

Wer seinen Audio-PC remote steuern will, dem seien folgende Links nahe gelegt.
http://docs.fedoraproject.org/en-US/Fed ... erVNC.html
http://stufs4u.wordpress.com/2014/02/25 ... fedora-20/

Die Fernsteuerung des Audio-PCs über VNC finde ich sehr sinnvoll. Man hat so quasi eine Fernbedienung auf seinem Laptop und das ganze ist vollkommen unempfindlich gegenüber Abbrüchen der Netzwerkverbindung zwischen VNC-Client und VNC-Server.
Bricht die Verbindung einmal ab, so läuft die Musik trotzdem weiter wie ursprünglich angewiesen über den VNC-Client. Dieser kann sich nach wiederhergestellter Netzwerkfunktionalität neu verbinden und bekommt sofort die Oberfläche des Servers angezeigt, wie sie vor dem Abbruch auch war.

Installation des Tiger VNC server Paketes

Code: Alles auswählen

yum -y install tigervnc-server
Konfiguration des Tiger VNC server Paketes

Code: Alles auswählen

cp /lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@:10.service
Alle <USER> Strings mit dem Audio-Usernamen ersetzen:

Code: Alles auswählen

vi /etc/systemd/system/vncserver@:10.service
→  /etc/systemd/system/vncserver@:10.service:
# The vncserver service unit file
#
# Quick HowTo:
# 1. Copy this file to /etc/systemd/system/vncserver@.service
# 2. Edit <USER> and vncserver parameters appropriately
#   ("runuser -l <USER> -c /usr/bin/vncserver %i -arg1 -arg2")
# 3. Run `systemctl daemon-reload`
# 4. Run `systemctl enable vncserver@:<display>.service`
#
# DO NOT RUN THIS SERVICE if your local area network is
# untrusted!  For a secure way of using VNC, you should
# limit connections to the local host and then tunnel from
# the machine you want to view VNC on (host A) to the machine
# whose VNC output you want to view (host B)
#
# [user@hostA ~]$ ssh -v -C -L 590N:localhost:590M hostB
#
# this will open a connection on port 590N of your hostA to hostB's port 590M
# (in fact, it ssh-connects to hostB and then connects to localhost (on hostB).
# See the ssh man page for details on port forwarding)
#
# You can then point a VNC client on hostA at vncdisplay N of localhost and with
# the help of ssh, you end up seeing what hostB makes available on port 590M
#
# Use "-nolisten tcp" to prevent X connections to your VNC server via TCP.
#
# Use "-localhost" to prevent remote VNC clients connecting except when
# doing so through a secure tunnel.  See the "-via" option in the
# `man vncviewer' manual page.


[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target

[Service]
Type=forking
# Clean any existing files in /tmp/.X11-unix environment
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l hu -c "/usr/bin/vncserver %i"
PIDFile=/local/home/hu/.vnc/%H%i.pid
ExecStop=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'

[Install]
WantedBy=multi-user.target
←  /etc/systemd/system/vncserver@:10.service:
Firewall-Freischaltung

Code: Alles auswählen

firewall-cmd --permanent --zone=public --add-service vnc-server
Danach habe ich über firewall-config den TCP-Portrange des vnc-server Services
erweitert auf:

Code: Alles auswählen

vnc-server: Proto TCP, Range 5900-5920
Password für den VNC-Benutzer
Als Audio-Benutzer (in meinem Fall: hu) lokal auf dem System einloggen. Dann:

Code: Alles auswählen

vncpasswd
Password : ***
Verify : ***

Falls jemand ein leeres Password möchte:
vncpasswd -f > .vnc/passwd
[ENTER]
Aktivieren und Starten des VNC service

Code: Alles auswählen

systemctl daemon-reload
systemctl enable vncserver@:10.service
systemctl start vncserver@:10.service
Verknüpfung auf dem LXDE-Desktop anlegen
Nachdem alle Pakete installiert sind und ich mich entschieden habe mittels Jack meine Audiohardware anzusteuern und Audacious als Audioplayer zu verwenden, lege ich zwei Iconen zum Schnellstart für die beiden Anwendungen auf dem Desktop an.

Ich klicke im laufenden Desktop mit der rechten Maustaste auf einen freien Bereich. In dem sich öffnenden Kontext-Menü wähle ich "Neu..." und darunter den Punkt "Leere Datei" (mit der Rechten Maus!). LXDE fragt mich nun nach einem Namen für die Datei und ich benenne sie nun "qjackctl.desktop". Wichtig ist das
".desktop", denn daran erkennt LXDE später, dass es sich um eine besondere Datei mit zusätzlichen Angaben handelt.

Die Datei liegt nun auf dem Desktop, Zeit zu hinterlegen was wir mit ihr starten wollen. Ich klicke mit der rechten Maustaste auf das neue Icon und wähle im Kontextmenü den Punkt Leafpad aus. Leafpad ist auf meinem System nach der Grundinstallation ein einfacher mitgelieferter Editor. Wer sein System
anders eingerichtet hat, hat womöglich einen anderen Texteditor hier aufgeführt, oder muss ihn manuell starten und darin unsere Datei öffnen. Sie befindet sich im Ordner ~/Schreibtisch, bei mir also in
/local/home/hu/Schreibtisch .

In die Datei schreibe ich nun folgende Inhalte hinein (Ehrlich gesagt habe ich es nicht wie oben beschrieben über die Maus und Klicks gemacht, sondern direkt die Desktop-Dateien mittels vi editiert.):

Code: Alles auswählen

vi ~/Schreibtisch/qjackctl.desktop
→ ~/Schreibtisch/qjackctl.desktop:
[Desktop Entry]
Name=qjackctl
Comment=start and controll the Jack Daemon
Exec=/usr/bin/qjackctl
TryExec=/usr/bin/qjackctl
Icon=qjackctl
Type=Application
← ~/Schreibtisch/qjackctl.desktop:
Nach dem Abspeichern der Datei kann ich qjackctl nun über Doppelklick auf meine
neue Desktop Verknüpfung starten.

Das Gleiche wiederhole ich nun für die Anwendung "audacious", also:

Code: Alles auswählen

vi ~/Schreibtisch/audacious.desktop
→ ~/Schreibtisch/audacious.desktop:
[Desktop Entry]
Name=audacious
Comment=start the audacious audio player
Exec=/usr/bin/audacious
Icon=audacious
Type=Application
← ~/Schreibtisch/audacious.desktop:
für DeaDBeeF:

Code: Alles auswählen

vi ~/Schreibtisch/deadbeef.desktop
→ ~/Schreibtisch/deadbeef.desktop:
[Desktop Entry]
Name=deadbeef
Comment=start the deadbeef audio player
Exec=/usr/bin/deadbeef
Icon=deadbeef
Type=Application
← ~/Schreibtisch/deadbeef.desktop:
für den gnome-mplayer:

Code: Alles auswählen

vi ~/Schreibtisch/gnome-mplayer.desktop
→ ~/Schreibtisch/gnome-mplayer.desktop:
[Desktop Entry]
Name=gnome-mplayer
Comment=start the gnome-mplayer audio player
Exec=/bin/gnome-mplayer
Icon=gnome-mplayer
Type=Application
← ~/Schreibtisch/gnome-mplayer.desktop:
und für die Anwendung "audacity", also:

Code: Alles auswählen

vi ~/Schreibtisch/audacity.desktop
→ ~/Schreibtisch/audacity.desktop:
[Desktop Entry]
Name=audacity
Comment=start the audacity audio recorder
Exec=/usr/bin/audacity
Icon=audacity
Type=Application
← ~/Schreibtisch/audacity.desktop:
Prozessauslastung und Fazit
Und, haben die Systemoptimierungen etwas gebracht? Zunächsteinmal ein kurzer Blick
auf die Prozessliste:

Code: Alles auswählen

top -H
> top - 07:32:34 up 21 min,  2 users,  load average: 0,77, 0,84, 0,63
> Threads: 295 total,   1 running, 294 sleeping,   0 stopped,   0 zombie
> %Cpu0  : 12,0 us, 28,9 sy,  0,0 ni, 59,1 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
> %Cpu1  : 11,8 us, 19,7 sy,  0,0 ni, 65,0 id,  0,0 wa,  0,0 hi,  3,5 si,  0,0 st
> KiB Mem :  5850212 total,  4869388 free,   271948 used,   708876 buff/cache
> KiB Swap: 17577980 total, 17577980 free,        0 used.  5478896 avail Mem 
> 
>   PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND      
>  1800 hu       -85   0  859492  71088  50272 S 17,8  1,2   2:51.65 FW_ISORCV    
>  1802 hu       -50   0  859492  71088  50272 S 16,2  1,2   2:29.96 jackd        
>   452 root     -86   0       0      0      0 S 15,5  0,0   2:42.21 irq/22-fire+ 
>  1799 hu       -87   0  859492  71088  50272 S 12,9  1,2   2:02.92 FW_ISOXMT    
>  1901 hu       -76   0  841432  73192  64804 S  5,3  1,3   0:02.10 audacious
Nicht irritieren lassen durch die "-50" als Priorität des Jack-Daemon. Das top Komando ist nicht das verlässlichste! Deshalb nochmal per ps-Komando:

Code: Alles auswählen

ps axHo user,lwp,pid,priority,rtprio,ni,command | grep jackd
> ...
> hu        1778  1768 -86     85   - /usr/bin/jackd -v -P80 -p128 -dfirewire -dhw:1 -r96000 -p64 -n3
> hu        1779  1768  -2      1   - /usr/bin/jackd -v -P80 -p128 -dfirewire -dhw:1 -r96000 -p64 -n3
> hu        1780  1768 -87     86   - /usr/bin/jackd -v -P80 -p128 -dfirewire -dhw:1 -r96000 -p64 -n3
> hu        1781  1768 -85     84   - /usr/bin/jackd -v -P80 -p128 -dfirewire -dhw:1 -r96000 -p64 -n3
> hu        1782  1768 -81     80   - /usr/bin/jackd -v -P80 -p128 -dfirewire -dhw:1 -r96000 -p64 -n3
> ...
Wie man sehen kann profitieren die priorisierten Prozesse stark von den Realtime Eigenschaften des angepassten Musiksystems.
Dem FFADO-Firewire Treiber sowie dem Jack-Daemon, dem Interrupt-Handler, der für die Ausgabe der Daten über das Firewire-Interface des Rechners zuständig ist, und dem Ausioplayer audacious, werden die höchsten
Sytemprioritäten zugebilligt (-85, -81, -86, -76).
Die genannten Anwendungen machen regen Gebrauch von den zwei Cores des verwendeten Testsystems (17,8 % + 12,9 % FFADO, 16,2 % jackd, 15,5 % IRQ 22 Firewire-Karte und 5,3 % audacious).
Die Prozesse verteilen sich gleichmäßig auf die Cores.
Bei einem Quad-Core System wären weitere Anpassungen eventuell sinnvoll. Eine Verteilung der FFADO-Firewire Treiber, des Jack-Daemons, des Interrupt-Handlers und des Ausioplayers auf jeweils einen eigenen dedizierten Core wäre denkbar.

Und, wie klingt es?

Dazu später. Im Moment tun mir die Finger vom Tippen weh.

Verfasst: 12.05.2015, 23:21
von Daihedz
Hallo Huscape

Sehr schöne Zusammenfassung! Hoffentlich kannst Du damit einige Leute dazu verführen, doch mal Linux (in diesem Fall Fedora) auszuprobieren. Ich habe schon mal einige Deiner Vorschläge in mein bisheriges Setup-Script eingebaut.

Vielleicht wäre es von allgemein Nutzen, Deine Konfiguration in Form von kleinen Shell-Skripts zur Verfügung zu stellen, so à la

Code: Alles auswählen

#!/bin/bash
#
# sys_basics_selinux.sh
# Purpose: selinux deaktivieren
# Version 0.02
# Datum 10.5.2015
# Target Systems: Fedora V. 21, Fedora V.22
#
sed -i -e 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux
sed -i -e 's/SELINUX=permissive/SELINUX=disabled/g' /etc/sysconfig/selinux
echo ""
cat /etc/sysconfig/selinux
oder

Code: Alles auswählen

#!/bin/bash
#
# sys_basics_noatime.sh
# Purpose: noatime aktivieren
# Version 0.02
# Datum 10.5.2015
# Target Systems: Fedora V. 21, Fedora V.22
#
sed -i -e 's/ext4 *defaults/ext4	defaults,noatime/g' /etc/fstab
echo ""
cat /etc/fstab
Solche Scripts könnten auch dazu verwendet werden, die einzelnen Audio-Programme (brutefir, sox, playhrt, bufhrt ...) massgeschneidert auf die Platform zu compilieren.

Falls dabei noch andere Forenten mitmachen (=scripten und testen) würden, käme mit der Zeit wohl eine ganze Sammlung von solchen Mini-Skripten zusammen, welche vielleicht einmal zu einem gemeinsamen, Audio-optimierten Mini-Fedora zusammenwachsen könnten. Das wäre doch ein Super Projekt!

Ganz in diesem Sinne zu verstehen sind meine folgenden Bemerkungen:

Swap-File: Weshalb denn ein Swap-File bei der Installation einrichten, um es dann in der Konfiguration zu deaktivieren? Ich setze von Anfang an gar kein Swap-File mit auf. Das geht, trotz der entsprechenden Warnung.

Real-Time-Kernel: Nachteil des RT-Kernels @ Fullspeed-CPU: Abwärme! Vorteil/Nutzen des RT-Kernels: höchst fraglich für die blosse Wiedergabe von Audio. Ich benutze deshalb kein RT-Kernel, dafür die präzise timenden Goodies von Frankl. Schön und interessant wäre es, wenn einige Forenten beide Varianten (RT und Nicht-RT) ausprobieren würden. Eine Bemerkung noch für RT- und Scripting-Freaks: Der ccrma-RT-Kernel hinkt vielmals den regulären Kernel-Releases hinterher. Da wäre es vielleicht sinnvoller, gleich die Sources von linux.org zu nehmen, zu patchen und massgeschneidert zu compilieren, nachdem man sich bei osadl.org über den neuesten Stand des Irrtums informiert hat.

Daemons/Dienste/Services: Ich habe den Eindruck, dass da noch wesentlich mehr entfernt, resp. stillgelegt werden könnte.

...
...
...

Anerkennende und hoffnungsfrohe Grüsse
Simon

Verfasst: 13.05.2015, 07:48
von huscape
Lieber Simon,
vielen Dank für deine Anregungen.
Daihedz hat geschrieben: Solche Scripts könnten auch dazu verwendet werden, die einzelnen Audio-Programme (brutefir, sox, playhrt, bufhrt ...) massgeschneidert auf die Platform zu compilieren.

Falls dabei noch andere Forenten mitmachen (=scripten und testen) würden, käme mit der Zeit wohl eine ganze Sammlung von solchen Mini-Skripten zusammen, welche vielleicht einmal zu einem gemeinsamen, Audio-optimierten Mini-Fedora zusammenwachsen könnten. Das wäre doch ein Super Projekt!
Das könnte man sich überlegen. Was letztlich scriptbar ist an der Betriebssystemoptimierung und was nicht ist allerdings die Frage. Unterschiedlichste Distributionen treffen auf unterschiedlichste Hardwareausstattungen. Im Geiste sehe ich eine hohe Zahl von Permutationen. Spätestens bei der IRQ-Optimierung wird es dann wirklich knifflig. Aber die beiden Beispiele, die Du ja bereits selber beigelegt hast zeigen, dass so etwas an der ein oder anderen Stelle möglich ist.
Falls genügend Nachfrage besteht und Andere auch ihre Scriptprogrammierkenntnisse beisteuern, würden ich mich an einem solchen Projekt beteiligen.
[/quote]
Daihedz hat geschrieben: Swap-File: Weshalb denn ein Swap-File bei der Installation einrichten, um es dann in der Konfiguration zu deaktivieren? Ich setze von Anfang an gar kein Swap-File mit auf. Das geht, trotz der entsprechenden Warnung.
Meine gepostete Zusammenfassung ist im Laufe meiner Optimierungsschritte entstanden. Am Anfang legte ich mit einem Swapfile los. Später merkte ich, dass ich ihn nicht mehr wollte. So ist das zu erklären. Selbstverständlich kann man ihn von vorneherein weglassen.
Daihedz hat geschrieben: Real-Time-Kernel: Nachteil des RT-Kernels @ Fullspeed-CPU: Abwärme! Vorteil/Nutzen des RT-Kernels: höchst fraglich für die blosse Wiedergabe von Audio. Ich benutze deshalb kein RT-Kernel, dafür die präzise timenden Goodies von Frankl.
Der Einwand ist berechtigt. Klar ist, dass die Aufnahme und das Wiedergeben von Musik Echtzeitanwendungen sind. Wie weit mein beschriebenes Setup jedoch in den Genuss der als solches ettiketierten Eigenschaften des gepatchten RT-Kernels gelangt, ist für mich technisch nicht vollständig zu beurteilen.

Folgendes Statement bewegte mich schließlich diesen Weg einzuschlagen:
http://ccrma.stanford.edu/planetccrma/software/ hat geschrieben: Planet CCRMA at Home (CCRMA is pronounced ``karma'') is a collection of free, open source rpm packages (RPM stands for RPM Package Manager) that you can add to a computer running Fedora, 18, 19 or 20, or CentOS 5 (not all applications are built on the 64 bit version) to transform it into an audio workstation with a low-latency kernel, current audio drivers and a nice set of music, midi and audio applications (what if you are not using Fedora or CentOS?). It replicates most of the Linux environment we have been using for years here at CCRMA for our daily work in audio and computer music
PS: Abwärme, Langlebigkeit und Energieverbrauch waren keine relevanten Parameter bei der Definition der Zielfunktion ... :D

Den von Dir angemerkten Artikel "Software Experimente mit Linux" von Frank habe ich mit großem Interesse gelesen. Sobald ich mehr Zeit habe, werde ich seine Vorschläge testen. Interessant könnte der von mir erstellte "mplayer-wrapper.sh" auch für sein Projekt sein. So ließe sich seine Anwendung einfach mit dem GUI des Gnome-Mplayers versehen und das für lau.
Daihedz hat geschrieben: Eine Bemerkung noch für RT- und Scripting-Freaks: Der ccrma-RT-Kernel hinkt vielmals den regulären Kernel-Releases hinterher. Da wäre es vielleicht sinnvoller, gleich die Sources von linux.org zu nehmen, zu patchen und massgeschneidert zu compilieren, nachdem man sich bei osadl.org über den neuesten Stand des Irrtums informiert hat.
Der ccrma-RT-Kernel hinkt definitiv immer dem normalen Kernel Tree hinterher. Der Scharm meiner Konfiguration sollte aber unter anderem auch darin bestehen, jederzeit mit "update" in den Genuss von Neuerungen zu kommen. Tatsächlich glaube ich, dass ich durch die Verwendung eines "eigenen" Kernels langfristig mehr veraltern würde, da ich irgendwann mit der Pflege (die ich ja ab nun selber machen müsste) nachlassen würde.
Daihedz hat geschrieben:Daemons/Dienste/Services: Ich habe den Eindruck, dass da noch wesentlich mehr entfernt, resp. stillgelegt werden könnte.

Code: Alles auswählen

systemctl -a | grep .service | grep running

  abrt-oops.service                                                                        loaded    active   running   ABRT kernel log watcher
  abrt-xorg.service                                                                        loaded    active   running   ABRT Xorg log watcher
  abrtd.service                                                                            loaded    active   running   ABRT Automated Bug Reporting Tool
  acpid.service                                                                            loaded    active   running   ACPI Event Daemon
  alsa-state.service                                                                       loaded    active   running   Manage Sound Card State (restore and store)
  atd.service                                                                              loaded    active   running   Job spooling tools
  chronyd.service                                                                          loaded    active   running   NTP client/server
  console-kit-daemon.service                                                               loaded    active   running   Console Manager
  crond.service                                                                            loaded    active   running   Command Scheduler
  dbus.service                                                                             loaded    active   running   D-Bus System Message Bus
  firewalld.service                                                                        loaded    active   running   firewalld - dynamic firewall daemon
  gssproxy.service                                                                         loaded    active   running   GSSAPI Proxy Daemon
  irqbalance.service                                                                       loaded    active   running   irqbalance daemon
  lvm2-lvmetad.service                                                                     loaded    active   running   LVM2 metadata daemon
  lxdm.service                                                                             loaded    active   running   LXDM (Lightweight X11 Display Manager)
  mcelog.service                                                                           loaded    active   running   Machine Check Exception Logging Daemon
  ModemManager.service                                                                     loaded    active   running   Modem Manager
  NetworkManager.service                                                                   loaded    active   running   Network Manager
  polkit.service                                                                           loaded    active   running   Authorization Manager
  rsyslog.service                                                                          loaded    active   running   System Logging Service
  rtkit-daemon.service                                                                     loaded    active   running   RealtimeKit Scheduling Policy Service
  sshd.service                                                                             loaded    active   running   OpenSSH server daemon
  systemd-journald.service                                                                 loaded    active   running   Journal Service
  systemd-logind.service                                                                   loaded    active   running   Login Service
  systemd-udevd.service                                                                    loaded    active   running   udev Kernel Device Manager
  udisks2.service                                                                          loaded    active   running   Disk Manager
  user@0.service                                                                           loaded    active   running   User Manager for UID 0
  user@1001.service                                                                        loaded    active   running   User Manager for UID 1001
Wie man sieht hast Du auch damit recht.

Code: Alles auswählen

systemctl disable gssproxy.service
systemctl stop gssproxy.service

systemctl disable lvm2-lvmetad.service
systemctl stop lvm2-lvmetad.service

systemctl disable mcelog.service
systemctl stop mcelog.service

systemctl disable ModemManager.service
systemctl stop ModemManager.service

systemctl disable systemd-journald.service
systemctl stop systemd-journald.service
... mehr traue ich mich nicht ... (danke, dass Du mich daran erinnert hast!) ... Habe es direkt übernommen.

Liebe Grüße, euer Hans

Verfasst: 13.05.2015, 13:29
von MPB
Ein schöner Beitrag! Habe hier einige Anregungen erhalten, die ich ausprobieren werde.

Vielen Dank für Deine Arbeit!

Grüße

Marcus

Verfasst: 13.05.2015, 20:54
von huscape
... und wie klingt es?

Wer den Artikel gelesen hat weiss, das ich verschiedene Setups getestet habe. Aber hier eine kurze Ergebnisbeschreibung der am besten klingenden Kombination.

Mit folgenden Komponenten ergab sich der beste Höreindruck:

Hardware in der Signalreihenfolge
Computer: Laptop Lenovo T61 mit 2GB Hauptspeicher
USB-Kabel: VS-04-2X2X26C7/7-SDA/SDB/2,0
Soundkarte: Gustard U12
DAC: Naim DAC / Naim 555 PS DR
Vorverstärker: Naim NAC 552 / NAC552PS-DR
Endverstärker: Naim NAP 500
Lautsprecher: Naim DBL

Ich finde es schwierig Verbesserungen in einem Setup zu beurteilen, da ja oft zeitliche Verzögerungen zwischen den Modifikationsschritten liegen.
Der Naim DAC hat eine interessante Eigenheit, mit deren Hilfe man stets eine Referenz hat. Er verfügt über einen eigenen USB-Port in den man einen USB-Stick mit Audiodaten stecken kann. Der DAC wird dann zum Master und spielt die enthaltenen Dateien der Reihenfolge nach ab. Kein Wiedergabegerät, dass an den DAC via SPDIF angeschlossen wird funktioniert besser als diese Lösung. Ich hatte bereits Gelegenheit verschiedene (hochwertige) Digitalquellen über den NAIM-DAC betrieben zu lauschen. Es verhielt sich immer so. Selbst Hardware für viele tausend Euro klang nicht besser als ein dergestalt abgespielter USB-Stick.

Das vereinfacht den Test ungemein und erspart mir mich in blumigen Umschreibungen über tonale Klangwiedergabe zu versuchen.

Software, so wie im Artikel oben beschrieben
Media Player: gnome-mplayer

nochmal zur Wiederholung: Der gnome-mplayer ist kein eigentlicher Mediaplayer, sondern vielmehr nur ein graphisches Front/End für den kommandozeilenbasierenden mplayer.
Gnome-mplayer übernimmt die Benutzerinteraktion und führt im Betrieb einzeln die selektierten Mediadateien an den mplayer weiter.
Dies brachte mich auf die Idee ein kleines Wrapper-Script zu erstellen, dass anstelle von mplayer durch den gnome-mplayer aufgerufen wird. Der Wrapper kopiert die Mediendaten auf eine Ramdisk und ruft danach erst den eigentlichen mplayer mit diesen Daten auf. Wenn man also eine Playlist hat, wird nach jedem Track der letzte auf der Ramdisk gelöscht und dann der nächste auf die Ramdisk kopiert. Und so weiter. Ein Vorteil ist, dass die zu verwendende Ramdisk nur so groß sein muss, wie der zu erwartende größte Track. Dies ist per Parameter im Wrapperscript konfigurierbar.
Die Funktionalität von gnome-mplayer wird dadurch nicht beeinträchtigt. Lediglich die Pausen zwischen den einzelnen Musiktracks werden etwas länger.

Musikdateien
Um etwas zu verwenden das jeder kennt habe ich unter Anderem auf die Testbenchdaten von http://www.2l.no zurückgegriffen ( http://www.2l.no/hires/ ). Zum Einsatz kamen Stereo FLAC in 24BIT/192kHz.

Fazit
Ich vermute, dass der direkt angeschlossene USB-Stick am Naim-DAC besser funktioniert hat. Und ja, ihr habt richtig gelesen, ich vermute es. Mit geschlossenen Augen würde ich mir nicht zutrauen treffsicher die richtige Quelle zu benennen. Wenn ein Unterschied zu hören ist, so sind meine Ohren zu verbraucht um diesen wahrzunehmen.

Verfasst: 13.05.2015, 20:56
von huscape
MPB hat geschrieben:Ein schöner Beitrag! Habe hier einige Anregungen erhalten, die ich ausprobieren werde.
Vielen Dank für Deine Arbeit!
Grüße Marcus
Lieber Marcus, danke für das positive Feedback. Viel Erfolg weiterhin beim Optimieren.
Lieber Gruß, Hans

Verfasst: 13.05.2015, 23:37
von frankl
huscape hat geschrieben: - Installation von Fedora 21 Workstation x86_64
Hallo Hans,

Dein Beitrag ist bestimmt nützlich für Leute, die mit Fedora oder CentOS starten wollen. (Ich selbst starte lieber von einer schlanken Installation wie voyage oder archlinux und installiere nach, was mir fehlt, als von einer "dicken" Installation Pakete zu löschen oder Services zu stoppen.)
huscape hat geschrieben: Real-Time Kernel
Um Musik unter Linux anständig wiedergeben zu können müssen wir den sog.
realtime kernel verwenden.
Ob das wirklich sein muss? Was benutzt Du denn von dem Real-Time Kernel, was der Standard-Kernel nicht bietet (und was ist daran besser)? Zum Beispiel gibt es den "realtime scheduler" und die Möglichkeit 'chrt -r' oder 'chrt -f' zu verwenden ja auch im Standard-Kernel.

huscape hat geschrieben: filesystem (noatime)
Ja, das finde ich auch nützlich, Du könntest dann auch gleich noch 'nodiratime' zu den mount-Optionen hinzufügen. Machmal findet man auch den Hinweis, dass man diese Optionen standardmäßig für SSDs verwenden soll.
huscape hat geschrieben: CPU Frequenzy
Oft wird unter Fedora die CPU nicht mit ihrer maximalen Taktrate betrieben, sondern erst im Bedarfsfall hochgetaktet. Darauf sollte man sich nicht verlassen und stattdessen den Rechner /sollte die CPU dies unterstützen) immer mit vollem CPU-Takt betreiben.
Mit dieser Aussage bin ich gar nicht einverstanden. Das ist Energieverschwendung und trägt meiner Meinung auch nicht zur audiophilen Qualität des Systems bei. Wenn die CPU immer mit höchster Geschwindigkeit läuft, wird viel Wärme produziert und unter Umständen die Stromversorgung anderer Komponenten verschlechtert, zum Beispiel benötigen manche RAM Speicher bei größerer Wärme mehr Refresh-Zykeln.

Ich benutze auf meinem Convolver-Rechner die 'cpufreq'-Tools, um den 'governor' (die Strategie zum Einstellen der CPU-Geschwindigkeit) auf 'userspace' zu setzen. Dann kann ich die Geschwindigkeit selbst direkt oder in Skripten fest bestimmen. Wenn ich Musik abspiele, setze ich die Geschwindigkeit hoch (aber nicht auf maximal, sondern hoch genug, so dass die Programme ohne Probleme laufen), danach setze ich sie auf das Minimum zurück. So bleibt die CPU und der Rechner immer so kühl wie möglich und es wird nebenbei noch viel Strom gespart.
huscape hat geschrieben: Swap abschalten
Sobald nicht genügend Hauptspeicher für alle Programme auf dem Rechner bereitsteht, beginnt normalerweise das Betriebssystem virtuellen Hauptspeicher auf der Festplatte zu verwenden, also zu swappen. Dies ist für eine Audioworkstation unbrauchbar.
Ich schalte das swapping deshalb vollständig aus.

Code: Alles auswählen

...
vm.swappiness = 0
...
Das kann eine sinnvolle Einstellung sein, schaltet das swapping aber nicht aus. Im laufenden System kann der Swap mit 'swapoff -a' ausgeschaltet werden, und dauerhaft aus bleibt er durch Auskommentieren der Swap-Zeilen in /etc/fstab.
huscape hat geschrieben: Bricht die Verbindung einmal ab, so läuft die Musik trotzdem weiter wie ursprünglich angewiesen über den VNC-Client. Dieser kann sich nach wiederhergestellter Netzwerkfunktionalität neu verbinden und bekommt sofort die Oberfläche des Servers angezeigt, wie sie vor dem Abbruch auch war.
Ist vnc nicht Overkill (und durch eine Firewall auch unsicher)? Ich logge mich in remote Rechner immer per ssh ein. Ich will zwar nur selten dort graphische Programme starten, aber das ist möglich. Es werden viel weniger Resourcen auf dem Audiorechner benötigt und die graphische Benutzerschnittstelle kann sogar ausgeschaltet werden (was sicher zur audiophilen Qualität beiträgt). Wenn es robust gegen Verbindungsabbrüche sein soll oder Zugriff von mehreren Rechnern möglich sein soll, ist 'tmux' (oder 'screen') nützlich.

Viele Grüße,
Frank

Verfasst: 13.05.2015, 23:57
von frankl
Daihedz hat geschrieben:

Code: Alles auswählen

#!/bin/bash
#
# sys_basics_noatime.sh
# Purpose: noatime aktivieren
# Version 0.02
# Datum 10.5.2015
# Target Systems: Fedora V. 21, Fedora V.22
#
sed -i -e 's/ext4 *defaults/ext4	defaults,noatime/g' /etc/fstab
echo ""
cat /etc/fstab
Hallo Simon,

ein grundsätzliches Problem bei solchen "Installations-Skripten" ist halt, dass sie im Detail doch meist von der genauen Distribution oder sogar dem genauen Release abhängen.

Hier aber noch ein allgemeiner Tipp: Ich versuche, solche Installations-Skripte immer idempotent zu machen, das heißt, dass sie mehrfach aufgerufen werden können, aber beim zweiten und weiteren Aufrufen nichts mehr geändert wird.

Das Beispiel oben ist nicht idempotent, denn bei jedem Aufruf wird ein weiteres ',noatime' eingefügt.
Wenn Du die sed-Zeile durch

Code: Alles auswählen

sed -i -e 's/ext4 *defaults/ext4	noatime,defaults/g' /etc/fstab
ersetzt, passiert ab dem zweiten Aufruf nichts mehr. Bei komplizierteren Fällen muss man if-Abfragen in das Skript einbauen und irgendwie feststellen, ob die Änderung schon gemacht wurde.

Viele Grüße,
Frank

Verfasst: 14.05.2015, 08:08
von huscape
Lieber Frank,

vielen dank für Deine wertvollen Diskussionsbeiträge.
frankl hat geschrieben:(Ich selbst starte lieber von einer schlanken Installation wie voyage oder archlinux und installiere nach, was mir fehlt, als von einer "dicken" Installation Pakete zu löschen oder Services zu stoppen.)
Das ist das schöne an Linux. Jeder findet etwas für sich passendes. Ich hatte ebenfalls an ein schlankeres OS-Design gedacht (Slackware), mich letztlich aber dagegen entschlossen, weil RedHat, Fedora & Co (für mich) am einfachsten zu administrieren ist. Letztlich fressen die "zu vielen" Pakete auch kein Brot, sondern liegen schlimmstenfalls nutzlos auf der Festplatte herum. Das abschalten unbenötigter Dienste empfand ich als überschaubaren Aufwand (wenn ich auch etwas Motivationshilfe durch Simon benötigt habe)
frankl hat geschrieben:Ob das wirklich sein muss?(Realtime-Kernel)

Da habe ich mich schlecht ausgedrückt ("Um Musik unter Linux anständig wiedergeben zu können müssen wir den sog. realtime kernel verwenden"). Besser hätte es wohl heissen müssen: Um Musikdaten möglichst genau wiedergeben zu können muss das Betriebssystem in der Lage sein in Echtzeit Daten zu verarbeiten.
frankl hat geschrieben:Was benutzt Du denn von dem Real-Time Kernel, was der Standard-Kernel nicht bietet (und was ist daran besser)? Zum Beispiel gibt es den "realtime scheduler" und die Möglichkeit 'chrt -r' oder 'chrt -f' zu verwenden ja auch im Standard-Kernel.

Hierzu kann ich mich mur selbst zitieren (siehe oben):
huscape hat geschrieben: Wie weit mein beschriebenes Setup jedoch in den Genuss der als solches ettiketierten Eigenschaften des gepatchten RT-Kernels gelangt, ist für mich technisch nicht vollständig zu beurteilen.

frankl hat geschrieben:Du könntest dann auch gleich noch 'nodiratime' zu den mount-Optionen hinzufügen. Machmal findet man auch den Hinweis, dass man diese Optionen standardmäßig für SSDs verwenden soll.

Sehr gut, danke, füge ich ein.
frankl hat geschrieben: Mit dieser Aussage (CPU-Frequency) bin ich gar nicht einverstanden. Das ist Energieverschwendung und trägt meiner Meinung auch nicht zur audiophilen Qualität des Systems bei. Wenn die CPU immer mit höchster Geschwindigkeit läuft, wird viel Wärme produziert und unter Umständen die Stromversorgung anderer Komponenten verschlechtert, zum Beispiel benötigen manche RAM Speicher bei größerer Wärme mehr Refresh-Zykeln.
Das war auch bei mir die Stelle, die mir die größten Bauchschmerzen bereitet hat. Ich bin noch am experimentieren, ob ich darauf verzichten werde. Erster Höreindruck war, dass ich die Hochtaktung des Prozessors wärend der Musikwiedergabe nicht wahrnehmen kann.
Wahrscheinlich werde ich diese Option nur wärend des Sampelns von Schallplatten verwenden.
huscape hat geschrieben: Swap abschalten
Sobald nicht genügend Hauptspeicher für alle Programme auf dem Rechner bereitsteht, beginnt normalerweise das Betriebssystem virtuellen Hauptspeicher auf der Festplatte zu verwenden, also zu swappen. Dies ist für eine Audioworkstation unbrauchbar.
Ich schalte das swapping deshalb vollständig aus.

Code: Alles auswählen

...
vm.swappiness = 0
...
Sorry, wieder falsch ausgedrückt."vm.swappiness = 0" schaltet das Swappen nicht vollständig aus, sondern hält es für den Fall des "out of memory"-Laufens als letzten Notnagel bereit. Das ist auch das was ich machen wollte.
frankl hat geschrieben:Ist vnc nicht Overkill (und durch eine Firewall auch unsicher)? Ich logge mich in remote Rechner immer per ssh ein. Ich will zwar nur selten dort graphische Programme starten, aber das ist möglich. Es werden viel weniger Resourcen auf dem Audiorechner benötigt und die graphische Benutzerschnittstelle kann sogar ausgeschaltet werden (was sicher zur audiophilen Qualität beiträgt). Wenn es robust gegen Verbindungsabbrüche sein soll oder Zugriff von mehreren Rechnern möglich sein soll, ist 'tmux' (oder 'screen') nützlich.
Ich halte vnc nicht für einen Overkill. In meinem Ansatz verfolgte ich aber auch die Spur den grafischen Desktop zur Fernsteuerung auf mobile Devices zu bringen. Meine Beobachtungen bezüglich der Systemresourceanbeanspruchung durch VNC wärend der Musikwiedergabe haben mich darin bestätigt.
Screen ( http://www.gnu.org/software/screen/screen.html ) benutze ich ebenfalls. Für alle, die komandozeilenorientiert ihren Audioplayer fernsteuern wollen ist das das A&O. Kann ich ebenfalls nur jedem ans Herz legen.

Ganz liebe Grüße, Hans

Verfasst: 14.05.2015, 09:58
von Melomane
Hallo in die Runde,

meine Empfehlung spätestens für den Zeitpunkt, an dem sich der User ein wenig näher mit Linux (nicht nur mit der grafischen Oberfläche) vertraut gemacht hat: Weg damit, mit dem ganzen grafischen Schnickschnack. Wenn schon alles mögliche optimiert wird, um den Rechner für die Musikwiedergabe zu entlasten, dann stört der grafische Overhead meiner Meinung nur. Eigentlich lässt sich alles Benötigte auch auf der Konsole erledigen, z.B. Aufnahmen lassen sich auch mit arecord anfertigen. Wenn der Rechner auch für andere Tätigkeiten genutzt wird, kann man ja im jeweils passenden Runlevel starten oder meinetwegen im runlevel 2 ; dann startet man bei Bedarf das X-System per Hand.

Zum rt-Kernel. Bei dem kommt es wie immer drauf an - ich habe schon Installationen auf einem Raspberry gehabt, in denen der rt-Kernel kontraproduktiv war. In anderen Installationen war er eher vorteilhaft. Das muss man am besten für sein jeweiliges Setup ausprobieren.

Grundsätzlich gilt: Das Schöne bei Linux ist ja, das viele Wege zum Ziel führen und ein jeder nach seinem Gusto glücklich werden kann. ;)

Gruß

Jochen

Verfasst: 14.05.2015, 11:16
von huscape
Lieber Jochen,
Melomane hat geschrieben:Wenn schon alles mögliche optimiert wird, um den Rechner für die Musikwiedergabe zu entlasten, dann stört der grafische Overhead meiner Meinung nur.
Grundsätzlich richtig. Was ist aber, wenn trotz graphischen Krempels die Musikwiedergabe nicht hörbar leidet?
Fazit: Ich vermute, dass der direkt angeschlossene USB-Stick am Naim-DAC besser funktioniert hat. Und ja, ihr habt richtig gelesen, ich vermute es. Mit geschlossenen Augen würde ich mir nicht zutrauen treffsicher die richtige Quelle zu benennen. Wenn ein Unterschied zu hören ist, so sind meine Ohren zu verbraucht um diesen wahrzunehmen.
Ein Arzt hat einmal gesagt: "wer heilt hat recht" ... und ich sage ... es gibt viele Wege die Audio-Wiedergabe auf einer Datenverarbeitungsanlage zu "heilen". Der hier beschriebene Weg verfolgt die Strategie am Ende dem Benutzer eine ansprechende graphische Benutzeroberfläche bereitzustellen, ohne hörbare Qualitätsverluste hinnehmen zu müssen.

Zu den Zeiten der kernel-Version 0.28, als ich Linuxianer wurde, gab es noch keine Linux-Distribution. Eigentlich hatten wir nur den Kernel und sehr wenige Utilities zum spielen. Über die SLS-Distribution freuten wir uns dann alle, aber das war nichts im Vergleich zur Slackware-Distribution die für mich den Duchbruch darstellte und ich mich von IRIX als Desktopbetriebssystem zu verabschieden begann (meine alte O2, R14000 steht immer noch im Schrank und ab und zu werfe ich einen sehnsüchtigen Blick auf sie ... ach der schöne gute 4Dwm) ... sorry ich werde immer mehr off topic ...

Heute stellt Linux eine Alternative zu anderen Betriebssystemen für alle dar. Bei interessierter Beschäftigung mit der Materie kann man Linux heute für alle Aufgaben mit Computern gut verwenden. Ich persönlich möchte nicht auf graphische Gimiks verzichten. Aber das ist Geschmacksache. Jeder wie er möchte. Wichtig ist letztlich, dass die orginäre Aufgabe nicht leidet. In diesem Fall also die Behandlung von Audiodaten. Und wie gesagt ... für mich war es nicht möglich mit dem realisierten Setup einen hörbaren Unterschied zur Referenz (siehe USB-Port am Naim-DAC) wahrzunehmen.

Lieber Grüße, Hans

Verfasst: 14.05.2015, 11:33
von Melomane
Hallo Hans,

ob sich X (oder sonst ein Prozess, der nicht direkt mit der Audio-Wiedergabe zu tun hat) negativ bemerkbar macht oder nicht, hängt ja letztlich von der Leistungsfähigkeit der Hardware ab. Und dann ist in der Tat noch zu unterscheiden die +/- audiophile Qualität der Musikwiedergabe und deren grundsätzliche Funktionsfähigkeit. Mit letzterer meine ich die Fähigkeit des Rechners, die Musik störungsfrei wiederzugeben. Wenn also die Kiste so leistungsschwach[1] ist, dass sie es nicht schafft, gleichzeitig X- und Musikwiedergabeprozesse parallel störungsfrei zu handhaben, dann weg mit X. Wenn nicht, kann X solange bleiben, bis die Ohren melden, dass es die audiophile Qualität beeinträchtigt. Und das ist dann wieder eine Einzelfallentscheidung. Also wie immer: ausprobieren.

Gruß

Jochen

[1] Jetzt sage niemand, dass es sowas heute nicht mehr gibt. ;)

Verfasst: 14.05.2015, 14:46
von Tinitus
Hallo,

ich finde es gut, dass es hier inzwischen mehrere Threads zum Thema Computer und Musik gibt die als Basis Linux haben. Ich bin in der Materie immer noch das, was die Franzosen einen idiot savant nennen, einer der nachäfft aber noch nicht so tief in der Materie steckt, um selbst kreativ zu werden. Ich bin auch inzwischen mehrmals mit dem Kopf gegen die wand gerannt und komme nicht weiter, das liegt zum Teil daran, dass die Zeit , die mir zur Verfügung steht, endlich ist und mein Hauptaugenmerk Musik Hören ist und nicht die Basteleien drum herum. Wie dann jeder mit Linux glücklich wird, muss er selbst entscheiden. Ich bin jemand der eher Jochen zustimmt und alles gerne headless macht. Aus eigener Erfahrung weiß ich aber auch, wie zeitaufwändig eine Dokumentation ist, wie Heinz sie hier eingestellt hat. Ob man sie nun eins zu eins kopiert oder sich von Teilen inspirieren läßt ist dabei nebensächlich. Wie sagt ein netter Forenkollege:

Möge es nutzen

Gruß

und weiterhin allen viel Spaß mit Linux Experimenten

Uwe

Verfasst: 14.05.2015, 19:01
von Eunegis
Hallo Tinnitus und Linux Aficionados,

schön daß Du, Uwe, frohen Mutes Deinen Linuxstand kundtust. So gehts mir auch. Jedes Mal, wenn die Linux-Diskussion hochkommt, lese ich neugierigst mit nur um festzustellen, wie unendlich weit ich weg bin von der Weisheit der Experten. Nicht, daß mir das bei anderen Themen nicht auch so ginge, aber Linux ist für den DIYer prinzipiell sehr anziehend, aber es ist auch ein Abgrund, den man als arbeitender Familienvater schon rein zeitlich kaum ergründen kann. Da geht ja Boxenbauen noch einfacher.

Wie auch immer, habt Ihr Kenntnis vom Projekt "Audiophile Linux"?:

http://www.ap-linux.com/

Wenn ja, warum habt Ihr Euch dagegen und für etwas anderes entschieden?

Gruß,
Jens

Verfasst: 14.05.2015, 22:12
von Daihedz
Hallo Jens
Eunegis hat geschrieben:...Wie auch immer, habt Ihr Kenntnis vom Projekt "Audiophile Linux"? ... Wenn ja, warum habt Ihr Euch dagegen und für etwas anderes entschieden?
Dass ich aktuell mit Fedora unterwegs bin, ist idiotisch-historisch-zufällig begründet: Fedora war damals diejenige Distribution, deren Installation bei mir ohne Hänger glatt durchlief und für mich einigermassen intuitiv nachvollziehbar war. Was mir an Fedora für Audio-Zwecke jedoch nicht besonders gefällt, ist der Umstand, dass Fedora schon in der Minimal-Install-Variante zu fett daherkommt. Z.B. ist Pulseaudio bereits dabei (Soviel ich weiss, arbeitet der Entwickler von Pulseaudio bei Fedora mit...). Und mir sind auch die Paketabhängigkeiten allzu verflochten: Wenn man z.B. bei einem Fedora mit Desktop (KDE oder Gnome) versucht, Pulseaudio per yum erase loszuwerden, dann ist man in der Regel den Desktop auch gleich los ... Deshalb bin ich noch so bereit, für blosse Audio-Zwecke Fedora zugunsten von etwas anderem zu verlassen.
frankl hat geschrieben: ... Ich selbst starte lieber von einer schlanken Installation wie voyage oder archlinux und installiere nach, was mir fehlt, als von einer "dicken" Installation Pakete zu löschen oder Services zu stoppen. ...
Genau so. Audiophile Linux kommt nach meinem Gusto bereits zu fett daher. Zu viel Bells and Whistles.

Wäre dieser Thread denn eine Gelegenheit, gemeinsam mit anderen Mistreitern ein Forums-Minimal-Audio-Linux zu kreieren? Welches darüber hinaus einigermassen Anfänger-tauglich wäre?

Ich stelle mir eine minimale Basis-Linux-Installation vor. Am liebsten auf der Arch-Distribution aufbauend, und zunächst nur mit den für Audio notwendigsten, wenigen Prozessen, quasi Alsa und sonst gar nichts. Darauf aufbauend und baumförmig erweiterbar einige Programme und Funktionalitäten (z.B. Audio-Programme à la sox, playhrt etc, oder ein x-server für die darauf aufsetzenden Player, oder Netzwerk-Funktionalitäten, oder andere Erweiterungen. Alle Erweiterungen würden mit einzelnen, kleinen bash-scripten nachinstalliert, welche mit entsprechenden Kommentaren selbsterklärend sein müssten. Andere Scripts würden der Konfiguration des Systems dienen. Die sich aus dem Entwicklungs-Prozess ergebende Script-Sammlung würde in Abhängigkeit des Forums-Feedbacks laufend korrigiert und aktualisiert werden müssen.

Mit einem solchen Satz Scripts könnte man relativ einfach verschiedene Bausätze bereitstellen, welche zu out-of-the-box funktionalen Systemen unterschiedlicher Funktionalität führen könnten: Ein "Bausatz" wäre ganz einfach ein Bausatz-Script, welches in Folge verschiedene Basis-Scripts aufrufen würde.

Diese Gedanken sind für mich sicherlich schon mal ein Grund, die Arch-Distribution näher anzuschauen.

Beste Grüsse
Simon