» Veranstaltungen
» Navigation
» über uns
|
-
Zitat:
Zitat von The Alchemist
arecord und brutefir klappt selbstverständlich.
Dann hatte ich wohl etwas falsch gemacht. Aber wie gesagt, ist der Test sowieso unnötig. arecord | aplay beweist ja, dass die hohe Grundlatenz nicht durch Brutefir entsteht.
-
Hallo Nils,
schönes Projekt! Hast du den Kernel mit irgendwelchen "low-latency" oder "real-time" Optionen kompiliert? Unter Linux gibt es mehrere Möglichkeiten die Latenzzeit zu verringern zum Bsp. auch mit der Wahl eine anderen Dateisystems (ich gehe davon aus, dass du ext4 benutzt?)
Cheers,
Mike
-
Zitat:
Zitat von SomeDude
schönes Projekt!
Danke! :)
Zitat:
Hast du den Kernel mit irgendwelchen "low-latency" oder "real-time" Optionen kompiliert? Unter Linux gibt es mehrere Möglichkeiten die Latenzzeit zu verringern zum Bsp. auch mit der Wahl eine anderen Dateisystems (ich gehe davon aus, dass du ext4 benutzt?)
Ich benutze den Standard-Kernel von Debian. Ich habe über diese Optionen auch gelesen, die reden aber nie von Latenzen im Hundertmillisekundenbereich, sondern immer von viel weniger. Ich kann mir nicht vorstellen, dass es an so einer Optimierung liegt. alsaloop schafft das Durschschleifen ja auch in 14 ms ohne spezielle Einstellungen.
Ansonsten läuft Brutefir in Echtzeitpriorität. Es ist egal, ob ich direkt in Brutefir die ALSA-Ein- und Ausgänge benutze oder Jack. Auch mit MPD über die Pipe nach Brutefir und dann mit ALSA raus gibt es diese große Verzögerung. Die ist ja so hoch, dass man sie richtig spürt und in Arta auch sofort an den Ausschlägen sehen kann. Es handelt sich also nicht um die letzten xx ms, die man noch herauskitzeln möchte, sondern um etwas viel Gröberes.
Ja, als Dateisystem habe ich EXT4, aber die Platte wird ja beim Durchschleifen oder Streamen von Netzwerk gar nicht benutzt.
-
Ich denke, ich habe ein Teil des Rätsels Lösung. Aufgefallen ist mir, dass Brutefir mit intern generierten Filtern (Dirac Impuls) eine deutlich niedrigere Latenz aufweist (92 ms). Also geht es grundsätzlich. Es sind also meine Filter, die ich mit RePhase generiert habe. Die habe ich mit der Einstellung "Center" gemacht. Stelle ich das um auf z.B. "20ms", dann sinkt die Latenz auf ca. 112 ms bei einer Filterlänge von 65.536 und 32 Partitionen (also 4094,32).
Die Einstellung "20ms" bewirkt aber anscheinend auch, dass das Filter nicht mehr so genau generiert werden kann. Es ist also ein Kompromiss.
PS: Warum arecord|aplay so eine hohe Latenz hat, weiß ich jedoch nicht. Das ist wahrscheinlich ein anderes Problem.
-
Eines vorweg: Ich habe keinerlei praktische Erfahrung mit Latenzzeiten von Audioanwendungen unter Linux, deswegen kann ich die von dir angegebenen Latenzzeiten nicht bewerten. Ich weiss allerdings, dass es da viele Stellschrauben gibt. Ein Ferndiagnose ist in einem solchen Fall immer sehr "mühsam".
Vielleicht helfen dir ja folgende Links:
http://wiki.linuxaudio.org/wiki/system_configuration
speziell das auf der Seite verlinkte Skript: realTimeConfigQuickScan und die Anwendung latencytop sollten für dich interessant sein und ein eingrenzen der Problematik ermöglichen
Auch nett ist der Eintrag im Arch Linux Wiki zum Thema Pro Audio -> https://wiki.archlinux.org/index.php/Pro_Audio
Falls du die Seiten nicht sowie so schon kennst. Zum Schluss noch zwei Fragen:
Ist BruteFIR eigentlich parallelisiert? Benutzt es openMP oder OpenMPI? Hast du BruteFIR eigentlich selber kompiliert oder über die Paketverwaltung installiert?
Ich finde die Idee einer PC gestützten Weiche auch super, allerdings würde ich gerne auch meinen Plattenspieler anschließen können (der Nostalgie wegen...). Könnte man den Plattenspieler auch an die Soundkarte anschließen? Ein Skript könnte dann die Quellenwahl übernehmen.
-
Zitat:
Zitat von SomeDude
Falls du die Seiten nicht sowie so schon kennst.
Bin ich schon mal drüber gestolpert, aber da die Latenz für meine Anwendung ja nicht wichtig ist, habe ich da keine weitere Zeit investiert. Und der Kernel 4, den ich benutze hat diesen RT-Patch schon integriert. Wenn ich mal Zeit habe, schaue ich mir das aber genauer an.
Zitat:
Ist BruteFIR eigentlich parallelisiert? Benutzt es openMP oder OpenMPI? Hast du BruteFIR eigentlich selber kompiliert oder über die Paketverwaltung installiert?
Ja, Brutefir nutzt Threads und startet so viele wie Kerne vorhanden sind. Deswegen habe ich auch extra einen Vierkerner gekauft.
Ich habe Brutefir über die Paketverwaltung installiert. Es ist aber die neueste Version.
Zitat:
Ich finde die Idee einer PC gestützten Weiche auch super, allerdings würde ich gerne auch meinen Plattenspieler anschließen können (der Nostalgie wegen...). Könnte man den Plattenspieler auch an die Soundkarte anschließen? Ein Skript könnte dann die Quellenwahl übernehmen.
Ja, das geht problemlos. :)
Ich schalte die Eingänge immer auf die analogen um, wenn ich die Kiste mit ARTA messe. Im Moment mache ich das noch per Hand in der Config-Datei. Aber das lässt sich alles mit Scripts automatisieren und Brutefir hat auch ein eigenes SSH-Interface. Siehe hier.
-
Ich hätte da eine Idee, die richtig billig werden könnte.
Neulich habe ich mir einen Odroid XU4 bestellt und damit ein wenig rumgespielt.
Daran würde ich eine Xonar DX über die SPI (oder I²S) Schnittstelle anschließen. Die Soundkarte habe ich noch nicht, ich weiß zwar, dass der C-Media-Chip diese Schnittstellen hat, aber ich konnte keine Information darüber finden, wie leicht man da ran kommt. Praktisch wäre es, wenn das Layout einen Anschluss bereit hält.
Weiß jemand mehr dazu?
-
Inzwischen habe ich den PC soweit optimiert, dass möglichst wenig Prozesse laufen, keine Timer starten und keine Festplattenaktivität mehr stattfindet. Zumindest fast, denn die Prozesse kworker und jbd2 schreiben immer noch alle paar Minuten ein paar kB auf die Platte (herausgefunden mit iotop). Bisher konnte ich nicht herausfinden, warum die das tun. Die meisten Threads im Internet haben mir auch keine Antwort geliefert.
Das Booten hat sich auch noch mal ein bisschen beschleunigt (GRUP Timeout und statische IP-Adresse).
Mit MPDroid auf dem Smartphone funktioniert das Abspielen problemlos. Nur die Lautstärkeregelung muss ich noch hinter Brutefir legen bzw. Brutefir selbst machen lassen. Der Nachteil ist aber, dass das dann nicht mehr über die App gesteuert werden kann. Es sei denn, jemand kennt da einen Trick... :)
-
Ich bin immer noch am Optimieren und heute ist mir eine Merkwürdigkeit an der Xonar aufgefallen. Anscheinend kann der Linuxtreiber die Eingänge nur mit 48 kHz und 16 Bit öffnen. Ich kann zwar arecord mit anderen Sampleraten aufrufen, aber
Code:
cat /proc/asound/card0/pcm0c/sub0/hw_params
zeigt mir immer 48 kHz an. Egal, was ich bei arecord angebe.
Code:
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 16384
Und ich bekomme nur Ton bei S16_LE, auch wenn hier S32_LE angezeigt wird.
Anscheinend findet irgendwo im Treiber ein Resampling statt. Das fiel mir in der Messung auf, die immer einen steilen Tiefpass bei ca. 22 kHz zeigt und schon ab 10 kHz schwach aber deutlich abfällt. Wenn ich arecord direkt mit 48 kHz aufrufe, ist dieser frühe Abfall nicht da (der steile bei 22 kHz bleibt natürlich).
Ausgeben funktioniert aber tadellos mit höheren Sampleraten, das konnte ich mit weißem Rauschen und Realtime Analyzer überprüfen.
Kann das irgendwer nachvollziehen? Wie ist das unter Windows? Ich würde die Karte ungerne ausbauen, um das zu prüfen.
Das Ganze ist für mich jetzt kein Drama. Ich benutze die Eingänge ja sowieso nur zum Messen. Aber auf der Packung steht 192/24 und das möchte ich natürlich auch haben. ;)
-
-
Danke für die Antwort, aber ich benutze PulseAudio gar nicht. Das Problem tritt schon direkt mit dem ALSA-Recorder auf.
-
Pulseaudio wird bei den neuen Linuxen oft einfach als Sound-Server mit installiert und läuft dann immer mit . Selbst wenn man PA von Hand deinstalliert, kann es passieren, dass er sich bei einem Systemupdate wieder mit installiert ....
-
Zitat:
Zitat von The Alchemist
Pulseaudio wird bei den neuen Linuxen oft einfach als Sound-Server mit installiert und läuft dann immer mit . Selbst wenn man PA von Hand deinstalliert, kann es passieren, dass er sich bei einem Systemupdate wieder mit installiert ....
Bei mir ist es nicht installiert. Das habe ich nachgeprüft. Ich habe sowieso schon alle möglichen Prozesse entfernt, die ich nicht benötige.
-
Ich habe mir ein kleines Script geschrieben, das über die Tastatur reagiert und die Parameterdatei von VOLRACE füllt.
Dabei ist zu beachten, dass nur der erste Parameter dieser Datei geschrieben wird. Es funktioniert also nur die Lautstärkeregelung und nicht der RACE-Algorithmus!
Das Script reagiert auf "+" und "-", sowie "m" für Mute. Es arbeitet komplett in Dezibel, die Lautstärkeänderungen werden also linear wahrgenommen. Die oberen und unteren Limits können festgelegt werden, sowie der Standardwert beim Starten des Scripts. Letzteres ist sinnvoll, um einen definierten Wert beim Einschalten zu erhalten.
Man könnte das Ganze nun mit einer Funk-Tastatur oder mit einer Fernbedienung steuern. Das sollte kein Problem sein.
Die Ausgabe bei Änderungen auf der Konsole ist bezogen auf 0 dB. Das entspricht dem Verstärkungsfaktor 1,0. Lauter als 1,0 geht natürlich auch, ist aber nur sinnvoll, wenn man eine sehr leise Aufnahme hat, die garantiert nicht clippt.
Beispielausgabe:
Zitat:
...
-30.0 dB
-28.0 dB
-26.0 dB
Mute
-26.0 dB
...
Code:
#!/bin/bash
# user variables
volFile=/tmp/volume
stepSize=2 # in dB
upperLimit=0 # in dB
lowerLimit=-100 # in dB
defaultVal=-30 # in dB
# converts a given dB value into a amplification factor
function ConvertdBToFactor {
local result=$(echo "scale=20;e(l(10) * $1 / 20)" | bc -l | awk '{printf "%.20f", $1}')
echo "${result}"
}
# intern variables
oldVal=0
oldValMute=""
newVal=$(ConvertdBToFactor $defaultVal)
factor=$(ConvertdBToFactor $stepSize)
upperBound=$(ConvertdBToFactor $upperLimit)
lowerBound=$(ConvertdBToFactor $lowerLimit)
# ouputs new value to console and to volume file
function Output {
if [ $(echo "scale=20;${newVal} == 0" | bc) -eq 1 ]; then
echo "Mute"
else
echo "scale=20;20 * l(${newVal}) / l(10)" | bc -l | awk '{printf "%.1f dB\n", $1}'
fi
echo "${newVal}" > $volFile
}
# set default value
Output
# main loop for key input
while true
do
read -s -n 1 key
case $key in
'-') oldVal=$(cat $volFile)
newVal=$(echo "scale=20;if(${oldVal} / ${factor} < ${lowerBound}) ${lowerBound} else ${oldVal} / ${factor}" | bc | awk '{printf "%.20f", $1}')
Output
;;
'+') oldVal=$(cat $volFile)
newVal=$(echo "scale=20;if(${oldVal} * ${factor} > ${upperBound}) ${upperBound} else ${oldVal} * ${factor}" | bc | awk '{printf "%.20f", $1}')
Output
;;
'm') if [ -z "$oldValMute" ]; then
oldValMute=$(cat $volFile)
newVal=0
else
newVal=$oldValMute
oldValMute=""
fi
Output
;;
esac
done
Ich habe VOLRACE hinter Brutefir eingebunden. Die ganze Signalverarbeitung wird in 64 Bit Gleitkommazahlen durchgeführt. Genauer geht eine digitale Lautstärkeregelung also kaum.
Das Script macht mir das Leben schon viel leichter. Vielleicht ist es ja auch für den einen oder anderen interessant. :)
-
Gute Neuigkeiten: das Aufnahmeproblem ist gelöst! :dance:
Man muss bei "arecord" zwingend das Sound Device angeben, ansonsten wird "dsnoop" aktiviert und immer auf 48 kHz /16 Bit konvertiert, falls mehrere Quellen gleichzeitig aufnehmen wollen! Das habe ich auch nur erfahren, weil ich den Entwickler von dem Xonar-Treiber gefragt habe. In einer Dokumentation konnte ich dieses "Feature" nicht finden.
Und ich musste das Device nie explizit angeben, weil ich ja nur eines eingebaut habe (Onboard ist deaktiviert).
Naja, jetzt klappt auf jeden Fall auch 192 kHz / 32 Bit. ;)
Ansonsten habe ich mir drei PCM1792A bestellt und werde die demnächst auf die H6-Erweiterungskarte einlöten. Dann haben alle Kanäle denselben Wandler und dieselbe Verzögerung. Ich berichte natürlich, ob das SMD-Löten geklappt hat.
|
