Aufnahme mit Knacksern - über X11-Forwarding geht es ;-) - Wenn ich Audacity auf dem gleichen Rechner öffne haben die Aufnahmen alle ein leises Knistern. Wenn ich Audacity über X11 Forwarding ...

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Aufnahme mit Knacksern - über X11-Forwarding geht es ;-)

      Hallo Liste,

      ich habe hier ein seltsames Phänomen:

      Meine Aufnahmen haben alle ein leises Knistern - wenn nicht schlimmeres. Egal ob ich über OSS (portaudio v18) oder Alsa (v19) aufnehme. Ich habe verschiedene Versionen von Audacity ausprobiert 1.2.4, 1.2.5, 1.3, teils selbst kompiliert, teils als Debian Packet.

      Mein System ist ein Debian Sarge
      Kernel 2.6.8
      Alsa 1.0.8
      Soundkarte Soundblaster Life! Platinum.
      (Problem existiert aber auch mit Kanotix, das auf Debian testing/unstable basiert)

      Abspielen ist generell kein Problem, auch wenn es hier gelegentlich zu einigen Knackser kommt, wenn der Rechner stärker belastet ist.

      Zufällig habe ich Audacity über X11-Forwarding auf einem anderen Rechner geöffnet. Wenn ich jetzt über OSS aufnehme (mit der Audacity-Version mit portaudio v18) dann klingt alles bestens. Mit Portaudio v19 gibt es nach wie vor Probleme: Audacity stürzt dann häufig nach einiger Zeit ab, aber die Aufnahmen klingen auch besser als wenn X auf localhost läuft.

      Was auffällt ist, dass der Cursor von Audacity auf localhost sehr ruckelig ist, auf einem anderen mit X11-Forwarding läuft er flüssiger. Könnte X hier ein Problem machen? (Der andere Rechner ist Debian Testing; ich hab noch nicht probiert, ob das einen Einfluß hat.

      Hat jemand eine Idee, woran das liegen könnte? Mir ist das ein Rätsel.

      grüße
      luna
    • hi gtred,

      danke für den Tip. Hatte ich noch nicht systematisch. Jetzt schon. Und tatsächlich: XFree86 frisst bis zu 50 % der Prozessorzeit. Kein Wunder also, dass das über X11-Forwarding dann funktioniert. Das scheint es also zu sein. Bleibt die Frage, woran es liegt.

      Dazu noch einige Hinweise:

      Grafikkarte ist eine VGA compatible controller: ATI Technologies Inc 3D Rage IIC AGP (schon ältere Bauart mit 16 MB oder sogar nur 8)
      XServer ist XFree86 Version 4.3.0.1

      Allerdings gibt es auf dem gleichen Rechner auch ein System mit Xorg. Damit ist der Prozessorverbrauch bei der Aufnahme noch höher: bis zu 90 %.

      Auf dem System, auf dem es problemlos läuft ist eine ATI Radeon Mobility 7500.

      Ich denke nicht, dass es an der config liegt: die von Xorg hat der Kanotix Installer erstellt, die von Debian Sarge ist von debconf erstellt und per Hand angepasst.

      Es gibt auch keinen eindeutigen Hinweis darauf, dass es an irgend einer Inkompatiblität mit wxWidgets liegt. Ein System ist Debian Stable, und das Problem betrifft sowohl selbst kompilierte Versionen als auch die officielle aus den Deb-Repositories.

      X selbst ist auch nicht grundsätzlich langsam. Ein laufender MPlayer Bspw. braucht max. 10% CPU für den X-Server.

      Noch eine Idee, wo ich weiter suchen könnte?

      grüße
      luna
    • Hi Luna,

      die Mauszeigergeschichte hört sich nach einem Interrupt- bzw. Bus-Problem mit dem Grafikkartentreiber an. Welchen Treiber verwendest Du? Bei ATI-Grafikkarten gibt es grundsätzlich drei Möglichkeiten: den binären von ATI selbst, den Treiber "radeon" und noch einen, der, glaube ich "ati" heißt oder so. Alle drei haben unterschiedliche Fähigkeiten in Bezug auf OpenGL usw. Je nachdem, ob der APIC des Rechners von Linux unterstützt wird oder nicht und ob genügend Interrupts frei sind, kann es sinnvoll sein, den einen oder anderen einzusetzen. Aber selbst im regulären Betrieb kommt es vor, dass bestimmte Chipsätze/Grafikkarten bei DMA-Transfers millisekundenlang den PCI-Bus sperren und dadurch Sound-Aussetzer verursachen. Das Ganze lässt sich nur dadurch in den Griff kriegen, dass man zusieht, dass keine DMA-Transfers stattfinden, d.h. etwa bei Problemen mit der Grafikkarte einen "unbeschleunigten" X11-Treiber verwenden, der keine Interrupts/DMA verwendet, oder bei der Festplatte (so blöd es klingt) DMA ausschalten.

      Das obige nur als allgemeine Info, was es bei Dir genau ist, kann ich natürlich auch nicht sagen.

      Ansonsten bzgl. ALSA: kompilier Dir mal das allerneueste CVS von Audacity selber, und zwar mit folgender ./configure-Zeile:

      ./configure --with-portaudio=v19

      Dann wähle zum Aufnehmen einen ALSA-Treiber aus den Einstellungen. Das Portaudio v19, das bei allen Versionen vor 1.3.2 (kommt demnächst raus) dabei war, ist kaum zu gebrauchen. Wenn es mit der CVS-Version immer noch knackst, gibt es auch noch die Möglichkeit, die Puffergröße einzustellen (in CVS-Version in den Einstellungen bei Audio E/A die Einstellung "Latency/Audio to Buffer"). Wenn es nur darum geht, lange Aufnahmen auf beschäftigten Rechnern knackserfrei herzukriegen, kann man das ruhig mal auf 500 ms oder so stellen.

      Gruß
      Markus
      Markus -- Audacity Lead Developer / Administrator Audacity Forum
      [url=http://www.privatmusikverein.de/]Privatmusikverein Nürnberg e.V. - Veranstalter für Kammermusik-Konzerte in Nürnberg[/url]
    • Hi Markus,

      danke für die Tips, ich habe nun verschiedenes ausprobiert:

      1. vesa als Treiber verwendet (ist der unbeschleunigt?? ich dachte ja...). Mir schien das eine geringfügige Verbesserung zu bringen, aber noch nicht die Lösung. Es knackst immer noch, aber Xfree86 beanspruchte nur noch rund 15-20% der Prozessorlast

      2. statt der ATI-Karte den On-Board Grafik-Chip (Intel 82815) verwendet mit dem Treiber i810: auch deutliche Verbesserung, aber immer noch knacksen. Prozessorlast von Xfree86 unter 10%.

      3. dma bei der Festplatte ausschalten, habe ich noch nicht probiert. Mache ich und berichte.

      Gleiches Problem übrigens mit Ardour und Jack. Zwar besser als mit Audacity (in allen Fällen übrigens mit OSS, weil mir gerade kein mit Portaudio v19 kompiliertes zur Verfügung stand) - aber nur, wenn man sonst nichts unter X macht. Dann geht es weitgehend ohne Knackser. Sobald man aber Fenster wechselt knackt es ziemlich... Audacity ist weniger empfindlich auf Aktionen mit Maus und Tastatur, dafür knackst es ohne dies schon genug.

      Problemlose Aufnahmen gibt es übrigens mit arecord (dem Alsa-Tool). Ist das plausibel?
      Wie ist das eigentlich mit der Aufnahmequalität von arecord. Ist das egal, oder sind da Audacity oder Ardour prinzipiell überlegen?

      Vielleicht hast du noch eine Idee?

      grüße
      luna
    • luna wrote:


      Problemlose Aufnahmen gibt es übrigens mit arecord (dem Alsa-Tool). Ist das plausibel?
      Wie ist das eigentlich mit der Aufnahmequalität von arecord. Ist das egal, oder sind da Audacity oder Ardour prinzipiell überlegen?


      Also Aufnahme ist prinzipiell Aufnahme, also wenn das Programm 16-bit-Audiodateien schreibt, ist es ja ok.


      Vielleicht hast du noch eine Idee?


      Nee, sorry, also außer dem was ich oben geschrieben habe. Hört sich für mich nach 'nem grundsätzlichen "Linux verträgt sich mit meiner Grafikkarte/meinem Chipsatz/meinem Board/meinem Prozessor/meinem Wetter nicht" an....

      Gruß
      Markus
      Markus -- Audacity Lead Developer / Administrator Audacity Forum
      [url=http://www.privatmusikverein.de/]Privatmusikverein Nürnberg e.V. - Veranstalter für Kammermusik-Konzerte in Nürnberg[/url]
    • Hi Luna,

      in /var/log/ findet sich auch nichts, was hilfreich wäre?

      Eventuell reicht es, dem Audacity einen renice -5 (als root) mitzugeben, damit es CPU-Zeit und HD-Zugriffe bekommt, wenn es diese benötigt.

      Wie ist die Last Deines Systems (Load)?

      Ist es Knistern (wie von Aussetzrern) oder eher ein sirren (könnte die arbeitende CPU sein).

      Gruß,
      Gregor
    • Hi Gregor

      gtred wrote:


      in /var/log/ findet sich auch nichts, was hilfreich wäre?


      weder in syslog noch in Xfree... log.

      gtred wrote:


      Eventuell reicht es, dem Audacity einen renice -5 (als root) mitzugeben, damit es CPU-Zeit und HD-Zugriffe bekommt, wenn es diese benötigt.


      leider nein. nicht einmal -10 ändert etwas. Ich habe mittlerweile auch versucht dma bei der Platte auszuschalten, wie Markus vorgeschlagen hat - leider ohne Effekt.

      gtred wrote:


      Wie ist die Last Deines Systems (Load)?


      Nicht verdächtig. Unter 1

      gtred wrote:


      Ist es Knistern (wie von Aussetzrern) oder eher ein sirren (könnte die arbeitende CPU sein).


      Es ist ein Knistern wie bei kurzen Aussetzern. Wenn man andere Dinge unter X macht, dann kommt dieses Knistern häufiger, sonst nur alle ca. 10 Sek. und ganz leise.

      Wenn ich mit arecord (auch da habe ich den Eindruck - wenn auch viel seltener - knistert was) etwas aufnehme erhalte ich folgende Meldungen

      Source Code

      1. ~$ arecord -f cd -t wav test.wav
      2. Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
      3. overrun!!! (at least 30.676 ms long)
      4. overrun!!! (at least 65.685 ms long)


      Ich bin mir nicht ganz sicher, was das bedeutet. Könnte aber damit im Zusammenhang stehen.
      grüße
      luna
    • Overrun bedeutet, dass die Daten, welche die Soundkarte zur Verfügung gestellt hat, nicht rechtzeitig von arecord abgeholt wurden und deshalb verloren gingen. Irgendetwas scheint den Computer periodisch zu beanspruchen und dabei das System für einige Millisekunden lahmzulegen. Das kann z. B. ein falsch implementierter Treiber sein o.ä., wie oben beschrieben. Hast Du mal versucht, Portaudio v19 zu verwenden und die Puffergröße hochzusetzen, so wie ich es geschrieben habe?
      Markus -- Audacity Lead Developer / Administrator Audacity Forum
      [url=http://www.privatmusikverein.de/]Privatmusikverein Nürnberg e.V. - Veranstalter für Kammermusik-Konzerte in Nürnberg[/url]
    • Hi Markus,

      Markus wrote:


      Hast Du mal versucht, Portaudio v19 zu verwenden und die Puffergröße hochzusetzen, so wie ich es geschrieben habe?


      noch nicht, da sich das 1.3.x auf Debian Sarge nicht so ohne weiteres kompilieren läßt, weil wxGTK 2.6. nicht verfügbar ist. Ich werde es aber bald mal probieren. 1.3.2 aus dem CVS ließ sich bei mir gestern auf einem anderen Rechner leider gar nicht kompilieren. ./configure lief ohne Fehler durch, make nicht. Vielleicht in ein paar Tagen noch mal probieren.

      grüße
      carsten
    • Hi,

      also etwas habe ich mittlerweile gefunden

      less /proc/interrupts ergibt

      Source Code

      1. CPU0
      2. 0: 4781697 XT-PIC timer
      3. 1: 3132 XT-PIC i8042
      4. 2: 0 XT-PIC cascade
      5. 7: 0 XT-PIC parport0
      6. 8: 1 XT-PIC rtc
      7. 9: 0 XT-PIC acpi
      8. 10: 239130 XT-PIC eth1, eth0, uhci_hcd
      9. 11: 85531 XT-PIC EMU10K1, aic7xxx, uhci_hcd
      10. 12: 86018 XT-PIC i8042
      11. 14: 50372 XT-PIC ide0
      12. 15: 84064 XT-PIC ide1
      13. NMI: 0
      14. LOC: 4781712
      15. ERR: 0
      16. MIS: 0
      17. /proc/interrupts (END)
      Display All


      an uhci_hcd war meine USB-Maus aktiv. Wenn die benutzt wurde gab es gelegentlich Knackser. Also ohne USB-Maus und Modul entladen ebenso aic7xxx (SCSI-Treiber)

      Der Erfolg war nicht durchschlagend, aber immerhin: mir scheint, etwas weniger Knackser. Hat also mglw. was mit den PCI-Ports zu tun. (Ich kenne mich da weniger als rudimentär aus...). Mit Audacity (1.2.3 gibt es immer noch gelegentlich Knacker. Mit arecord auch einige Overruns allerdings nur mit wenigen ms (meist unter 10). Mit ardour und Jack gelingt, wenn man den REchner nicht anschaut - und Maus nicht bewegt eine knackserfreie Aufnahme.

      Ich versuche demnächst noch, was passiert, wenn man die Soundkarte in einen anderen PCI-Slot steckt und ein paar andere PCI-Karten herausnimmt. Keine Ahnung ob es jenseits von IRQ-Sharing noch Probleme dabei geben kann. (Weiß das jemand?)

      grüße
      luna
    • Der aic7xxx ist der Treiber für den Festplatten-Controller. Es kann also schon damit zusammenhängen, dass Audacity (im Gegensatz zu anderen Programmen) während der Aufnahme große Blöcke auf Festplatte schreibt. Es könnte also schon damit zusammenhängen, dass die Soundkarte und der Festplatten-Controller am gleichen IRQ hängen....
      Markus -- Audacity Lead Developer / Administrator Audacity Forum
      [url=http://www.privatmusikverein.de/]Privatmusikverein Nürnberg e.V. - Veranstalter für Kammermusik-Konzerte in Nürnberg[/url]
    • Hi,
      sicher? ich denke aic7xxx ist das modul für den SCSI-Controller (Adaptec), an dem mein Scanner hängt. Ich kann das Modul auch einfach mit rmmod entladen. Die IDE-Festplatten sind wohl auf irq 14 u. 15 gesetzt. Aber auch wenn ich aic7xxx und uhci_hcd entlade, also EMU10K1 alleine irq11 belegt bleibt es bei leichtem gelegentlichen (ca. alle 10 -20 sec) Knistern. Aber die Richtung scheint zu stimmen. Möglicherweise gibt es mehrere Ursachen.
      grüße
      luna
    • Es reicht normalerweise pci=noacpi, da sind dann die meisten Powermanagementfunktionen noch aktiv, aber der ACPI-Support für PCI ist aus.

      Außerdem kann noch helfen "noapic" bzw. "nolapic" (oder beide).
      Markus -- Audacity Lead Developer / Administrator Audacity Forum
      [url=http://www.privatmusikverein.de/]Privatmusikverein Nürnberg e.V. - Veranstalter für Kammermusik-Konzerte in Nürnberg[/url]
    • Danke für die Tips, Bootoption acpi=off habe ich probiert, ohne Effekt. Bevor ich noch viel rumprobiere: vielleicht könnt ihr mir noch mal bei der Diagnose helfen.

      Nachdem ich die USB-Maus die mit der Soundkarte den gleichen irq belegt hatte, entfernt habe (incl. Modul) läßt sich - soweit ich das getestet habe - mit arecord auch über längere Zeit fehlerfrei aufnehmen - auch dann, wenn der REchner sonst ein bißchen beschäftigt wird.
      Anfällig für Knackser sind ardour, bei dem die Aufnahmen aber ok sind, wenn sonst nichts unter X passiert und Audacity, bei dem es immer gelegentlich knistert.

      Ich frage mich, ob die Tatsache, dass es mit arecord fehlerfrei geht, nicht darauf hindeutet, dass es eher kein pci-Problem ist, sondern es an anderer Stelle hakt? Oder bedeutet es das aus eurer Sicht noch nicht?
    • luna wrote:


      Ich frage mich, ob die Tatsache, dass es mit arecord fehlerfrei geht, nicht darauf hindeutet, dass es eher kein pci-Problem ist, sondern es an anderer Stelle hakt? Oder bedeutet es das aus eurer Sicht noch nicht?


      Naja, arecord ist halt einfach anspruchsloser. Es empfängt die Daten und schreibt sie, so wie sie sind, direkt auf die Harddisk. Das ist der "Minimalaufwand". Audacity dagegen aktualisiert auch die Bildschirmdarstellung, gruppiert die Daten in einzelne "Blockfiles", berechnet gleich sog. Summary-Daten usw. D.h., der Rechner ist bei der Aufnahme mit Audacity schon einfach mal mehr beschäftigt als bei arecord, daher auch anfälliger für Overruns. Bei Ardour ist die Situation ähnlich. Nach wie vor bin ich jedoch der Meinung, dass das Ganze von der Puffergröße abhängt. Beim neuen Audacity ist die Puffergröße defaultmäßig schonmal wesentlich höher eingestellt (etwa 5-10x), d.h. die Knackser sollten schon dadurch einfach verschwinden. Das habe ich u.a. deshalb eingebaut, weil ich mit dem alten Audacity auf meinen zwei Rechnern auch immer Knackser hatte.

      Ich halte Deine "Probleme" für völlig normal. Problem 1 scheint zu sein, dass Linux Deine Hardware, d.h. Mainboard, Chipsatz, Busmaster-Controller usw. nicht vollständig unterstützt. Problem 2 ist, dass Linux in der Grundkonfiguration eh für anspruchsvolle Audiobearbeitung nicht zu gebrauchen ist. In jeder Linux-Audio-FAQ im Netz steht, dass man seinen Kernel mit Low-Latency-Patches usw. patchen soll, um ordentlich mit Audio arbeiten zu können. Lies mal die Installationsanleitung/FAQ zu Ardour, da steht genau das drin. Abhilfe: entsprechend hohe Sicherheiten einbauen, d.h. 100ms Puffergröße und fertig. Oder beim Kauf des nächsten Rechners auf entsprechende Linux-Echtzeitfähigkeiten achten.
      Markus -- Audacity Lead Developer / Administrator Audacity Forum
      [url=http://www.privatmusikverein.de/]Privatmusikverein Nürnberg e.V. - Veranstalter für Kammermusik-Konzerte in Nürnberg[/url]
    • Ich glaube, ich kann eventuell weiterhelfen. Wir (Campusradio Duisburg-Essen) hatten zusammengefasst das gleiche Problem: Je mehr CPU-Last, desto mehr drop-outs und Kratzer, CPU-Last wurde durch den X-Server erzeugt, z.B. Zoomen oder ein schneller, automatisch scrollender Cursor im Wellenfenster. Ein Wechsel von xfree86 auf xorg brachte sogar eine Verschlechterung, d.h. Kratzer auch bei der Wiedergabe. Ließ man Audacity über ssh getunnelt auf dem hardwaregleichen Nachbarrechner laufen, wurden die Aufnahmen tadellos. Also die xorg.conf von dem Nachbarrechner kopiert und alle Probleme waren weg, selbst härteste Belastungen wie 32-bit float, schnelllaufender Cursor, zoomen und bewegen des Wellenfensters während der Aufnahme und schlechte Musik ließen Audacity unbeeindruckt, dabei stieg die Prozessorlast von X-Prozesse + Audacity teilweise auf 90%. Die beiden xorg.conf unterscheiden sich nur minimal, bei der jetzigen ist der LCD-Monitor eingetragen und die Module "GLcore" und "speedo" fehlen. Ich möchte allerdings nicht bis ins letzte austesten, was es wirklich war, auf Wunsch kann ich aber die funktionierende (und die andere) xorg.conf hier veröffentlichen.