Wie gut ist Sidux?

[nowhiskey]

soweit mir das bekannt ist, ist neuerdings die datei /etc/security/limits.d/audio.conf zuständig.
sollte bei jackd installation erzeugt werden und das war hier auch der fall. beim sidux2010-01.
die performance von dem normalen sidux kernel ist für rt-audio sachen hier auch sehr schlecht...xruns und so...aber der rt-kernel von horo ist monster gut für mich!

gruss,
doc

[autoandimat]

soweit mir das bekannt ist, ist neuerdings die datei /etc/security/limits.d/audio.conf zuständig.

Tatsächlich, das wusste ich gar nicht. Ich hab gerade mal nachgeschaut. Die sieht bei mir so aus:

Code: Alles auswählen

@audio   -  rtprio     95
@audio   -  memlock    unlimited
#@audio   -  nice      -19

Ich habe den Kernel 2.6.32-2.slh.4-sidux-686. Der ist nicht ganz aktuell, läuft aber super.
Warum ändern die schon wieder so gravierende Sachen? Wenn es vorher endlich mit nem Standard-Kernel lief und jetzt plötzlich nicht mehr ist das ja schon wieder ein (von mir gefühlt wahrgenommener) Rückschritt.

[horo]

Hi,

schön, dass mein rt-kernel ordentlich läuft - das ist der Vanilla mit dem rt-patch, .config ist als "make oldconfig" aus dem slh-kernel entstanden.
Es dauert wohl noch ein wenig bis zur nächsten Version - habe von Thomas Gleixner auf dem LinuxTag erfahren, dass 2.6.34.x ausgelassen wird, der nächste wird dann 2.6.35.x-rt werden.

Ciao Martin

[Mitsch]

Hey!

Danke für die vielen Antworten! Ihr wart richtig schnell - ich dagegen bin erst jetzt dazu gekommen, Eure Tips auszuprobieren.

Horo's Kernel ist bestimmt klasse - dummerweise kann ich ihn nicht installieren, weil ich auf 64bit setze. Ich habe aber mal das Repository von pengutronix installiert. bis jetzt nichts brauchbares gefunden... Jemand 'nen guten Tip?

Grüße!

[autoandimat]

hmmm, 64bit hab ich auf Linux bisher nicht probiert.
Ich hab den Kernel von horo mal auf AV-Linux getestet. Sicherlich ist das nicht allgemein zur Nachahmung empfohlen da die Basis ja Squezze ist. Dennoch läuft der einwandfrei sauber durch und hat im Test sogar weniger Xruns als der mitgelieferte rt-Kernel von AV-Linux.
Sidux 1-1010 hab ich mal gerade frisch neu installiert. Ich hatte lange Zeit Dist-Upgrades verpasst so dass ne Fresh-Install einfacher war. Der slh-Kernel hat aber auch hier zumindest im ersten Testlauf durchaus eine ordenliche Performance.
Ich überlege gerade warum das bei dir so gar nicht ging. Hast du von vorn herein auf 64bit getestet? Ansonsten müsste es ja schon fast die Hardware sein.
Sicherlich ist ein rt-Kernel besser aber so wie deine Erfahrungen mit dem Standard-Kernel sind hab ich das hier bei weitem nicht gehabt. Ich stelle mir gerade wirklich die Frage ob es am 64bit liegt.
Hat das einen bestimmten Grund warum du 64bit bevorzugst? Wenn man dort derzeit noch Einschränkungen hat wäre es ja vielleicht doch ne Idee erstmal zweigleisig zu fahren.

[Mitsch]

Ich glaube, ich habe die Wurzel des Problems entdeckt: jackd weißt nebensächlich mal so darauf hin, dass das mit der Realtime-Priorität aufgrund mangelnder Rechte nicht funktioniert... Gebe morgen mal den genauen Wortlaut wieder - sitze gerade nicht an meiner Multimedia-Maschine... Komisch allerdings: Ich bin bereits in Gruppe "audio". Wo soll ich den sonst noch dazugehören?!?

Grüße!
Mitsch

[autoandimat]

Ich wollte es wissen und habe heute mal eine sidux 1-2010 64-bit installiert. Hier habe ich auch Rechteprobleme mit Realtime-Priorität.

Ich versuchte dann auch mal einen “Handstart”:

Code: Alles auswählen

/usr/bin/jackd -R -dalsa -dhw:0 -r48000 -p128 -n2

Das brachte folgende Ausgabe:

Code: Alles auswählen

JACK is running in realtime mode, but you are not allowed to use realtime scheduling.
After applying these changes, please re-login in order for them to take effect.
You don't appear to have a sane system configuration. It is very likely that you
encounter xruns. Please apply all the above mentioned changes and start jack again!

Die Systemkonfiguration ist aber völlig identisch mit meiner sidux 32-bit-Install auf der alles einwandfrei mit rt-Prio läuft. Eine Erklärung dafür habe ich nicht. Sicherlich kann man das bestimmt lösen – aber das übersteigt meinen Linux-Horizont bei weitem.

Ich will dich nicht überreden 32-bit zu nehmen. Du kannst es ja vorübergehend (um zumindest erstmal arbeiten zu können) auf ner Nebenpartition testen, solange bis jemand eine Lösung hat.

[nowhiskey]

...
ist bei euch libpam instaliert?
ich meine, bei 32bit ist die per defalut instaliert und damit läuft das ganze, oder?

gruss,
doc

[Mitsch]

Hey!

Nochmal vielen Dank für Euren Einsatz!
libpam ist installiert. Allerdings "nur" 4 Pakete, namens libpam-gnome-keyring, libpam-modules, libpam-runtime und libpam0g. So, wie es aussieht, gibt es etliche Module und da weiß ich jetzt nicht genau, welche für jackd installiert sein müssten...

Der genaue Wortlaut der Fehlermeldung: "cannot use real-time scheduling (FIFO at priority 99) [for thread 1604200208, from thread 1604200208] (1: Operation not permitted)"

Meldungen von jack (komplett):

Code: Alles auswählen

20:42:03.159 /usr/bin/jackd -P89 -p512 -u -dalsa -dhw:0 -r48000 -p128 -n2 -zt -H -M
jackd 0.118.0
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
Enhanced3DNow! detected
SSE2 detected
apparent rate = 48000
creating alsa driver ... hw:0|hw:0|128|2|48000|0|0|hwmon|hwmeter|-|32bit
control device hw:0
configuring for 48000Hz, period = 128 frames (2.7 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
cannot use real-time scheduling (FIFO at priority 99) [for thread 1604200208, from thread 1604200208] (1: Operation not permitted)
20:42:03.323 JACK wurde mit PID = 14946 gestartet.
20:42:05.601 Serverkonfiguration nach "/home/mitsch/.jackdrc" gespeichert.
20:42:05.606 Statistik zurückgesetzt.
20:42:06.305 Client aktiviert
20:42:06.316 JACK-Verbindung geändert.
20:42:06.323 Schaubild der JACK-Verbindungen geändert.
Enhanced3DNow! detected
SSE2 detected
20:42:06.736 XRUN callback (1)...

Auf 32bit will ich eigentlich nicht runter. Die Maschine läuft seitdem ich sie habe (sehr gut) mit 64bit. Und Phoronix hat in Benchmarks bewiesen, dass 64bit in für Multimedia relevanten Bereichen (lame-encoding, gzip-compression) Vorteile bringt. Ich habe prinzipiell auch nichts dagegen, in dem (von der Sidux-Audio-Community anscheinend selten genutzten) Bereich einen auf Tester zu machen. Nur: Funktionieren sollte es hat schon am Ende... Nochmal speziellen Dank an Autoandimat - da Du die 32- und 64bit-Versionen direkt verglichen hast, kann ich mal beruhigt einen Bugreport verfassen.

Nehme natürlich trotzdem gerne weitere Hinweise entgegen...
Grüße!

[Mitsch]

Hi!

Habe mal einfach "cannot use real-time scheduling" in Google eingetippt. Die meisten Ergebnisse handeln von fehlenden Einträgen in der /etc/security/limits.conf (die ja nun in /etc/security/limits.d/audio.conf eingetragen werden sollen - was bei mir der Fall ist!) und von Leuten, die vergessen haben, sich zur Gruppe "audio" hinzuzufügen. Ein Beitrag aus einem Forum befasst sich allerdings mit der Rechtevergabe in /dev: http://ubuntuforums.org/showthread.php?t=453486

Einer hat das Problem mit der fehlenden Echtzeit-Priorität nämlich so gelöst:

Code: Alles auswählen

$ sudo mkdir -p /dev/shm/jack-1000/default
$ sudo chmod -R 777 /dev/shm/jack-1000

Ich weiß zwar nicht, wie das zusammenhängt, aber kann jemand mit 32bit-System mal schauen, ob das Verzeichnis "/dev/shm/jack-1000" angelegt wurde (oder vielleicht erst nach dem Starten von jackd angelegt wird?) und wie es mit Benutzern, Gruppen und Zugriffsbits des Verzeichnis' und dessen Inhalt aussieht?

Code: Alles auswählen

ls -l /dev/shm/jack*
ls -ld /dev/shm/jack*

Grüße!

[Mitsch]

O.k. - habe das, was ich einen Beitrag weiter oben hingeschrieben habe, mal selbst ausgecheckt:
jackd (oder wer auch immer) legt beim Starten das Verzeichnis /dev/shm/jack-1000 an. Die Rechte sehen aber sehr eindeutig aus:

Code: Alles auswählen

mitsch@mmmaschine:~$ ls -dl /dev/shm/jack-1000/
drwx------ 3 mitsch mitsch 60 13. Jul 10:27 /dev/shm/jack-1000/

Code: Alles auswählen

mitsch@mmmaschine:~$ ls -l /dev/shm/jack-1000/
insgesamt 0
drwx------ 2 mitsch mitsch 140 13. Jul 10:27 default

Code: Alles auswählen

mitsch@mmmaschine:~$ ls -l /dev/shm/jack-1000/default/
insgesamt 0
srwxr-xr-x 1 mitsch mitsch 0 13. Jul 10:27 jack_0
srwxr-xr-x 1 mitsch mitsch 0 13. Jul 10:27 jack_ack_0
prw-r--r-- 1 mitsch mitsch 0 13. Jul 10:28 jack-ack-fifo-3116-0
prw-r--r-- 1 mitsch mitsch 0 13. Jul 10:28 jack-ack-fifo-3116-1
prw-r--r-- 1 mitsch mitsch 0 13. Jul 10:27 jack-ack-fifo-3116-2

Dummerweise ist also alles so, wie es sein soll... Oder? Was mich jetzt ein klein wenig überrascht, ist, dass die Gruppe "mitsch" keinerlei Rechte in den Verzeichnissen /dev/shm/jack-1000 und /dev/shm/jack-1000/default hat. Und wieso überhaupt Gruppe "mitsch" - müsste das nicht Gruppe "audio" sein, damit die Einstellungen in /etc/security/limits.d/audio.conf auch wirken?
Kann jemand das mal auf 'nem 32bit-System gegenchecken?

Grüße!

[horo]

Hi Mitsch,

gleicher Versuch auf 'nem PIII/600MHz Thinkpad A20m:

Code: Alles auswählen

$ uname -a
Linux book 2.6.33.5-rt23 #1 SMP PREEMPT RT Wed Jun 9 21:37:27 CEST 2010 i686 GNU/Linux

Code: Alles auswählen

$ /usr/bin/jackd -P79 -u -dalsa -dhw:0,0 -r48000 -p256 -n3 -Xseq
jackd 0.118.0
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

JACK compiled with System V SHM support.
loading driver ..
apparent rate = 48000
creating alsa driver ... hw:0,0|hw:0,0|256|3|48000|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 48000Hz, period = 256 frames (5.3 ms), buffer = 3 periods
ALSA: final selected sample format for capture: 16bit little-endian
ALSA: use 3 periods for capture
ALSA: final selected sample format for playback: 16bit little-endian
ALSA: use 3 periods for playback

Code: Alles auswählen

# ls -dl /dev/shm/jack-1000/
drwx------ 3 horo horo 60 13. Jul 11:24 /dev/shm/jack-1000/

Code: Alles auswählen

# ls -l /dev/shm/jack-1000/
insgesamt 0
drwx------ 2 horo horo 120 13. Jul 11:24 default

Code: Alles auswählen

# ls -l /dev/shm/jack-1000/default
insgesamt 0
srwxr-xr-x 1 horo horo 0 13. Jul 11:24 jack_0
srwxr-xr-x 1 horo horo 0 13. Jul 11:24 jack_ack_0
prw-r--r-- 1 horo horo 0 13. Jul 11:24 jack-ack-fifo-2228-0
prw-r--r-- 1 horo horo 0 13. Jul 11:24 jack-ack-fifo-2228-1

Ciao Martin

P.S.: Hab's eben mal mit Deinen Aufrufparametern gestartet:

Code: Alles auswählen

$ /usr/bin/jackd -P89 -p512 -u -dalsa -dhw:0 -r48000 -p128 -n2 -zt -H -M
jackd 0.118.0
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

JACK compiled with System V SHM support.
loading driver ..
apparent rate = 48000
creating alsa driver ... hw:0|hw:0|128|2|48000|0|0|hwmon|hwmeter|-|32bit
control device hw:0
configuring for 48000Hz, period = 128 frames (2.7 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 16bit little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 16bit little-endian
ALSA: use 2 periods for playback
Triangular dithering at 16 bits
cannot use real-time scheduling (FIFO at priority 99) [for thread -1237390480, from thread -1237390480] (1: Operation not permitted)

Das beißt sich mit meinem Eintrag "@audio - rtprio 95", denn jackd legt einen um 10 höher priorisierten FIFO-thread an: -P89 -> 99.

Code: Alles auswählen

$ cat /etc/security/limits.d/audio.conf
# Provided by the jackd package.
#
# Changes to this file will be preserved.
#
# If you want to enable/disable realtime permissions, run
#
#    dpkg-reconfigure -p high jackd

@audio   -  rtprio     95
@audio   -  memlock    182412
#@audio   -  nice      -19

Ich kann mich dunkel erinnern, dass auf LAD (Paul Davis ?) von zu hohen Prioritäten abgeraten wurde, da man sich so sein System im Fehlerfall einfriert.

[Mitsch]

Das beißt sich mit meinem Eintrag "@audio - rtprio 95"!

O.k. - was muss ich dann eintragen, damit ich jackd auch mit den maximalen 89 laufen lassen kann? Ich dachte erst rtprio 99 - aber das scheint nicht zu gehen. Derzeit läuft jack ohne zu meckern (aber bei 5ms immer noch mit massig xruns) auf 85. Ich probiere aber auch mal nen anderen Kernel...

Grüße!

[Mitsch]

Anderen Kernel ausgetestet (pengutronix 2.6.33-rt19). jackd meckert zwar nicht mehr über fehlende Echtzeit-Priorität, aber wirklich besser laufen tut das nicht: Es reicht selbst bei 10ms eine Mausbewegung, damit die xruns ausgelöst werden...
Dabei benutzt meine Soundkarte (hdsp) ganz alleine den Interrupt 17:

Code: Alles auswählen

mitsch@mmmaschine:~/Desktop$ cat /proc/interrupts 
            CPU0       CPU1       
   0:         61          0   IO-APIC-edge      timer
   1:        955         75   IO-APIC-edge      i8042
   7:          1          0   IO-APIC-edge    
   8:          0          0   IO-APIC-edge      rtc0
   9:          0          0   IO-APIC-fasteoi   acpi
  12:          0          4   IO-APIC-edge      i8042
  14:       4606         61   IO-APIC-edge      ide0
  15:          0          0   IO-APIC-edge      ide1
  17:         12      53508   IO-APIC-fasteoi   hdsp
  18:          7         54   IO-APIC-fasteoi   firewire_ohci, DC30plus[0]
  19:        824        183   IO-APIC-fasteoi   ath9k, eth0
  20:          0          0   IO-APIC-fasteoi   sata_nv
  21:       8128       3020   IO-APIC-fasteoi   ohci_hcd:usb2
  22:       4432       3063   IO-APIC-fasteoi   sata_nv
  23:      26345        336   IO-APIC-fasteoi   ehci_hcd:usb1, NVidia CK804
  28:          0         18   PCI-MSI-edge      hda_intel
 NMI:          0          0   Non-maskable interrupts
 LOC:     112008     104721   Local timer interrupts
 SPU:          0          0   Spurious interrupts
 PMI:          0          0   Performance monitoring interrupts
 PND:          0          0   Performance pending work
 RES:     199441     194177   Rescheduling interrupts
 CAL:         24         28   Function call interrupts
 TLB:        653        717   TLB shootdowns
 TRM:          0          0   Thermal event interrupts
 THR:          0          0   Threshold APIC interrupts
 MCE:          0          0   Machine check exceptions
 MCP:          2          2   Machine check polls
 ERR:          1
 MIS:          0

An welchen Schräubchen kann man denn jetzt noch drehen?
Ich probiere auch mal 'nen anderen Kernel!

Übrigens: Ich habe einen sehr ähnlichen Laptop, 'nen Thinkpad A20p mit Crystal-Soundkarte. Der läuft Realtime aber auch nicht soooo toll - wobei ich das aber auf den Soundkarten-Treiber geschoben habe. Läuft Dein Laptop gut, Horo?

Grüße! Und danke für Eure Mühen!

[nowhiskey]

tag,
bei mir ist die prio eintellung im qjack bei 79.

gruss,
doc

p.s. ich selber habe nur die libpam0g installiert und es läuft.