Linux-Optimierung für die Wiedergabe digitaler Audiodaten

Melomane
Aktiver Hörer
Beiträge: 3114
Registriert: 14.10.2011, 18:30

Beitrag von Melomane »

Hallo Simon,

Arch wäre mir zu sehr "im Fluss". Lieber etwas Konservatives wie Debian. Dann müsste man nicht so oft die Anweisungen updaten. Debian bekommt man recht klein, wenn man bei der Installation tasksel links liegen lässt. Dann ist erstmal nichts an Board, kein X, kein alsa, kein vim, nicht mal ein less. So zumindest meine schon etwas länger zurückliegenden Erfahrungen. Vielleicht ist das heutzutage anders. Hm, vielleicht sollte ich mal wieder...

Gruß

Jochen
Bild
Tinitus
Aktiver Hörer
Beiträge: 1322
Registriert: 10.11.2013, 21:48

Beitrag von Tinitus »

Hallo Simon,

:cheers: . Auch wenn ich persönlich nur den Spaß an der Freud mit beitragen werden kann, so finde ich deine Idee spitze. Arch Linux war auch für mich erste Wahl, weil es schlank ist und weil es Frank empfohlen hatte. Wenn ich es richtig weiß, kann man eine GUI nach installieren, so dass auch diejenigen, die dies bevorzugen auf ihre Kosten kämen. Als Linux Newbie kann ich nur sagen, dass Arch Linux mich nicht uberfordert hat. Ich konnte bei meiner Arch Installation Wifi mit statischer IP per netctl problemlos einrichten, auch die fstab habe ich hin bekommen. Mit noatime und nodiratime auch schon mit manchen Einstellungen, um die SD- und eMMc-Karten zu schonen. Symbolische Links um mehrere Datenträger in einem Verzeichnis unterzubringen bekomme ich auch schon hin. Im Moment habe ich eine lauffähige Volumio-Karte bei der ich die eMMc eingefügt habe und die RAMdisk vergrößert habe, so dass ich die meisten redbook Alben aus dem RAM spielen kann. Die andere karte ist eine RuneAudio Version. Die habe ich versucht mir selbst zusammen zu basteln, weil sie für C1 nicht fertig erhältlich ist, bin aber letztlich gescheitert. RuneAudio wollen in der Zukunft ein Packagebuid veröffentlichen, welches einem erlaubt, RuneAudio auf alle möglichen Plattformen zu portieren. Meine dritte karte ist mein persönliches Arch Linux, bei dem ich noch nicht entschieden habe, wie ich Audio implementiere (alsa, sox?, jack?). Außerdem habe ich noch eine brutefir version, die auch auf meinem C1 laufen sollte. Da ich das umstecken der karten und die damit verbundene Entscheidung Fummeln oder Musik Hören satt war, ist der zweite C1 bestellt. Einer zum Musik Hören mit Volumio einer zum Experimentieren :) . Dann könnte ich eventuell auch Franks zwei Computer set up verwirklichen. Im RuneAudio forum berichtet jemand davon, dass er RuneAudio mit brutefir auf dem Pi 2 laufen läßt, dann sollte das ein C1 auch können. Warum ich mich mit Volumio nicht zufrieden gebe? Ich mag es nicht, wenn meine Festplatte ständig läuft. Deshalb kopiere ich die Musik in die RAMdisk oder bei HiRes auf die eMMc (per Konsole übers iphone). Irgendwann habe ich kapiert, dass ich mpd dann gar nicht brauche, da im verzeichnis aus dem ich die Musik auslese eh immer nur das Album ist, welches ich hören möchte. Auf der anderen Seite möchte ich auch nicht unbedingt eine viertel Stunde auf der Konsole rumhacken müssen, bevor der erste Ton aus den LS kommt.
Zumal die Konsole einen nachteil hat, sie zeigt mir für Umlaute und Dinge wie è bzw è nur murks an. Ich ahbe zwar dann ein Tool laufen lassen, das die unter Windows eingerichtete HDD auch nach Linux Codierung funkionieren lässt, dass funktioniert auch in soweit, als der Dateiname zum Beispiel wirklich Édith Piaf lautet und cp -R "Édith Piaf" /mnt/shm auch funktioniert, aber es wäre schon schön wenn nach ls -l | less in der Konsole auch Édith Piaf statt <G3 >dith Piaf (oder Ähnliches) gelistet würde. Das sind alllerdings Details, die mich nicht abschrecken. In diesem Sinne, ich bin dabei, wenn auch eher als fast follower :oops:

Beste Grüße

Uwe
Bild
huscape
Aktiver Hörer
Beiträge: 55
Registriert: 06.02.2015, 07:01

Beitrag von huscape »

Lieber Jens liebes Forum,
Eunegis hat geschrieben: Wie auch immer, habt Ihr Kenntnis vom Projekt "Audiophile Linux"?:
http://www.ap-linux.com/
Ich habe mich nicht sehr viel mit AP-Linux beschäftigt. AP-Linux ist weniger eine Distribution, als vielmehr die Anpassung einer Installation nach dem Gusto des Anbieters und die Erstellung eines OS-Images, dass zur Installation angeboten wird. Das beinhaltet naturgemäß einiges an Nacharbeiten und Überprüfungen nach Aufspielen eines solchen Images.

Da kann ich mir auch gleich die Distribution meines Vertrauens schnappen und diese entsprechend anpassen.

RedHat Linux bzw. Fedora halte ich für geeignet zum Aufbau eines Audio-PCs. Mit dem LXDE-Spin existiert bei Fedora eine Paket-Zusammenstellung, die für mich schlank genug ist. Mich stören aber auch unbenutzte Pakete nicht sonderlich. Wäre es anders könnte man einen eigenen Spin in Fedora definieren, der dann eine noch minimalere Installation als Resultat hätte.

Linux-Instalationen für die unterschiedlichsten Anwendungszwecke sprießen wie Pilze aus dem Boden. Es ist für jeden etwas dabei. Wenn man sich für eine Distribution entschlossen hat, kann man dann nur die Daumen drücken, dass der Maintainer seine Arbeit fleissig fortsetzt und sich nicht irgendwann dazu entschließt lieber etwas anderes zu tuen. Dies ist ein weiterer Grund für mich auf Fedora zu setzen.

Mit den Leuten von der Stanford-University existiert eine Community, die seit längerem RedHatz im Rahmen ihrer Arbeit mit Computern und Audio verwendet und Instalationspakete fleissig pflegt ("It replicates most of the Linux environment we have been using for years here at CCRMA for our daily work in audio and computer music production and research"). Noch ein Grund für mich bei diesem Projekt Fedora zu verwenden.

Wichtig finde ich dann noch die "Lebenszeit" einer Installation. Wie lange dauert die Patchversorgung an und wie gestaltet sich ein Releasewechsel. Im Falle von Fedora (selbstverständlich auch bei allen Debinähnlichen, schließlich ist das u.A. deren Hauptfocus) ist das sehr gut gelöst. Mit der Verwendung von Repositories zur Softwareinstalation, "yum update" als Updatemechanismus und "fedup" für die Releasewechsel, stehen Mechanismen bereit, die helfen eine Installation jahrelang auf einem modernen Stand zu halten.

Eine "wirkliche" audiophile Distribution wäre ein schönes Projekt. In Fedora ließe sich dies über einen eigenen Spin realisieren. Konfigurationsanpassungen auf unterschiedliche Hardwareumgebungen über Kickstarts evtl. sogar mit Puppet / Foreman zentral verwaltet ... (hey ... ich philosophiere nur so vor mich hin ... ich meine das nicht ernst) ...
Aber wie gesagt ... das muss man dann auch pflegen ... will man das?

Liebe Grüße, euer Hans
Bild
Melomane
Aktiver Hörer
Beiträge: 3114
Registriert: 14.10.2011, 18:30

Beitrag von Melomane »

Guten Morgen allerseits,

das Problem einer audiophilen Distribution beginnt ja schon damit, dass es kein einheitliches Verständnis davon gibt, was das eigentlich sein soll. Der eine definiert die als möglichst abgespeckt, der andere als Basis einer Muliroom-Lösung, wieder ein anderer als für die Aufnahme oder Digitalisierung seiner Vinyl-Schätze optimiert. Bei allen Ansätzen bedarf es individueller Lösungsansätze. Letztlich führt meiner Meinung nach kein Weg daran vorbei, sich selbst in die Materie Linux einzuarbeiten und dann für sich das Optimum zu stricken. Dabei helfen solche threads wie dieser ungemein, um die nötigen Anregungen und Tipps zu bekommen. Hier haben dann auch (anpassbare) Scripts eine vorzügliche Heimat.

All-Inclusive-Ansätze wie z.B. Volumio haben natürlich auch ihre Daseinsberechtigung, sind aber nicht wirklich optimiert. Ob die dann ausreichen oder nicht, kann man nur - ein jeder für sich - ausprobieren und dann beurteilen. Der Zeitfaktor ist dabei ja auch nicht zu vernachlässigen. Aber das gilt ja für einen jeden Versuch zu optimieren, wie wir nur allzu gut wissen. ;)

Gruß

Jochen
Bild
Daihedz
Aktiver Hörer
Beiträge: 793
Registriert: 25.06.2010, 15:09

Beitrag von Daihedz »

Hallo in die Audio-Linux-Runde

Ich hinterfrage zwischenzeitlich meinen Vorstoss: Noch ein weiterer, spriessender Pilz? Skripte, welche auf der Distro yx geschrieben wurden und auf xy dann doch nicht laufen? Religionskriege (Fedora vs. Arch vs. Debian vs. Gmulspistri vs. Trieana vs. ...)?

Ich nehme deshalb meinen in begeisterter Euphorie erdachten Vorschlag einer forumseigenen Installationssammlung zurück. Stattdessen möchte ich anregen, wie bis anhin und ausgehend von den von Hans mit diesem Thread eingebrachten Informationen eine knowldegde-base in Sachen Linux-Audio weiter aufzubauen und zu weiter zu pflegen, in der Hoffnung, dass möglichst viele Forenten die sich darin ansammelnden Tips ausprobieren und validieren können.

Und das ist ja mit diesem Thread schon in bester Entwicklung begriffen...

Simon
Bild
huscape
Aktiver Hörer
Beiträge: 55
Registriert: 06.02.2015, 07:01

Beitrag von huscape »

Lieber Simon,

Dein Vorschlag mit der Knowledge Base gefällt mir ausgezeichnet. Evtl. wäre hierzu ein Wiki, parallel zum hier verwendeten phpBB-Forum ein geeignetes Werkzeug.

Liebe Grüße, Hans
Bild
Sire
Aktiver Hörer
Beiträge: 309
Registriert: 02.12.2013, 14:01

Beitrag von Sire »

Hallo und Guten Morgen,

ich hatte mir auch schon so meine Gedanken gemacht, und dachte dass ein Wiki (Knowledge Base) mit angehängter Script-Sammlung der geeignete Weg sein könnte. Wie ich sehe, ist der Gedanke schon geboren.

Es sind die Architekturen, die von den Forenteilnehmern verwendet werden, doch auch sehr unterschiedlich. Manche nutzen klassisch x86-Systeme andere wieder ARM-Prozessoren. Der eine mag/nutzt archLinux, Fedora oder gar kleine angepasste Distros, wie zb. PiCore, die komplett im RAM laufen. Für manche ist ein X-Server notwendig, andere bevorzugen einen headless-Ansatz. (Da kommt einiges an Wissen aus der Linux-Vielfalt zusammen). Eine einzige eigene Distro zu zimmern und pflegen, die diesen unterschiedlichen Bedürfnissen gerecht wird, scheint mir zwar nicht unmöglich, würde aber viel an Ressourcen binden. Und diese Ressourcen wären dann meiner Meinung nach besser in leicht verständlichen und fachlich fundierten Anleitungen besser genutzt.
Deshalb würde ich auch für die Knowledge Base, eventl. als Wiki, mit angehängter Script-Sammlung plädieren.

Dann dürfte es auch für Anfänger möglich sein, eine gute Linux-Audio-Lösung nach eigenem Gusto, optimiert auf die eigenen Bedürfnisse zu installieren. (Wenn ich mir anschaue, wieviel Zeit und Energie die Windows-Fraktion in die Optimierung von Rechner und Betriebssystem steckt, dann erscheint mir Linux im Grunde einfacher).
Aber auch für Fortgeschrittene wäre es imho interessant. Meiner Erfahrung nach kann man doch immer nur dazulernen.
Für die Cracks wäre es möglicherweise deshalb vorteilhaft, da sie aus den Rückmeldungen der Nutzer weitere Erkenntnisse gewinnen könnten.

Hoffnungsvolle Grüße

Klaus
Bild
Eunegis
Aktiver Hörer
Beiträge: 134
Registriert: 17.11.2012, 19:53

Beitrag von Eunegis »

Hallo Leute,

Wenn ein Newbie wie z. B. ich (und vielleicht so manch anderer, der noch nicht aus der Deckung gekommen ist) da rangeht wäre es hilfreich, ein gemeinsames "Mutterschiff" zu haben, von dem aus die Jäger dann starten. Will heißen: wenn man sich auf eine Distro einigen könnte, in die sich der Newbie dann einarbeiten kann, wäre das besser, als wenn lauter Wikis für unterschiedliche Plattformen existierten, die dann am Ende doch nur wieder für Experten geeignet sind. Für diese eine Distro könnte man dan die Wikis schreiben, die das System runterstrippen, um es dann sukzessive und nach Bedarf modular wieder aufzupimpen.

Wenn das nicht konsensfähig ist, könnte man aber auch mehr als eine Schiene laufen lassen, meinetwegen eine für Fedora und eine für Debian oder Arch, und für alle Wikis/Skripte erstellen. Man müßte sie nur sauber trennen (eigene Threads), damit wirklich jeder das überblicken kann. Dann muß man halt hoffen, daß mehrere Schienen nicht die Recourcen (Manpower) zu sehr ausdünnen. Eine zu breite Front hat noch immer zum Untergang geführt. Andererseits hätte man dadurch auch die Option, auf der jeweils anderen Schiene zu "spicken", was die Experten dort schon realisiert haben, um es dann zu portieren. So könnte man vielleicht mehr Experten motivieren und einbinden.

Also: eine oder mehrere? Ich wäre auf jeden Fall froh, wenn die Dinge auch für Einsteiger machbar wären und würde daher die Experten bitten, einen kleinen Teil ihrer Phantasie für ebenjene Einsteigerperspektive aufzuwenden. Ich wäre im Gegenzug bereit, meine Unkenntnis uneingeschränkt zur Verfügung zu stellen und die Fußvolkprobe für alles Mögliche zu machen, so daß man am Ende das besondere Gütesiegel "Dummy approved" vergeben könnte. Immerhin... :mrgreen:

HG,
Jens
Bild
huscape
Aktiver Hörer
Beiträge: 55
Registriert: 06.02.2015, 07:01

Beitrag von huscape »

Lieber Jens,
Dein Bedürfnis einen einfachen Weg mit Linux zu einem passenden und gut klingenden Musiksystem zu finden, finde ich sehr nachvollziehbar.
Tatsächnich handelt es sich bei diesem Forum bisher um eine Plattform zum gegenseitigen Austausch. Soll mehr daraus werden, müssen genügend Menschen aktiv daran mitarbeiten. Wenn im Forum also ausreichend viel in diese Richtung diskutiert wird, so wächst die Wahrscheinlichkeit, dass eine solche Entwicklung in Gang gesetzt wird.
Mit meinem Beitrag wollte ich eine bauanleitungartige Beschreibung dessen mit euch teilen, wass es für mich bedeutete, ein passendes System zu realisieren. Für mich war es wichtig Anregungen zu erhalten um dieses Setup weiter zu verbessern. Hinweise wie die z.B. von Frank und Simon helfen mir dabei.
Um konkret zu werden ... falls Du Lust hast ein Setup wie das von mir beschriebene auf einem Testrechner auszuprobieren, stehe ich Dir gerne (natürlich auch jedem Anderen) per PM, E-Mail, Telefon oder persönlich zur Verfügung. Auf die Art und Weise fällt dann auch auf, was für den Linux-Laien wenig verständlich an solchen Computermanuals ist und wie man es besser formulieren kann.
Falls einmal ein Wiki enstehen sollte muss jemand den Anfang machen und später müssen genügend Leute daran teilnehmen. Ganz ohne redaktionellen Teil geht es auch bei einem Wiki nicht und es muss Menschen geben, die sich dafür verantwortlich fühlen. Kein weiter Weg ... aber auch kein kurzer ...
Lieber Gruß, Hans
Bild
Daihedz
Aktiver Hörer
Beiträge: 793
Registriert: 25.06.2010, 15:09

Beitrag von Daihedz »

Hallo Audio-Linuxer

Die Linux Foundation hat ein Real-Time Linux (RTL) Collaborative Project ins Leben gerufen, und neben Altera, ARM, Google, Intel, IBM, National Instruments, Texas Instruments and others macht auch OSADL ab sofort dort mit: http://www.linuxfoundation.org/news-med ... time-linux.

Das ist für Linux eine sehr gute Nachricht. RT-Fähigkeiten sind zwar fürs Wohnstubenaudio sicherlich nicht nötig und heizen bloss unsere Sommerabende zusätzlich noch etwas auf. Aber eine solche Zusammenarbeit von industriellen Elefanten wie TI, NI und IBM ist schon ein Commitment für Linux. Und "wir ganz Kleinen" können weiterhin optimistisch-zukunftsträchtig Linux zu optimieren versuchen.

Solchermassen ermutigt, habe ich nun eine konkrete Frage zu einer Audio-Linux-Optimierung in einem Mehrkern-CPU-System. Nehmen wir an, wir hätten ein (abgespecktes) Audio-Linux-Basissystem, in welchem der Audiostrom mittels einer Pipe einige Programme durchläuft:

Audiodatei -> cptoshm -> shmcat -> sox -> volrace -> brutefir -> sox -> playhrt/aplay -> Soundkarte

Man könnte nun zwei unterschiedliche Strategien fahren:

Strategie 1: Wir verteilen die Rechenlast aller Programme möglichst gleichmässig auf alle Prozessorkerne (sodass der notwendige CPU-Takt relativ klein gehalten werden kann, mit allen sich daraus ergebenden Vorteilen).

Strategie 2: Wir verfolgen selektiv für die Audio-Bearbeitung einen Quasi-RT-Ansatz. D.h. wir befreien zunächst einen Prozessorkern möglichst vollständig von allen Nicht-Audio Lasten (z.B. also von Systemverwaltungsprozessen), und lassen danach nur noch die Audioprogramme auf diesem zuvor "befreiten" Prozessorkern laufen, dies mit durchwegs hohen Prioritäten. Das geht natürlich nur solange, als dieser eine "Audio-Kern" denn auch die ganze Audio-Prozesslast bewältigen kann. Das könnte (Irrtum vorbehalten) in einem PC mit einer 4-Kern-CPU gemäss https://www.dpunkt.de/leseproben/3864/6 ... -Basis.pdf z.B. so erfolgen:

1. Zuerst wird ein Prozessorkern temporär abgeschaltet (Das Abschalten der Kerne No. 1, 2 oder 3 funktioniert meistens. Kern No. 0 jedoch wird in der Regel nicht abgeschaltet werden können). Damit erfolgt eine automatische und sofortige Umverteilung aller bisherigen Prozesse dieses Kernes auf die 3 aktiv verbleibenden Prozessorkerne.
# echo "0" > /sys/devices/system/cpu/cpu3/online
Kern No.3 ist nun abgeschaltet.

2. Unmittelbar vor dem Start der Audioprogramme wird der zuvor abgeschaltete Prozessorkern wieder aktiviert.
# echo "1" > /sys/devices/system/cpu/cpu3/online
Kern No.3 ist nun wieder verfügbar, ist jedoch von der bisherigen Prozesslast befreit.

3. Sofort nach dem Wiedereinschalten von Kern 3 werden die einzelnen Audioprogramme aufgestartet und selektiv dem Kern No.3 zugewiesen, dies mit einer sehr hohen Priorität.
# chrt -r 91 taskset -c 3 cptoshm ... ; chrt -r 92 taskset -c 3 shmcat ... | ... | chrt -r 98 taskset -c 3 brutefir ... | chrt -r 99 taskset -c 3 playhrt ...

Ich frage nun in die Runde: Welche der beiden Strategie ist vorzuziehen? Vielleicht gibt es im Forum eine Erfahrungs- resp. Wissensbasis dazu.

Beste Grüsse
Simon
Bild
Daihedz
Aktiver Hörer
Beiträge: 793
Registriert: 25.06.2010, 15:09

Beitrag von Daihedz »

Ooops!

Das zweite sox in der Pipe
Audiodatei -> cptoshm -> shmcat -> sox -> volrace -> brutefir -> sox -> playhrt/aplay -> Soundkarte
ging in meinem bash-Beispiel verloren:
Daihedz hat geschrieben: # chrt -r 91 taskset -c 3 cptoshm ... ; chrt -r 92 taskset -c 3 shmcat ... | ... | chrt -r 98 taskset -c 3 brutefir ... | chrt -r 99 taskset -c 3 playhrt ...
Sollte richtig heissen:
# chrt -r 91 taskset -c 3 cptoshm ... ; chrt -r 92 taskset -c 3 shmcat ... | ... | chrt -r 97 taskset -c 3 brutefir ... | chrt -r 98 taskset -c 3 sox ... | chrt -r 99 taskset -c 3 playhrt ..

Nachschlagende Grüsse
Simon
Bild
Sire
Aktiver Hörer
Beiträge: 309
Registriert: 02.12.2013, 14:01

Beitrag von Sire »

Hallo Simon,

eine interessante Frage, was besser ist: Separieren oder gleichmäßig verteilen. Kernel-Hacking und Prozessortuning gehören nun nicht zu meinen Kenntnissen. Daher möchte ich unbedarfter Weise ein paar Fragen stellen.
Was wäre das Ziel, wenn wir einen oder mehrere Kerne für die rt-relevanten Prozesse reservieren? Dass die Prozesse nicht von anderen behindert werden? Müsste dann aber nicht auch die Peripherie des Prozessors (z.b. Bus-System) eine "reservierte Spur" für die rt-Daten erhalten? Zur technischen Ausführung: Was passiert, wenn ein schlafender Prozess aufwacht? Wird er in dem Kern bleiben, in welchem er ruhte, oder könnte es geschehen, dass ihn der Scheduler in einen anderen Kern verschiebt?

Nach Deinen Ausführungen scheint es relativ einfach zu sein, dies auszuprobieren. Hast Du schon Versuche durchgeführt?

Mit interessierten Grüßen

Klaus
Bild
frankl
Aktiver Hörer
Beiträge: 486
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

Daihedz hat geschrieben: Strategie 1: Wir verteilen die Rechenlast aller Programme möglichst gleichmässig auf alle Prozessorkerne (sodass der notwendige CPU-Takt relativ klein gehalten werden kann, mit allen sich daraus ergebenden Vorteilen).

Strategie 2: Wir verfolgen selektiv für die Audio-Bearbeitung einen Quasi-RT-Ansatz. D.h. wir befreien zunächst einen Prozessorkern möglichst vollständig von allen Nicht-Audio Lasten (z.B. also von Systemverwaltungsprozessen), und lassen danach nur noch die Audioprogramme auf diesem zuvor "befreiten" Prozessorkern laufen, dies mit durchwegs hohen Prioritäten. Das geht natürlich nur solange, als dieser eine "Audio-Kern" denn auch die ganze Audio-Prozesslast bewältigen kann.
Hallo Simon,

ich habe mal einige Strategien in diesem Zusammenhang in meinem Setup probiert.

Zuerst sollte hier vermutlich noch ein Aspekt beleuchtet werden, der noch nicht angesprochen wurde: Bei vielen Anwendungen ist bei heutigen Prozessoren nicht die Auslastung und Geschwindigkeit eines oder mehrerer Prozessoren die Hauptfrage, um zu einer optimalen Performance zu kommen, sondern die Frage, wie die Daten am effizientesten in den Prozessor kommen, damit dieser sie bearbeiten kann.

Ich schätze, dass die Antwort auf Deine Frage nach der besten Strategie vom konkreten Rechner mit seinem Prozessor und der Speicher- und Cache-Verwaltung abhängt. Die Cachegröße (L1, L2, L3) kann eine Rolle spielen und welche CPUs sich welchen Cache teilen. Noch komplizierter wird es mit Hyperthreading bei Pentium, wo man virtuell doppelt so viele CPUs hat, wie physikalisch vorhanden sind.

Wenn mehrere Prozesse mit Pipes hintereinandergeschaltet sind, war es bei meinen Experimenten effizienter, diese auf einer CPU laufen zu lassen, damit die Chance höher ist, dass Daten über den Cache weitergereicht werden können. Dieser Effekt ist umso stärker, je weniger eigentliche Rechenzeit die beteiligten Prozesse benötigen.

Auf meinem Rechner (Odroid XU) mit 4 CPUs mache ich es deshalb so: bufhrt (oder playhrt), das die Daten zum Spielen wegschickt und somit der zeitkritischte Prozess ist, läuft alleine auf einer CPU. Außerdem läuft der CPU-intensivste Prozess, das ist brutefir, auf einer eigenen CPU. Dann laufen catloop und writeloop auf einer weiteren CPU und alle anderen Prozesse der Pipe auf der vierten CPU. Bei den vielen Möglichkeiten, die es gibt, schließe ich natürlich nicht aus, dass es besser geht.
Sire hat geschrieben: Wird er in dem Kern bleiben, in welchem er ruhte, oder könnte es geschehen, dass ihn der Scheduler in einen anderen Kern verschiebt?
In den Beispielen, die oben bei Simon stehen, wird mit 'taskset -c ...' jeder Prozess fest an eine CPU gebunden. Ohne solche direkten Anweisungen verteilt das Betriebssytem die Prozesse auf die CPUs. Solange die Rechenzeit und der Speicher, den eine CPU effizient ansprechen kann, nicht ans Limit läuft, wird der Scheduler einen Prozess immer auf der gleichen CPU laufen lassen, wie vorher. Es kann aber Situationen geben, in denen ein Prozess auch mal auf eine andere CPU verschoben wird.

Viele Grüße,
Frank
Bild
Tinitus
Aktiver Hörer
Beiträge: 1322
Registriert: 10.11.2013, 21:48

Beitrag von Tinitus »

Hallo,

Frage an die Spezialisten: Selbst bei meinem popeligen C1 mit RuneAudio (ergo mehr Prozesse als man eigentlich braucht) liegt die gesamte Prozessorlast beim Abspielen eines 24/176 files bei knapp über 4 % Spitzenlast. Spitzenlast für einen Kern 3,3 % bedenkt man dann noch das was Frank in seinem Post erwähnt hat, ist es dann wirklich notwendig bestimmte tasks bestimmten Kernen zu zuordnen?


Gruß

Uwe
Bild
Daihedz
Aktiver Hörer
Beiträge: 793
Registriert: 25.06.2010, 15:09

Beitrag von Daihedz »

Hallo in die Linux-Runde

Die Installation von Arch-Linux ist schon seit einiger Zeit um einiges einfacher geworden:

Ich möchte auf ein neues Upate von Anarchy hinweisen, welches nun in der Version 1.0.0 voliegt. Anarchy ermöglicht es auf sehr einfache Weise, ein Arch-Linux aufzusetzen. Anarchy bietet z.B. eine umfangreiche Auswahl an Desktops an, inklusive i3 (=ohne Pulseaudio), und auch die Option, mit oder ohne Anmeldemanager das System hochzufahren. Try it!

Der Teaser:
https://www.linux.com/learn/intro-to-li ... rchy-linux

Das real thing:
https://anarchy-linux.org/iso/anarchy-c ... x86_64.iso

Pingophile Grüsse
Simon
Bild
Antworten