KDE SC 4.5.1, Conky, Kopete und Clementine

Beim Verfassen des vergangenen Posts habe ich mich immer wieder versucht, zu erinnern, wie das früher so mit ALSA & Co. lief; dabei viel mir meine gute, alte Creative Soundblaster Audigy 2 Platinum ein, die irgendwo im Keller in der Hardwarekiste vor sich hin gammelte. “Moment, die war doch hardwaremixing-fähig…” – kurz Google befragt und bestätigt.

Problem bei der Audigy (und Grund für das Triste Dasein in der Kiste) war, dass das zugehörige Output-Rack für die Front bei Einbau in einen 5,25″-Schacht aufgrund der herausstehenden Regler das Schließen meiner Gehäusetür verhindern würde. Ohne Rack hätte es jedoch keinen Kopfhörer- und Mikro-Ausgang vorne am Gehäuse gegeben. Zumindest nicht so ohne Weiteres, was ich damals noch nicht wusste…

Nach ein par Google-Orgien fand ich diverse HowTos (z.B. hier oder hier), wie man an einen internen, 10-poligen Anschluss auf der Karte ein AC’97- bzw. HD-Audio Frontpanel anschließen kann. Nun ist dieser Anschluss leider bei der Audigy 2 (ohne “ZS”) leider nicht bestückt – also Arbeit für den Lötkolben. Mit ein paar Zentimetern altem Telefonkabel konnte ich die benötigten Pins (1, 2, 4, 6, 8) schließlich emulieren und mithilfe einer kurzerhand umfunktionierten USB-Buchse an mein Frontpanel anschließen. Hierbei noch ein Tip: Wer Pin 1 (HP-Masse) nicht festgelötet bekommt, kann sich die Masse auch einfach vom Slotblech holen, verursacht keine Störgeräusche.

Also dann im BIOS die onboard-Karte deaktiviert, System gebootet und noch flux das emu10k1-Modul gebacken – fertig. Sound läuft direkt über ALSA mit parallelem Zugriff, 5.1 mit 48000Hz, out-of-the-box. Kein Soundserver, keine /etc/asound.conf, keine ~/.asoundrc – so einfach und elegant kann Sound unter Linux auch sein, die richtige Karte vorausgesetzt. Leider haben selbst die etwas besseren (=teureren) aktuellen Karten kaum noch Hardwaremixer.

Upmixing für Stereo-Signale erreiche ich mit den folgenden paar Zeilen:

# /etc/asound.conf
 
pcm.ch51dup {
    type plug
    slave.pcm "surround51"
    slave.channels 6
    route_policy duplicate
}

Früher waren also zumindest die Soundkarten besser

Hardware: SupremeFX X-Fi* Soundkarte, analoges Logitech 5.1 System

Ich wusste, dass meine Karte nicht hardwaremixing-fähig ist, also war dmix die erste Anlaufstelle. Laut Arch-Wiki ist dmix allerdings ab ALSA 1.0.9rc2 automatisch aktiv, also habe ich da nicht weiter gedreht und nach Alternativen gesucht.

OSS4 ist die Neuimplementierung des alten Unix Standard-Audiosystems, und erfreulicherweise vollständig kompatibel, d.h. ich hätte keine Anwendungen patchen müssen – also erste Wahl.
Die Installation lief problemlos (vgl. Wiki), allerdings wird meine tolle Soundkarte noch nicht offiziell unterstützt und ich bekam nur Stereo-Output, mit dem Kopfhörerausgang als primärem Ausgabemodul.

Nachdem die beiden existierenden direkten Hardware ansprechenden Möglichkeiten ausgeschöpft waren also ran an die Soundserver – allen voran PulseAudio als prominentestem Vertreter. Auch hier lief die Installation reibungslos; nach ein paar Eingriffen in die Configs gem. Wiki hatte ich ein statisches 5.1 Setup mit 48000Hz und Upsampling. Problem hierbei: ein penetrantes Kratzen im hochfrequenten Bereich, das alle Stimmen extrem blechern wirken ließ, neben einem viel zu schwachen Subwoofer-Kanal. Hat mich an meine Windows-Zeit erinnert, als ich mit einer Audigy 2 und denselben Boxen mal die Bass-Umleitung aktiviert hatte. Hierfür habe ich keine Lösung gefunden, also nächster Versuch.

JACK war meine letzte Idee, und ebenfalls schnell aufgesetzt (de facto war hier eigentlich nichts aufzusetzen, da bereits installiert – musste nur gestartet werden). Problem mit JACK war mal wieder das Multiplexing, bei parallelen Zugriffen bekam der zweite Client Device or Ressource busy.

Etwas genervt von der Rumprobiererei galt der letzte Blick wieder dmix, und siehe da: ein manuell per /etc/asound.conf eingebundenes dmix ermöglicht nun mplayer und flash-Audio parallel – ganz ohne Soundserver

# /etc/asound.conf:
pcm.!default {
    type plug
    slave.pcm "dmixer"
}
 
pcm.dsp0 {
    type plug
    slave.pcm "dmixer"
        hint {
         show on
         description "dmix dsp0"
    }
}
 
pcm.dmixer {
    type dmix
    ipc_key 1024
    slave {
        pcm "hw:0,0"
        period_time 0
        period_size 1024
        buffer_size 8192
        rate 48000
    }
}
 
ctl.dmixer {
    type hw
    card 0
}

Genervt hat übrigens die ganze Zeit über auch knotify4, dass ständig alle möglichen devices blockierte und des Öfteren mit SEGFAULT abstürzte. Hier warte ich gespannt auf KDE 4.5, wo selbiges komplett überholt sein soll.

* Ein von ASUS groß als X-Fi mit EAX4 beworbenes Müll-Teil, was eigentlich einen ganz anderen Chip besitzt und sich nur ähnlich einer X-Fi verhält. Wird von so gut wie keinem Spiel als EAX-fähig erkannt und sorgt bei unzähligen Usern für Probleme, siehe Foren.

Alle aquaero®-Besitzer seien also herzlich eingeladen, die neue Version zu testen! Bugreports sind immer willkommen, am Besten über die “Issues”-Funktion auf Github.

egrep: Unmatched ) or \)

Toll: weder Regelsatz noch Zeilennummer werden genannt, also manuell suchen. Da es sich aber meist um umfangreiche Regelsätze handelt und ich (selbst bei gefundenem Satz) keine Möglichkeit gefunden habe, egrep die Zeilennummer des ungültigen Ausdrucks zu entlocken, entstand auf die Schnelle folgendes simples Script:

#!/bin/bash
 
if [ $# -ne 1 ]; then
    echo "usage: $0 RULES_FILE"
    exit 1
fi
 
if ! [ -r "$1" ]; then
    echo "unable to read $1"
    exit 1
fi
 
LINES=$(wc -l "$1" | cut -d ' ' -f 1)
 
for I in $(seq $LINES); do
    echo "line $I..."
    echo "foo" | egrep "$(cat "$1" | head -n $I | tail -n 1)"
done
 
exit 0

Es gibt bestimmt auch irgendeine elegantere Lösung, aber vielleicht erspart es ja jemandem die nervige Sucherei

Firefox vs. Chromium

Kurios bei der Ausführung: Chromium cheatet  Beim Rendering-Test Stufe 1 mit den Kugeln sollen selbige nicht nur an den “Wänden”, sondern auch gegenseitig abprallen, was Firefox korrekt umsetzt. Chromium hingegen scheint sich die Kollisionsabfrage der Kugeln untereinander zu sparen und lässt sie tunneln:

Tunneleffekt

Ich schließe mal böse Absicht aus; wer die gegebenen JavaScript-Algorithmen jetzt korrekt umsetzt und damit “Recht” hat, bleibt zu klären

Update: Hier der Link zum Eintrag im Bugtracker

Trotz Wasserkühlung knackte mein Exemplar so nicht selten die 70°C – Marke, was mir im Hinblick auf den Sommer einige Sorgen bereitete. Zugegeben, mein System hat in Punkto Kühlungsdesign zwei entscheidende Defizite: 1.) Im Kreislauf hängt neben CPU auch eine GTX 280 als GraKa, die nicht unerheblich zur Hitze beiträgt. 2.) Der Rechner steht eingekeilt zwischen Schreibtisch-Seitenteil, Schrank und Tischplatte, sodass nur nach vorne Luft zu- und wegströmen kann.

Das alles veranlasste mich kürzlich zu einem konkreten Benchmark mit linpack:

Intel(R) LINPACK data
 
Current date/time: Fri May  7 19:49:37 2010
 
CPU frequency:    3.610 GHz
Number of CPUs: 8
Number of threads: 8
 
Parameters are set to:
 
Number of tests                             : 1
Number of equations to solve (problem size) : 21000
Leading dimension of array                  : 21000
Number of trials to run                     : 100  
Data alignment value (in Kbytes)            : 4    
 
Maximum memory requested that can be used = 3528424096, at the size = 21000
 
============= Timing linear equation system solver =================
 
Size   LDA    Align. Time(s)    GFlops   Residual     Residual(norm)
21000  21000  4      252.846    24.4215  3.959026e-10 3.178913e-02
21000  21000  4      252.587    24.4466  3.959026e-10 3.178913e-02
21000  21000  4      252.602    24.4451  3.959026e-10 3.178913e-02
21000  21000  4      252.614    24.4439  3.959026e-10 3.178913e-02
21000  21000  4      252.531    24.4520  3.959026e-10 3.178913e-02
21000  21000  4      252.550    24.4501  3.959026e-10 3.178913e-02
21000  21000  4      252.500    24.4549  3.959026e-10 3.178913e-02
21000  21000  4      252.466    24.4583  3.959026e-10 3.178913e-02
21000  21000  4      252.481    24.4568  3.959026e-10 3.178913e-02
21000  21000  4      252.489    24.4560  3.959026e-10 3.178913e-02
21000  21000  4      252.467    24.4582  3.959026e-10 3.178913e-02
21000  21000  4      252.475    24.4574  3.959026e-10 3.178913e-02
21000  21000  4      252.482    24.4567  3.959026e-10 3.178913e-02
21000  21000  4      252.477    24.4573  3.959026e-10 3.178913e-02

Intel(R) LINPACK data
 
Current date/time: Mon May 10 20:33:50 2010
 
CPU frequency:    2.670 GHz
Number of CPUs: 8
Number of threads: 8
 
Parameters are set to:
 
Number of tests                             : 1
Number of equations to solve (problem size) : 21000
Leading dimension of array                  : 21000
Number of trials to run                     : 100  
Data alignment value (in Kbytes)            : 4    
 
Maximum memory requested that can be used = 3528424096, at the size = 21000
 
============= Timing linear equation system solver =================
 
Size   LDA    Align. Time(s)    GFlops   Residual     Residual(norm)
21000  21000  4      342.691    18.0188  3.959026e-10 3.178913e-02
21000  21000  4      342.756    18.0154  3.959026e-10 3.178913e-02
21000  21000  4      342.765    18.0149  3.959026e-10 3.178913e-02
21000  21000  4      342.770    18.0146  3.959026e-10 3.178913e-02

Summa summarum also ~25% Performance-Einbuße, genau der linearer Weise erwartete Wert. Nun zu den Auswirkungen auf die Temperaturen:

Alle Werte außer “CPU Last” beziehen sich auf eine Uptime von ca. 4h bei normalem Office-Workload und einer Raumtemperatur von ca. 23°C.

Fazit: 25% weniger (theoretische) CPU-Performance für 30% bessere Temperaturwerte – für den Sommer ein wie ich finde fairer Tausch. Zumal bei den einzigen wirklich Rechenintensiven Anwendungen (Games!) hauptsächlich GPU und weniger CPU belastet wird.

Hier noch die relevanten Settings für beide Modi:

Die *-Werte werden noch nachgeliefert. Am VCore könnte man sicher noch etwas Undervolting betreiben, hier heißt das Ziel <1.0V

<bash-addicted>Yep, eindeutige Notwenigkeit für ein selbst gehämmertes, kommentierbares  Script!</bash-addicted> Wie in guten alten Debian-Zeiten übernimmt jetzt also bei mir ein einfaches, aber für den Job völlig ausreichendes init-script den Job. Wer es verwenden mag:

#!/bin/bash
 
#
#   easy-to-edit iptables init script for Arch
#           2010 by Alexander Koch
#
 
 
# TCP services: ssh
SERVICES_TCP=( 22 )
# UDP services:
SERVICES_UDP=( )
 
. /etc/rc.conf
. /etc/rc.d/functions
 
if [ -e "/etc/conf.d/iptables" ]; then
    . /etc/conf.d/iptables
fi
if [ -z "$IPTABLES" ]; then
    IPTABLES="/usr/sbin/iptables"
fi
if ! [ -x "$IPTABLES" ]; then
    echo "unable to execute iptables binary: $IPTABLES"
    exit 1
fi
 
function reset_tables() {
    ERR=0
    $IPTABLES -F || ERR=1
    $IPTABLES -X || ERR=1
    $IPTABLES -P INPUT ACCEPT || ERR=1
    $IPTABLES -P OUTPUT ACCEPT || ERR=1
    if [ $IPTABLES_FORWARD -eq 1 ]; then
        $IPTABLES -P FORWARD ACCEPT || ERR=1
        echo 1 >/proc/sys/net/ipv4/ip_forward || ERR=1
    else
        $IPTABLES -P FORWARD DROP || ERR=1
        echo 0 >/proc/sys/net/ipv4/ip_forward || ERR=1
    fi
 
    return $ERR
}
 
function setup_tables() {
    ERR=0
 
    # setup prevention chain against common attacks
    $IPTABLES -N preventions || ERR=1
    $IPTABLES -A preventions -f -j DROP || ERR=1                           # frags
    $IPTABLES -A preventions -p tcp --tcp-flags ALL ALL -j DROP || ERR=1   # XMAS
    $IPTABLES -A preventions -p tcp --tcp-flags ALL NONE -j DROP || ERR=1  # null
 
    # setup services chain
    $IPTABLES -N services || ERR=1
    for PORT in ${SERVICES_TCP[@]}; do
        $IPTABLES -A services -p tcp --dport $PORT -j ACCEPT || ERR=1
    done
    for PORT in ${SERVICES_UDP[@]}; do
        $IPTABLES -A services -p udp --dport $PORT -j ACCEPT || ERR=1
    done
 
    # allow incoming ping requests
    iptables -A services -p icmp --icmp-type echo-request -j ACCEPT || ERR=1
 
    # setup main chains
    $IPTABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT || ERR=1
    $IPTABLES -A INPUT -i lo -j ACCEPT || ERR=1
    $IPTABLES -A INPUT -j preventions || ERR=1
    $IPTABLES -A INPUT -m state --state NEW -j services || ERR=1
    $IPTABLES -A INPUT -p tcp -j REJECT --reject-with tcp-reset || ERR=1
    $IPTABLES -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable || ERR=1
    $IPTABLES -P INPUT DROP || ERR=1
 
    return $ERR
}
 
case "$1" in
    start)
        stat_busy "Loading IP Tables"
        reset_tables
        if ! setup_tables; then
            stat_fail
            exit 1
        else
            add_daemon miptables
            stat_done
        fi
        ;;
    stop)
        stat_busy "Flushing IP Tables"
        if reset_tables; then
            rm_daemon miptables
            stat_done
        else
            stat_fail
            exit 1
        fi
        ;;
    restart)
        if ! ck_daemon miptables; then
            rm_daemon miptables
        fi
        $0 start
        exit $?
        ;;
    *)
        echo "usage: $0 {start|stop|restart}"
        ;;
esac
 
exit 0

Gefiltert werden nur eingehende Pakete; related und established Pakete werden ebenfalls ohne weitere Beachtung durchgelassen, ebenso alles über loopback. Für neue Pakete werden zuerst ein paar Vulnerability-Checks durchgeführt. Nach Außen wird ein Verhalten wie ohne iptables emuliert (z.B. REJECTs mit tcp-reset).

Bugreports wie immer willkommen, und Benutzung auf eigene Gefahr!

Update 31.07.10: Bugfixed

XFCE mit AWN statt xfce4-panel