Tipp: Linux 64Bit mit Wineasio(x)

[4damind]

Wer gerne auch bei [g=547]Linux[/g] zu 64Bit wechseln will und das wegen fehlender Unterstützung durch Wineasio noch nicht gemacht hat, kann jetzt

Drumfix hat einen experimentellen Treiber auf der Pfanne mit der Bezeichnung wineasio-x. Neben dem Wineasio Treiber erhält das Paket eine jackbridge die als Vermittler dient. Das ganze ist momentan wie ich das verstanden habe nur eine Notlösung solange bis die Leute von Jack die Probleme bei 64Bit beseitigt haben.
Warum, weshalb und welches Problem kann Drumfix wohl am besten selbst erklären.

Das Quellpaket muss selbst gebaut werden oder ihr probiert mein Deb-Paket was ich unter [g=548]Ubuntu[/g] gebaut habe (unten verlinkt)
Die Quellen befinden sich hier wineasio-x.tar.gz
Es benötigt die Header u.a von Wine und das [g=12]Asio[/g]-SDK von Steinberg. Die Pfade im Makefile müssen angepasst werden, sodass wineasio.so.dll z.B. unter Ubuntu64 nach /usr/lib32/wine/ installiert wird und jackbridge nach /usr/bin.
Ausserdem muss in der Build-Regel für die DLL "-ljack" rausgenommen werden, sonst gibt es einen Fehler beim Build.

Nach Installation wie üblich ein "regsvr32 wineasio.dll" um die DLL zu registrieren.
jackbridge muss auch gestartet werden, idealerweise gleich in qjacktrl (Optionen: Execute Script after Startup und dort "jackbridge&" eintragen) oder halt über ein Shellscript basteln
Innerhalb Qjacktrl die Ausgänge von jackbridge mit den Eingängen des System verbinden (Connect Button in QJackControl). Siehe Bild.

Läuft hier sehr gut mit Reaper, bekanntermassen mit kleiner [g=5]Latenz[/g] bei mir hier von <2ms und zusätzlich noch mit den Vorteilen die ein 64Bit System mit sich bringt (z.B. viel möglicher RAM...)

Hier noch das Paket das ich mal für [g=548]Ubuntu[/g] gebaut habe. Es installiert wineasio.dll.so nach /usr/lib32/wine und das jackbridge nach /usr/bin. Anschliessend noch die DLL registrieren unter dem Useraccount mit "regsvr32 wineasio.dll".
wineasio-x_0.3.deb

[Edit]
Afaik gibt es mittlerweile auch schon ein reinrassiges 64Bit Wine, was dann auch nur mit 64Bit Windows Anwendungen läuft. Ob das schon einsetzbar ist etc. weiss ich allerdings nicht.

 

[zettberlin]

...
nur eine Notlösung solange bis die Leute von Jack die Probleme bei 64Bit beseitigt haben.

Jack hat schon seit Jahren keinerlei Probleme mit 64bit.

Das Problem hat/ist Wine

 

[4damind]

you can use wineasio-x, until the jack developers get their 64/32 [g=395]bit[/g] bugs fixed.

Siehe hier

 

[metasymbol]

Wer jetzt "schuld" ist daran, das 32bit apps auf 64bit Systemen nicht so rund laufen sei dahingestellt; Bevor sich jetzt aber alle daran machen, ein 64bit System aufzusetzen: Das bedeutet Audio [g=547]Linux[/g] nochmal 2-4 Jahre zurück und der Performancegewinn macht sich erst bei zig GB RAM bemerkbar.

Also wer jetzt auf 64bit [g=547]Linux[/g] setzt, muss sich auf selberkompilieren, dauernde Abstürze und sehr viele Einschränkungen gefasst machen und betritt das Experimental- Land, wo das geheime Howto gefunden werden muss, das auf die versteckte Manpage hinweist, worin steht, das das Programm erst noch geschrieben werden muss -von dir.

Das ist nur was für Freaks und Geeks und selbst denen vergeht leicht die Lust nach einiger Zeit. Als Entwickler ist 64bit AudioLinux allerdings eine echte Herausforderung. Perfekte 64bit [g=547]Linux[/g] Lösungen wird es mE in ca 4 jahren geben.

 

[4damind]

Kann ich so nicht bestätigen.
64Bit [g=547]Linux[/g] läuft sehr stabil, inklusive der üblichen Anwendungen.
Mal abgesehen vom wineasio-x musste ich auch nichts selber kompilieren.
Flash für Firefox funktioniert genauso wie Java oder die Windows Codecs (für die es mittlerweile auch eine w64codecs Variante gibt).

Selbst VirtualBox gibt es als 64Bit Version die insbesondere von dem nun möglichen größeren RAM profitiert.
Ich habe hier z.B. 4GB im System wovon bei [g=547]Linux[/g] letztlich 3,8GB ankommen. Da kann ich ohne Probleme 1,5GB der VirtualBox geben und behalte knapp über 2GB noch für [g=547]Linux[/g].

Das einzige was vorkommen kann wenn man spezielle closed Source benutzt die es nur als 32Bit gibt. Viele Sachen funktionieren ohne zutun weil automatisch bei solchen Sachen die Kompatibilitätslibs (32Bit) von [g=548]Ubuntu[/g] installiert werden.
In wenigen Fällen kann es aber sinnvoller sein sich eine 32Bit chroot zu machen.
Ich nutze z.B. vuescan, eine kommerzielle Scannersoftware. Die läuft in einer chroot ganz hervorragend. Wird mit Hilfe von dchroot dann auch ganz einfach aufgerufen.
Bei [g=548]Ubuntu[/g] gibt es dafür auch eine kurze Howto um sowas einzurichten. Das wäre jetzt die einzige Sache die sicherlich nicht sehr Anfängerfreundlich ist.

In Ubuntu64 ist das zumindest gut gelöst und inklusive Realtime-Kernel oder sonstigem Kram kein Unterschied zu einer 32Bit Installation.
Wer eine Partition frei hat bzw. genug Platz um ein weiteres [g=547]Linux[/g] zu testen sollte mal Ubuntu64 ausprobieren und sich einfach selbst ein Bild machen.

 

[zettberlin]

Bevor sich jetzt aber alle daran machen, ein 64bit System aufzusetzen: Das bedeutet Audio [g=547]Linux[/g] nochmal 2-4 Jahre zurück und der Performancegewinn macht sich erst bei zig GB RAM bemerkbar.

Grundsätzlich gesehen bringt 64bit nur Unterstützung für mehr RAM, in der Praxis habe ich 5 Linuxdistros auf einem 64bit-AMD mit nur 1GB RAM getestet und 64Studio mit 64bit Kernel lief von allen am schnellsten und stabilsten. Keins der 3 32bit-Systeme im Test lief besser.

Also wer jetzt auf 64bit [g=547]Linux[/g] setzt, muss sich auf selberkompilieren, dauernde Abstürze und sehr viele Einschränkungen gefasst machen und betritt das Experimental- Land, wo das geheime Howto gefunden werden muss, das auf die versteckte Manpage hinweist, worin steht, das das Programm erst noch geschrieben werden muss -von dir.

Kann sein, dass das mit Suse so ist - 64Studio und mit kleinen Abstrichen auch [g=548]Ubuntu[/g] Studio 64 laufen 1a und haben gut gehende Versionen aller relevanten Linuxaudio Programme an Bord.

Das ist nur was für Freaks und Geeks und selbst denen vergeht leicht die Lust nach einiger Zeit. Als Entwickler ist 64bit AudioLinux allerdings eine echte Herausforderung. Perfekte 64bit [g=547]Linux[/g] Lösungen wird es mE in ca 4 jahren geben.

Nein, perfekte wird es gar nicht geben, sehr gute gibt es jetzt schon.

 

[4damind]

64Studio muss ich mir mal anschauen. Wie ich das in Erinnerung habe basiert das auch auf Debian (was mir schonmal sehr sympathisch ist).
Bei mir ist sowieso eine 32Bit Partition frei geworden

 

[metasymbol]

Interessant was ihr schreibt. Vielleicht liegt es ja daran, das die openSUSE 64bit Audiogeschichte gegenüber [g=548]Ubuntu[/g] noch im argen ist? Auch hatte ich immer gedacht, das man zB auf Flash verzichten muss. Meine vorsichtigen Tests Anfang letzten Jahres mit openSUSE 10.2 64bit ergaben jedenfalls nicht das Bild eines gereiften, stabilen Produktionssystems. 90% aller Audioapplikationen stürzten ab und es machte keinen Spass.

[g=548]Ubuntu[/g] 64 kann ich leider nicht installieren, weil es Schwierigkeiten mit der X-Erkennung hat und mir nur einen unbrauchbaren schwarzen Bildschirm liefert (Geforce 7200 mit 2x Samsung 19' tft's) und selbst stundenlanges Fummeln an xorg.conf nichts gebracht hat (andere Distributionen haben da keine Schwierigkeiten).

Die Sicherheit mit der ihr sagt, das sei was brauchbares, hat mich zumindest angeregt, mir nochmal generell 64bit [g=547]Linux[/g] anzuschauen. Anscheinend hat haben sich die Entwickler mächtig ins Zeug gelegt und ihre Anwendungen auf 64bit umgeschrieben. Ich hatte geglaubt das dauert noch ein paar Jahre, bis das abgeschlossen ist.

 

[4damind]

Die üblichen Kandidaten waren eigentlich immer Flash, Java und Realplayer sowie Mplayer mit den Windows-Codecs.

Flash funktioniert ouf of the Box im Firefox3 (Beta5) 64Bit. Ich kann mich nichtmal erinnern das ich was installiert habe. Aber auf jedenfall ist flash-nonfree im Repository.

Die Windows-Codecs gibt es auch als w64Codecs Version. Unter [g=548]Ubuntu[/g] muss man für diese Sachen (wegen Lizenz und Kram) am besten das Mediabuntu als Source einbinden. Dann hat man alles bis hin zu DVD Support.

Den Helixplayer Nightly 64 habe ich allerdings noch nicht getestet weil ich den eigentlich nie brauche (ich nutze wenn überhaupt nur dort den Nightly auch bei 32Bit weil die schon Alsa Support drinnen haben). 64Bit Version für [g=547]Linux[/g] gibt es aber auf der Helixplayer Seite.

Java gibts ja mittlerweile von Sun und IBM als 64Bit. Ich nutze hier Eclipse mit der IBM Java 64Bit. Ohne Abstürze und stabil.

[Ergänzung]
Bei [g=548]Ubuntu[/g] wird der nspluginwrapper automatisch installiert, deswegen funktionert Flash auch ohne zutun in einem 64Bit Browser.
Bei Gentoo gibt es das Paket auch, lässt sich dort auch ohne grosses basteln nutzen.

 

[Frank6502]

@4damind

ist den jetzt ein geschwindigkeitsvorteil und wenn ja mal so in %te gegenüber nem 32bit zu merken ?

hats irgendeinen anderen vorteil ???
abgesehn von der persönlichen genugtuung mehr als 4GB zu adressieren ?

LG Frank

 

[4damind]

Bei Ubuntu64 kann ich keinen Geschwindigkeitsvorteil feststellen. Da gibts aber sicherlich Benchmarks wo sich Leute die Mühe gemacht haben irgendwelchen Kram genau zu benchmarken.
Möglicherweise das es bei Gentoo64 oder Studio64 ganz anders aussieht...

Mehr verfügbarer RAM ist schon für mich der primäre Vorteil, besonders wenn man VMs nutzt oder Java freut man sich immer über viel RAM

 

[4damind]

Btw. 64Studio läuft auf meinem System nicht. Der installierte Kernel ist zu alt für die aktuelle Hardware. Installieren lässt es sich zwar von der Live-DVD aber beim booten freezed er irgendwann bei AGPGART oder SATA (kann man schlecht erkennen).
Müsste da einen eigenen aktuellen Kernel backen um wenigstens das System booten zu können.
Gibt es bei 64Studio auch etwas wie "testing" oder "unstable" mit einem aktuellen 2.6.24 RT-Kernel?

 

[404NotFound]

Das schon gelesen? http://www.64studio.com/node/314

Ansonsten kannst du für den neueren Kernel einfach die Sid-Quellen reinfummeln.
EDIT: Ok, ist natürlich Schwachsinn, weil du ja gar nicht bis dahin kommen kannst

 

[4damind]

Oh je... Anscheinend haben einige da Probleme mit dem alten Kernel bei der Studio64. Nee so ist das nix. Mal auf die nächste Version warten und dann gucke ich es mir nochmal an.

 

[metasymbol]

Ja, 64studio hat da das gleiche "Problem" wie JAD 1.0 - hab die Entwicklerversion von 64studio 2.1 mal getestet, aber da ging gar nichts. Ist aber auch schon ein paar Tage her.

Wenn man es ganz aktuell und Debian haben will -Die deutsche Community Sidux hat auch ein Tutorial im Programm, mit denen man Bleeding Edge Debian (Sid) Audiofähig macht. Mir ging das bisher immer zu weit und so toll ist Debian nu auch nicht, als das ich tagelang mich daran zum basteln setze.

 

[404NotFound]

metasymbol schrieb:
und so toll ist Debian nu auch nicht, als das ich tagelang mich daran zum basteln setze.

Das gleiche habe ich mir auch bei JAD gesagt
Mal im Ernst (und etwas OT), ist es irgendwie möglich, in JAD eine aktuelle X-Version (mindestens 1.3) sowie XCE 4.4.2 zu installieren? Das waren nämlich die Punkte an denen ich gescheitert bin.

 

[4damind]

Man könnte sich Studio64 mit debootstrap aufsetzen (halt Etch nehmen und dann die Quellen von Studio64 rein) und dann einen Kernel von Sid nehmen oder halt selber einen bauen. Aber auf soviel Bastelei habe ich nun auch keine Lust Wenn ich "basteln" will kann ich auch Gentoo mit dem Pro-Audio Overlay nehmen^^

Was ich mich nur Frage... Die haben doch ein eigenes Apt-Repository. Warum halten die nicht wenigstens die Systemkomponenten (wie den Kernel) auf einem aktuellen Stand und bauen dann halt mal selber ein Paket?