[19:14] <arve> så, siden alle andre IRC-kanaler har vist seg å være ubrukelige
[19:14] <arve> ksoftirqd
[19:14] <arve> noen som har peiling på hvor jeg kan tune default priority på den prosessen?
[19:14] <arve> jeg har absolutt behov for at den skal få kjøre med realtime priority
[19:17] <Malinux> https://www.nixtutor.com/linux/changing-priority-on-linux-processes/
[19:18] <arve> Malinux: does not actually apply
[19:18] <arve> jeg trenger å konfigurere maskinen til å kjøre denne spesifikke prosessen med rt-prioritet
[19:18] <Malinux> så det i linken der er ikke relevant?
[19:19] <arve> niceness er noe helt annet enn prioritet
[19:19] <arve> jeg driver med realtime-audio-greier
[19:20] <Malinux> ok. Da er det kanskje denne du leter etter? http://manpages.ubuntu.com/manpages/xenial/man1/chrt.1.html
[19:20] <arve> forsåvidt
[19:20] <arve> men chrt varer fra reboot til reboot
[19:20] <ducasse> arve: prøvd #ubuntustudio?
[19:21] <arve> og trenger en måte å stille prioriteten som er litt mer robust enn en one-liner i /etc/rc.local
[19:21] <arve> ducasse: vært gjennom ##linux, #raspberrypi og #alsa
[19:22] <ducasse> arve: vet det finnes folk der som driver med pro-audio, vil tro de kjenner bedre til rt
[19:23] <Malinux> kanskje det er beskrvet her, for at det skal være permenent https://askubuntu.com/questions/337444/how-to-increase-the-priority-for-a-task-permanently-in-linux-machine
[19:23] <Malinux> men kanskje ducasse har et bedre poeng. Spør noen som herjer med sånt ofte :)
[19:24] <arve> er ikke så mange som herjer med realtime-audio som spiser 70% CPU på en RPi-kjerne
[19:24] <arve> men takk uansett
[19:24] <ducasse> det er også minst en kar på ubuntu-user lista som kjører ubuntu med rt-kernel pga audio-ting.
[19:25] <arve> ducasse: her er greia - jeg tar i mot lyd over nettverk, så kan ikke drive med alskens ugne kernel patches
[19:27] <ducasse> har ikke noen særlig andre forslag, dessverre. det er ikke noe jeg har tuklet med selv.
[19:28] <Mathias> arve: du kan alltids kompilere en rt-kernel selv
[19:29] <arve> @Mathias: har noe med vedlikeholdskostnad å gjøre
[19:30] <arve> og at på et eller annet tidpunkt, så kommer jeg muligens til å stikke en RPi i et kommersielt produkt
[19:32] <arve> sånn for ordens skyld, så er det jeg gjør å kjøre digital romkorreksjon av høyttalere via en Raspberry Pi, med lyden kommende inn over nettverk (Airplay)
[19:36] <Malinux> ah, får du redusert latency via airplay?
[19:36] <arve> latency er ikke problemet
[19:36] <Malinux> okey
[19:36] <arve> kjeden min er shairport-sync -> snd-aloop -> brutefir -> DAC
[19:37] <arve> så det er en viss latency uansett hvordan du vrir og vrenger på det
[19:37] <arve> men, så lenge det noen er som helst  CPU-load
[19:37] <arve> så får snd-aloop spader
[19:38] <arve> den klarer ikke fore data fort nok gjennom systemet, og gjør at sample-raten varierer fra 38-47 kHz
[19:39] <arve> noe apper som BruteFIR som prøver å motta lyd ikke er glad i
[19:40] <arve> så du ender med glitches, og at BruteFIR til slutt kræsjer fordi avviket er for stort
[19:41] <arve> symptomet er at lyden faller ut
[19:41] <Malinux> ah
[19:41] <Malinux> det er kjedelig
[19:41] <arve> og om du prøver å se video med lyden over AirPlay, så havner lyden mer og mer ut av synk
[19:41] <arve> så du kan begynne å se en film med perfekt lip-sync
[19:42] <arve> når du er en halvtime inn i filmen, så rører leppene seg tre sekunder før lyden
[19:43] <ducasse> det er en kar i #ubuntu som antagelig vet en del om dette, og han var ihvertfall der for ikke lenge siden... verdt ett forsøk?
[19:43] <Malinux> det kan jeg i alle fall glemme. Få sync med lyd/bilde over airplay og dlna og sånt
[19:44] <arve> altså, funka lenge for meg, men jeg oppdaterte kjernen
[19:44] <arve> litt i vanvare, og litt fordi jeg liker å være up to date
[19:44] <arve> hjelper det å kjefte på Linus?
[19:45] <Malinux> ja, han er jo kjernekar
[20:13] <RoyK> arve: se ionice - du kan sette sanntidsprio der
[20:13] <RoyK> ellers finnes det egne utvidelser i linux for sanntid
[20:14] <RoyK> men gjetter at det holder med ionice
[20:15] <RoyK> men igjen - det spørs jo hvilken scheduler du har også og hvordan kjerna er konfigurert - de fleste trenger ikke sanntid, så da bruker man høyere HZ og tar mer hensynt til generell ytelse enn at en separat prosess skal kunne yte dritbra på bekostning av alt annet
[20:15] <RoyK> dvs, man bruker *lavere* HZ
[20:16] <RoyK> høyere HZ i kjerna, f.eks. 1k, gjør at sanntidsgreier funker bedre, men man får veldig mye context switching, noe som går ut over generell ytelse
[20:17] <RoyK> i Gamle Dager var det vanlig med 100Hz, så ble det 1kHz, og nå har det vel normalisert seg på 250Hz, men skal du ha noe som funker best mulig på sanntid, må du i hvert fall ha noe som er bygd med low-latency
[20:17] <RoyK> kanskje greit å begynne med ionice og se om det hjelper
[20:34] <arve> @RoyK: dette er en relativt standard jessie
[20:35] <arve> og akkurat å la ksoftirqd gjøre hva #$% den vil fikser alt jeg vil
[20:35] <arve> lar jeg den få turde å gå, så holder den seg i sync, men kræsjer BruteFIR en gang i timen eller så
[21:49] <RoyK> har du prøvd å leke med ionice?