[audio4linux]

Folgendes Setup:
- Laptop: HP nx7400 mit Intel Core Solo 1,66 GHz und 1GB Ram
- Interface: RME Mutiface I
- System: Ubuntu 7.10 mit Kernel 2.6.22-14-rt, XFCE als Desktop
- ALSA 1.0.14
- Jack 0.103.0
- die üblichen Tweaks (limits.conf, rt-clock)

Habe bis jetzt die Latenz zwecks Stabilität immer auf Maximum gehabt (4096 Samples) - Aufnahme und Wiedergabe ist kein Problem. Allerdings habe ich jetzt mal niedrigere Pufferwerte getestet, und schon sah es nicht mehr so rosig aus: Ab 512 Samples bekomme ich vo Zeit zu Zeit xruns, selbst wenn das System überhaupt nicht belastet und keine andere Anwendung geöffnet ist - die in qjackctl angezeigte Prozessorlast bewegt sich bei 1%, top listet jackd mit 1,7% CPU. Das ist sc
hon recht ungewöhnlich, weil ich mit einem wesentlich älteren Rechner mit M-Audio-Soundkarten und dem gleichen System keine Probleme hatte.


Am meisten macht mich folgende Meldung beim Starten von Reaper stutzig:
Das scheint mir ein Hinweis zu sein, wo das Problem liegen könnte. leider habe ich bis jetzt noch nichts genaueres dazu gefunden... Ich bin für jede Hilfe dankbar.

scheinbar hast du dein problem schon selbst indentifiziert.
interessant ist der "- die üblichen Tweaks (limits.conf, rt-clock)" punkt.

scheinbar hst du irgendwo /mnt/ramfs angegegeben, wo du entweder als user keine rechte hast, dort zu schreiben/lesen, oder an dem mountpunkt kein tmpfs eingehängt ist. das standard linux tmpdir ist /dev/shm und sollte auch unter ubuntu verfügbar sein.
seit jackd 0.109.0 ist das tempdir per default auf /dev/shm gesetzt, ich weiß jedoch nicht ob das aus einer variable ausgelesen wird, bzw. ob es einen command swich gab um dies festzulegen, da ich schon die neue version nutze.

überprüfe einfach ob du mit dem folgenden command einen output bekommst, der in /mnt/ramfs liegt. falls dies nicht der fall ist, ist klar dass dies dein problem ist. auch wäre es nicht verwunderlich wenn jackd xruns bekommt, auch wenn keine clients dran hänge, da der temporäre speicher im ram fehlt.

mfg z421

um noch genauer darauf einzugehen:
wenn man "--with-default-tmpdir=PATH" beim ./configure von jack mitgibt, kann man diesen pfad ändern. dies ist allerdings eine "build-time" option, und keine "runtime" option.

d.h. wenn du die normale ubuntustudio version von jack benutzt wird es einfacher sein, in der /etc/fstab den benötigten eintrag zu tätigen. (allerdings ist es auch kein problem das packet mit den benötigten optionen neu zu bauen, siehe: apt-get source; dpkg-buildpackage und den ./debian/ order im source package welches mit dpkg-buildpackage geholt wird.)

mfg z421

Den Pfad habe ich beim Kompilieren von Jack selbst so gesetzt und den Eintrag in die /etc/fstab hinzugefügt (genau so wurde es nämlich in der Readme von Jack vorgeschlagen) - vorher war es /dev/shm aus der APT-Version von Jack, da hatte ich exakt die gleichen Probleme. Alle User haben übrigens Lese- und Schreibzugriff.

Komischerweise kommt die Meldung zwar beim Starten von Reaper, aber nicht in qjackctl. Beide werden vom selben User ausgeführt.

-----

Habe jetzt 64studio parallel zu Ubuntu installiert, läuft perfekt - Jack gibt keine xruns im Leerlauf, das Reaper-Demo-Projekt läuft ohne Aussetzer bei 128 Samples, meine eigenen Projekte konnte ich auch erstmals ohne Aussetzer mit voller Plugin-Last abspielen. Mich würde es nicht wundern, wenn jetzt auch Ardour keine Abstürze bei großen Projekten mehr verursacht, da wäre der Umstieg auf Reaper eigentlich gar nicht nötig gewesen Trotzdem bleibe ich jetzt beim Sensenmann. Wenn ich jetzt noch das WLan zum Laufen bekomme, fliegt Ubuntu zugunsten von Jacklab runter, das hatte ich nämlich bisher noch gar nicht.

cannot lock down memory for RT thread (Cannot allocate memory)

hupps, da habe ich mich scheinbar selber geirrt. das hat in dem fall nichts mit dem tmpfs zu tun. das liegt an den pam einstellungen.

Then edit /etc/security/limits.conf

@audio - rtprio 90
@audio - nice -5
@audio - memlock 500000

^ das sollte die lösung zu deinem problem sein.

mfg z421

Muss den Thread nochmal updaten. Bis vor kurzem lief nun mit 64studio alles sauber, aber mittlerweile haben sich aus unerfindlichen Gründen auch hier Probleme eingestellt:

#1: Das monatelang stabile System produziert auf einmal XRuns zu zufälligen Zeitpunkten - selbst wenn alles im Leerlauf läuft, keine Audioprogramme offen etc.
Am merkwürdigsten waren allerdings die xruns an sich - es wurde innerhalb eines Jack-Aufrufs immer exakt die gleiche Länge angezeigt, und die war nicht von schlechten Eltern: Sie lag immer bei z.B. 1207673399803.904 ms, das macht um die 38 Jahre Trotzdem waren nur kurze Aussetzer zu hören. Ganz nebenbei wurde ich von mysteriösen System-Freezes geplagt.
Konfiguration:
64studio Kernel 2.6.21.2-multimedia
Alsa 1.0.16
Jackd 0.109

#2: Mir wurde es zu bunt, und da meine Root-Partition eh zu klein war, habe ich 64studio ein zweites mal auf der ehemaligen Ubuntu-Partition installiert.
Änderungen nach der Neuinstallation:
- Wine 0.9.54 installiert
- Wineasio 0.5 (oder was auch immer im 64studio-Repository rumgeistert) installiert
- X-Server zwecks Dualhead auf Version 1.4.1 bzw. 7.3 upgegradet
- zusätzlich Jackdmp installiert, da mittlerweile ein Dualcore im Laptop haust (Probleme bestanden schon vor dem CPU-Upgrade).
Und siehe da, es tauchen wieder Probleme auf - im Leerlauf kommen zwar keine Dropouts mehr, aber beim Arbeiten mit Reaper, vor allem beim Rumspielen mit VSTI, kommt nach einer Weile ein XRun dem direkt ein Haufen weiterer folgt (sprich, die Zahl in Klammern in qjackctl erhöht sich rasant). Dabei wird gleich noch der Soundfluss gekappt, erst nach einem Jack-Neustart hört man wieder etwas. Und siehe da, die XRuns haben schon wieder absurde Längenangaben! Interessanterweise tritt das Problem sowohl bei Jackd als auch bei Jackdmp auf.

Hat jemand eine Idee, woher die utopischen Zahlen rühren?

Falls nicht, könnte mir zumindest jemand dabei assistieren, in Jacklab einen aktuelleren X-Server (möglichst 1.4.1 bzw. 7.3, ich blicke bei der Versionierung nicht durch) sowie XFCE 4.4.2 einzurichten? Ich als eingefleischter APT-User blicke beim RPM-System irgendwie überhaupt nicht durch Hab es nach zwei Stunden Frustration wieder vom Rechner geschmissen, da ich ohne das X-Server-Update quasi gar nichts mit meinem Rechner anfangen kann.