Seite 2 von 2
Verfasst: Fr Feb 12, 2010 6:42 pm
von sommi
anselmoso hat geschrieben:Weil eure Erfahrung ist, dass alles mit 48Khz runder läuft oder warum genau?
48 ist besser durch 3 teilbar als 44!
Habe ich so gelernt, erklären können das andere besser
Gruß von Sommi
Verfasst: Fr Feb 12, 2010 9:40 pm
von horo
Hi,
das Thema wurde letztens auf LAU diskutiert:
http://old.nabble.com/usb-and-jack-td26046087.html
Ciao Martin
Verfasst: Sa Feb 13, 2010 1:39 am
von zettberlin
anselmoso hat geschrieben:Weil eure Erfahrung ist, dass alles mit 48Khz runder läuft oder warum genau?
Klanglich kann ich hier beim Testen mit Zyn und keinen Unterschied zwischen 44 und 48 Khz ausmachen.
Ein hörbarer Unterschied kommt erst bei 96KHz zu Stande. Der Effekt ist auch bei anderen Synths ausgeprägter, besonders bei AMS.
anselmoso hat geschrieben:
Ich arbeite halt oft mit externen Produzenten zusammen, die unsere Aufnahmen dann abmischen und da lautet die Vorgabe "bitte in 44Khz und 24Bit aufnehmen".
Echt? wenn die noch mischen und wahrscheinlich diverse Prozessoren laufen lassen, sollten sie aber eher bestrebt sein, so viel Basismaterial wie möglich zu bekommen. 24bit ist natürlich wichtiger aber die 44.1-Forderung halte ich für Faulheit (immer so gemacht! warum anders?...)
anselmoso hat geschrieben:
48Khz bedeute da unnötiges Runtergerechne weil sie es dann in 44Khz mischen,
anselmoso hat geschrieben:
bringe mir qualiatitv rein gar nichts und würde auch die CPU unnötig mehr belasten - natürlich nicht gravierend, aber meiner Kenntnis nach bringt es rein audio-mäßig erst mal 0 Vorteile.
48 hört man kaum, das ist richtig. Aber der Unterschied zu 96 ist erheblich, das hört jeder, der nicht auf die Ohren gefallen ist
anselmoso hat geschrieben:
Das Interface ist übrigens USB 1.1.
Ha! da haben wirs!
Wenn wir den Drang des Ird’schen abgeschüttelt,
Das zwingt uns stillzustehn. Das ist die Rücksicht,
Die Elend lässt zu hohen Jahren kommen.
Es gibt einen Bug im Protokollcode des Linux-USB-Systems, der zu hohen Lastspitzen bei Echtzeitübertragungen von Audio führen kann, wenn eine nicht glatt durch 3 teilbare Kilohertzrate gewählt ist.
48 und 96 funktionieren blendend, 44.1 macht Schwierigkeiten. Ich habe das selbst bei einem halben dutzend USB und übrigens auch Firewire-Interfaces beobachtet - sieht so aus, als wäre es das ...
Verfasst: Sa Feb 13, 2010 10:15 am
von anselmoso
Zwischenstand: In Muse mit den mitgelieferten SoftSynths habe ich bislang keine XRuns, also z.B. mit "Organ" und "deicsonze".
Gibts denn sonst noch Synths von Zyn-Qualität, die man z.B. in Muse nutzen kann?
Verfasst: Sa Feb 13, 2010 12:33 pm
von corresponder
hi,
du kannst doch fast alle synths, die midi machen, in muse nutzen;
asynth
qsynth
was macht zyn, immer noch xruns?
gruss
c.
Verfasst: Mo Feb 15, 2010 12:17 pm
von anselmoso
habe jetzt mal die letzten 2 tage primär audio-aufnahmen gemacht, mit zyn und den anderen synths muss ich nochmal genauer testen. jedenfalls ist bei normalen audio-aufnahmen in ardour so, dass ich die latenz auf min. 15ms hoch schrauben muss, damit ich keine xruns (und damit dropouts in der aufnahme) bekomme. bei derartiger latenz sind dann einige aufnahme-durchgänge ohne xruns durchgelaufen. aber sobald ich se niedriger stell ( <= 128 samples) gibts xruns.
Verfasst: Mo Feb 15, 2010 10:55 pm
von linuxchaos
vielleicht dumme fragen, aber ist bei jack auch die nutzung des realtimekernels eingestellt?
grüsse
l.chaos
Verfasst: Mo Feb 15, 2010 10:58 pm
von Mitsch
Aber 15ms ist doch gar nicht schlecht für'n USB-Device, oder?
Verfasst: Mo Feb 15, 2010 11:09 pm
von linuxchaos
kenne mich mit usb nicht aus (weiss nur, dass es schlechter ist, als pci), aber zum musikmachen würde ich das dann als eher untauglich bezeichnen...
grüsse
l.chaos
Verfasst: Di Feb 16, 2010 12:46 am
von anselmoso
Jack ist bei mir folgendermaßen konfiguriert
http://img199.imageshack.us/img199/2804/testrj.jpg
(kann hier irgendwie kein Bild mit img tag einfügen)
Bei dieser Latenz laufen Audio-Aufnahmen so 10-20 Minuten, dann gibt es meistens doch wieder 1 bis ein paar Xruns zwischen durch.
Netzwerk alles deaktiviert. Jack und Ardour, Ubuntu 9.10
Midi und Synthies muss ich nochmal ausgiebig in Muse und co testen, es scheint in den vorigen Tests primär an LMMS zu liegen, dass es dauernd zu Knacksern kommt. Die haben wohl noch allgemein Probleme mit ihrer Audio-Engine.
Verfasst: Di Feb 16, 2010 11:36 am
von Mitsch
Hä? Jetzt bist Du ja immer noch auf 44.1 KHz und es läuft trotzdem so gut? Kein Unterschied zu 48 kHz?
Ich mein: Einfach mal testweise. Und wenn's wirklich besser läuft, vielleicht gibt es ja 'ne Möglichkeit, das Ganze am Ende in 44.1 kHz zu exportieren, damit Du wieder mit Deinen Leuten kompatibel bist...
Grüße!
Verfasst: Di Feb 16, 2010 1:00 pm
von anselmoso
Umstellung auf 48Khz bringt keinen Unterschied, exakt das gleiche Verhalten wie bei 44.
Wenn ich den Zyn pur direkt anspiele mit Midi Keyboard gibts auf jeden Fall weniger XRuns, gleiches Verhalten wie beim Audio-Recording mit Ardour.
LMMS scheint momentan noch recht unbrauchbar.
Verfasst: Di Feb 16, 2010 1:03 pm
von Mitsch
anselmoso hat geschrieben:LMMS scheint momentan noch recht unbrauchbar.
Ich fürchte: Ja. Obwohl ich es noch nie ausprobiert habe. Aber ich höre hier immer wieder, dass LMMS keinen stabilen Eindruck hinterlässt.
Verfasst: Di Feb 16, 2010 1:31 pm
von horo
Mitsch hat geschrieben:Aber 15ms ist doch gar nicht schlecht für'n USB-Device, oder?
Nicht schlecht, geht aber noch besser (2ms):
http://www.sidux.com/index.php?name=PNp ... 011#150011
Code: Alles auswählen
/usr/bin/jackd -R -P79 -dalsa -dhw:1,0 -r48000 -p48 -n2 -Xseq
Interessant ist der Parameter -p48, der nicht die üblichen Zweierpotenzen als Puffergröße wählt, sondern Vielfache von 1ms-Paketen, also 48 oder 96. Das ist eh' die Menge, die USB-Audio-Geräte pro Interrupt (jede ms) über den Bus schicken.
Clemens Ladisch, der USB-Guru, schrieb dazu auf LAU (^^):
For most USB audio devices, using period sizes that are an integer
multiple to the USB packet size (1 ms) will definitely help. Some
devices like the SB Audigy 2 NX or UA-101 do not synchronize their
sample clock to the USB clock (and this has nothing to do with USB
2.0), and in those cases, the period size does not matter.
(I did not know that Jack now supports lengths that are not powers
of two.)
Ciao Martin
