[woody]

Zitat:Original geschrieben von voltwide

Tjaaa, früher war das einfacher, da nahm man einfach ubuntu und alles war ok.
Inzwischen weiß ich auch kaum noch, was ich nehmen soll:
debian: zwar stabil, aber sehr restriktiv hinsichtlich proprietärer Sw, also nix für Multimedia out of the Box
ubuntu: unity-Desktop ist völlig inakzeptabel, da kann ich ja gleich zu Win8 wechseln.
mint: noch am ehesten, scheint aber nicht wirklich ausgereift
usw usf

Ja das ist das Problem mit Freier Software. Jeder kann machen was er will und keiner blickt mehr durch. Daher bin ich wieder zurück zu Windows (als Win7 rauskam).
Nach dem ich lange Zeit auf ein extrem wartungsintensives aber unglaublich individuelles Gentoo schwörte, habe ich verschiedene Distributionen probiert. Mint fand ich noch am besten.

Aber aktuell? Ich sehe keine wirkliche Alternative zu Win7 - leider.

[voltwide]

Zitat:Original geschrieben von Black_Chicken

Ich habe mich wegen der umfassenden paketquellen (gute verfügbargkeit) für die ubuntu-plattform entschieden. Unity ist nicht der hit, läuft aber auf meinem x200 erstaunlicher Weise extrem flüssig. Aber du kannst ja immer noch zu gnome3 oder gnome-classic zurückkehren....

Ich hab mal gelesen, dass Ubuntu in der Standard-Konfiguration grundsätzlich eine Sample Rate Konvertierung durchführt (in software). Was ist da dran?

Das hab ich noch nicht gehört, da fehlt jetzt auch der Kontext, sprich welche Tonquelle (mit welcher samplerate) abgespielt wird über welche Tonausgabe (mit welcher samplerate)...
Wenn man eine 44,1kHz CD mit einer 48khz soundkarte abspielt, wird man wohl um die Konvertierung nicht drum rum kommen.

[voltwide]

Inzwischen habe ich mich durch Berge unverständlicher man-pages und irrelevanter google-Treffer gewurstelt, und weiß nun sicher, dass sound unter Linux eher was für die Harten ist.
So langsam kommt aber Land in Sicht.
Meine halb-virtuelle Meßkette besteht jetzt aus den "Atomen"

Soundkarte: intern oder extern
Alsa: Audiotreiber
SOX: Audiostreamer mit AudioFilter und Dateiformat-Umsetzer
FeedGnuPlot: streamfähiger Diagramm-Generator

Das beginnt zu funktionieren und dürfte eine sehr flexible Basis für allerlei Audiomessung werden. Eine toolbox, die ich schon immer haben wollte.

Sox ist unter allen Plattformen verfügbar, es ist also durchaus denkbar das hier auch nach Windows und Mac OSX zu portieren. Aus dem bash-scripten werden dann batch-Dateien.

[voltwide]

Der aktuelle Stand der Dinge



Wie man sieht, haben die beiden CPU-Kerne schon was zu tun!
Den Löwenanteil belegt hierbei die plot-Ausgabe, vlt kann ich da noch etwas tunen

[Rumgucker]

Ich finde das so geil, was Du da treibst. Man könnte fast glauben, dass Du bzgl. der "Box 13" sowas ähnliches wie "Mitdenken" hinbekommen hast...

[voltwide]

Die Sache mit dem PC-sound treibt mich schon ziemlich lange um. Vor Jahren habe ich es mit dem "Mataa"-projekt (+Gnu Octave +GnuPlot) probiert, war mir aber auf Dauer alles zu unhandlich. Mein Ziel war die Verarbeitung eines Datenstromes durch eine Reihe von Filtern oder sonstigen Funktionen innerhalb einer pipeline von verketten Prozessen.

Das was Du da siehst, ist also ein frei konfigurierbares Soundkarten-Oszilloskop. Und auch nur die Spitze des Eisberges. Schleust man den Datenstrom zusätzlich durch den Matlab-Clone Octave hindurch, sind beliebige mathtematische Filteroperationen (FFT...) auf dem Datenstrom möglich.
Gnuplot an sich ist, ebenso wie audacity, nicht geeignet als Prozeß innerhalb einer streaming-Kette. Dafür habe ich nun "FeedGnuPlot" als streaming frontend für GnuPlot entdeckt: Das war der Baustein, der noch fehlte!

Das zugehörige Shell-Programm umfaßt übrigens ganze 2 Zeilen:
Die Auswahl der Soundkarte und die Audio-Prozesskette.
Fast eine Woche habe ich dafür gebraucht!

[Black_Chicken]

Moin!

ich habe noch keine zeit gefunden mich weiter mit linux+sound auseinanderzusetzen.

Das Wochenende habe ich viel mit MATAA unter win7 herumgespielt (lustig, dass Du es gerade jetzt erwähnst). Mit Matlab läufts super, mit Octave3.2 krieg ich noch einen Fehler von der reshape() Funktion... keine Ahnung was da schon wieder schief läuft . Als nächsten Schritt möchte ich ganz auf Linux+Octave3.6 umsteigen. Oder sollte ich besser die Finger davon lassen?

Den Vorteil von MATAA sehe ich darin, dass alles über 1 script abgehandelt wird. Also Messung + Auswertung + Aufbereiten der Messdaten. Im Moment messe ich noch hauptsächlich mit ARTA, STEPS und LIMP. Die Messdaten werden dann exportiert und mit numpy/scipy/matplotlib weiterverarbeitet. Das ist leider ein bisschen umständlich.

[voltwide]

Zitat:Original geschrieben von Black_Chicken

Moin!

ich habe noch keine zeit gefunden mich weiter mit linux+sound auseinanderzusetzen.

Das Wochenende habe ich viel mit MATAA unter win7 herumgespielt (lustig, dass Du es gerade jetzt erwähnst). Mit Matlab läufts super, mit Octave3.2 krieg ich noch einen Fehler von der reshape() Funktion... keine Ahnung was da schon wieder schief läuft . Als nächsten Schritt möchte ich ganz auf Linux+Octave3.6 umsteigen. Oder sollte ich besser die Finger davon lassen?

Den Vorteil von MATAA sehe ich darin, dass alles über 1 script abgehandelt wird. Also Messung + Auswertung + Aufbereiten der Messdaten. Im Moment messe ich noch hauptsächlich mit ARTA, STEPS und LIMP. Die Messdaten werden dann exportiert und mit numpy/scipy/matplotlib weiterverarbeitet. Das ist leider ein bisschen umständlich.

Die Möglichkeit, so etwas über scripte zu steuern/automatisieren ist das was für mich den Reiz an der Sache ausmacht. Nach anfänglicher Euphorie hat die eingehendere Überprüfung noch heftige Probleme aufgeworfen.

Sox, bzw diese ganze Digital-Audio-Verarbeitung, muß ich erstmal besser durchdrungen haben. Die graphische Ausgabe ist dann noch mal eine extra-Baustelle. Und die damit verbundene Prozessorlast.

So produziere ich momentan winzige Programmschnipsel, die ich der Reihe nach auf ihre tatsächliche Funktion überprüfe und dokumentiere. Mit anderen Worten stehe ich noch in den Anfängen, bin aber an der Sache dran und werde in absehbarer Zeit auch Resultate präsentieren können.

[voltwide]

Ein direktes Aufnehmen des Systemklanges klappt bei mir nicht.
Dazu müsste man an den Monitorausgang der Soundkarte abgreifen -
sofern sie den überhaupt hat.
Die tools dazu erfordern pulseaudio -
das aber funktioniert bei mir nicht in Verbindung mit der Behringer Soundkarte.

Andererseits brauche ich diesen SignalWeg garnicht unbedint, solange ich mit "rec" ( sox ) resp "arecord" (ALSA) auf den Eingang meiner soundkarte zugreifen kann.

Ob octave eine Option darstellt, den Datenstrom zu Gnuplot zu reduzieren, weiß ich noch nicht. Das hängt davon ab, ob/wie man es in die streaming-pipe eingebaut bekommt.

[Black_Chicken]

Gestern hab ich gleich mal einen Versuch gestartet mit Ubuntu+Octave3.6+MATAA. Meine Soundkarte (Edirol UA1) wird vom System erkannt, aber die kommunikation zwischen Octave und der Soundkarte über Testtone läuft überhaupt nicht (war ja zu erwarten).

Da ich aktuell mal wieder zeitlich recht knapp bin ist hier erstmal schluss, die Lösung mit Arta funzt ja...

Das Thema linux+sound ist jedenfalls sehr spannend!

Wünsche viel Erfolg!

[voltwide]

Ja, Linux+Sound, das allein genügt für die einsame Insel!

[voltwide]

Hier wäre denn mal ein vorzeigbares bash-script, mit doku:

#! /bin/bash
export AUDIODEV="hw:CODEC,0"

sox --buffer 200 -r 4k -d -t dat - | tee x.dat | feedgnuplot --lines --stream --xlen 1 --domain --ymax 1 --legend 0 "linker Kanal" --title "Behringer U202: input L: Fsine=1030Hz Vsine=3,6Vss Fs=8kHz -> PlotData -> Plot" --y2 2 #--extracmds "set logscale yy2 10"
exit
------- ende des codes

Details

Vorab per Umgebungsvariablen die ext Soundkarte wählen

1.Prozess - Audiodaten aufnehmen von Soundkarte Behringer U202

Signal an line-in, links: Sinus 1kHz, 3,6Vpp
Signal an line-in, rechts: Stille
Sox
--buffer 200 verkürzte Reaktionszeit
-r 4k down sampling von 48KHz auf 4kHz zur CPU-Entlastung
-d Eingabedatei ist das Audio Default Device: sox ist im RealTime-play modus
-t dat konvertiere auf das Plotdateiformat, dh. eine Textdatei formatiert zu 1.Spalte=Zeit(s) 2.Spalte=Signal1 3.Spalte=Signal2
- Ausgabedatei des streams ist STDOUT

2.Prozess Datei speichern
tee i/o Gabelung des streams 1) STDOUT 2) Abspeichern auf Datei

3.Prozess 1x/sec Graphische Ausgabe des streams
feedgnuplot
--lines Punkte mit Linien verbinden
--stream stream plot
--xlen 0.01 x-Breite 0,01sec/Bild
--domain 1.Spalte ist x-Achse = sec
--ymax 1 Skalierung y-Achse max=1,0
--legend 0 Beschriftung y0
--title Überschrift
--y2 2 Y2 = Spalte2 des Datenstromes

System Lenovo X200 DualCore, LinuxMint15/64bit

CPU-Last 2x 45..55% @fs=8kHz xlen=0,01
CPU-Last 2x 70..100% @fs=8kHz xlen=1
CPU-Last 2x 60..85% @fs=4kHz xlen=1

Kritik

Die PlotAusgabe ist derartig resourcenhungrig, dass die Abtastfrequenz auf 4-8khz begrenzt ist.
Abhilfe verspricht ein aufs Notwendigste begrenzter Datenstrom - evtl mit Hilfe von GNU-Octave.

[Rumgucker]

Och nö. Das ist ja ne Linux-Antiwerbung!

[voltwide]

Habe mich nun von dem Gedanken getrennt, das als bash-script zu realisieren - das ist einfach zu resourcenfressend.
Also kommen Hochsprachen in Betracht.
Z.B. Python,
Als Ausgangspunkt der Code für ein Komplettes soundkarten-Oszilloskop
lauffähig unter Windows, Linux, MAC-OSX

Quelldatei "Oscilloscope-v01a.pyw" herunterladen von
http://www.qsl.net/pa2ohh/11oscilloscope.htm
und aus dem Archiv expandieren.

Im Einzelnen, speziell für Linux...

Der Text ist unter Windows erstellt, deshalb
DOS Zeilenenden ersetzen durch UNIX-Zeilenenden und 1.Zeile einfügen:
#! /usr/bin/python2.7

Weiter in der Linux - Kommandozeile (bash)

$ sudo apt-get install python2.7 # fehlende Programmpakete installieren
$ sudo apt-get install python-pyaudio
$ sudo apt-get install python-tk
$ sudo apt-get install idle-python2.7
Wechseln in das Verzeichnis des Python-Scriptes
$ chmod a+x Oscilloscope-v01a.pyw #python-script ausführbar machen
$./Oscilloscope-v01a.pyw # Programmstart

- und läuft!

[alfsch]

[voltwide]

Ich arbeite mich so langsam durch das Python Script hindurch.
An die Sprache kann man sich schnell gewöhnen, die meisten Konstrukte sind altvertraut aus verschiedenen Ecken.
Mit dem Programmierstil des Verfassers läuft es umgekehrt: Je mehr ich verstehe, desto weniger gefällt er mir ;deal2

[Rumgucker]

[sup]...das ging mir bei Deinem Programmierstil auch so....[/sup]

[voltwide]

Tja, Du bist eben irgendwie
anders!