audiodiyers.hu http://audiodiyers.hu/ |
|
audio HTPC építése http://audiodiyers.hu/viewtopic.php?f=49&t=2493 |
Oldal: 11 / 15 |
Szerző: | Toto [ 2018.03.26. 12:34 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Windows 8.1-el mi a gond egyébként? Csak azért kérdezem, mert ebből könnyebben kitudom venni a DWM-et. Vezérlőpult is klasszikus. És persze letudom csökkenteni a 64 bites telepítőt olyan 1 GB környékére. |
Szerző: | hifitibi [ 2018.03.26. 13:04 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Konzol írta: Ugyanez egy Dell Vostro 15-ön.... Ha ezt a parancsot kiadom az AP Linuxos gépemen, amit bemásoltál, akkor az is szépen válaszol, mint Neked? sudo cyclictest -t 5 -p 99 -n -i 10000 |
Szerző: | Konzol [ 2018.03.26. 13:11 ] |
Hozzászólás témája: | Re: audio HTPC építése |
hifitibi írta: Konzol írta: Ugyanez egy Dell Vostro 15-ön.... Ha ezt a parancsot kiadom az AP Linuxos gépemen, amit bemásoltál, akkor az is szépen válaszol, mint Neked? sudo cyclictest -t 5 -p 99 -n -i 10000 ??? Azt nem tudom, hogy fog válaszolni. Ha nincs telepítve, akkor szükséged lesz az rt-tests csomagra. |
Szerző: | hifipisti [ 2018.03.26. 14:13 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Win 10 alatt mivel mértek? Egyelőre a beállított bufferértékekre alapoztam a kijelentésem ,de szívesen meg is mérném. Fidelizer Pro 8.1-el is optimalizálva van az oprendszerem. Egy procimagot a JRiver hasznosít. |
Szerző: | miczo [ 2018.03.26. 14:36 ] |
Hozzászólás témája: | Re: audio HTPC építése |
LatencyMon (6.51) nevü tool, innen: http://www.resplendence.com/downloads Email címmel regelni kell, egyébként free. |
Szerző: | hifipisti [ 2018.03.26. 17:18 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Az alábbi adatok milyennek minősülnek? Kód: CONCLUSION
_________________________________________________________________________________________________________ Your system appears to be suitable for handling real-time audio and other tasks without dropouts. LatencyMon has been analyzing your system for 0:01:09 (h:mm:ss) on all processors. _________________________________________________________________________________________________________ SYSTEM INFORMATION _________________________________________________________________________________________________________ Computer name: DESKTOP-68BLN4N OS version: Windows 8 , 6.2, build: 9200 (x64) Hardware: All Series, ASUS, ASUSTeK COMPUTER INC., Z97-A CPU: GenuineIntel Intel(R) Core(TM) i5-4590S CPU @ 3.00GHz Logical processors: 4 Processor groups: 1 RAM: 16261 MB total _________________________________________________________________________________________________________ CPU SPEED _________________________________________________________________________________________________________ Reported CPU speed: 2998 MHz Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results. _________________________________________________________________________________________________________ MEASURED INTERRUPT TO DPC LATENCIES _________________________________________________________________________________________________________ The interrupt to DPC latency reflects the measured interval in which a DPC could execute in response to a hardware request from the moment the interrupt service routine started execution. Highest measured interrupt to DPC latency (µs): 163,251589 Average measured interrupt to DPC latency (µs): 2,444582 _________________________________________________________________________________________________________ REPORTED ISRs _________________________________________________________________________________________________________ Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal. Highest ISR routine execution time (µs): 49,981321 Driver with highest ISR routine execution time: portcls.sys - Port Class (Class Driver for Port/Miniport Devices), Microsoft Corporation Highest reported total ISR routine time (%): 0,339434 Driver with highest ISR total time: portcls.sys - Port Class (Class Driver for Port/Miniport Devices), Microsoft Corporation Total time spent in ISRs (%) 0,342798 ISR count (execution time <250 µs): 150649 ISR count (execution time 250-500 µs): 0 ISR count (execution time 500-999 µs): 0 ISR count (execution time 1000-1999 µs): 0 ISR count (execution time 2000-3999 µs): 0 ISR count (execution time >=4000 µs): 0 _________________________________________________________________________________________________________ REPORTED DPCs _________________________________________________________________________________________________________ DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution. Highest DPC routine execution time (µs): 59,627752 Driver with highest DPC routine execution time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation Highest reported total DPC routine time (%): 0,229887 Driver with highest DPC total execution time: portcls.sys - Port Class (Class Driver for Port/Miniport Devices), Microsoft Corporation Total time spent in DPCs (%) 0,326348 DPC count (execution time <250 µs): 356646 DPC count (execution time 250-500 µs): 0 DPC count (execution time 500-999 µs): 0 DPC count (execution time 1000-1999 µs): 0 DPC count (execution time 2000-3999 µs): 0 DPC count (execution time >=4000 µs): 0 _________________________________________________________________________________________________________ REPORTED HARD PAGEFAULTS _________________________________________________________________________________________________________ Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution. Process with highest pagefault count: none Total number of hard pagefaults 0 Hard pagefault count of hardest hit process: 0 Highest hard pagefault resolution time (µs): 0,0 Total time spent in hard pagefaults (%): 0,0 Number of processes hit: 0 _________________________________________________________________________________________________________ PER CPU DATA _________________________________________________________________________________________________________ CPU 0 Interrupt cycle time (s): 3,236708 CPU 0 ISR highest execution time (µs): 49,981321 CPU 0 ISR total execution time (s): 0,938497 CPU 0 ISR count: 147682 CPU 0 DPC highest execution time (µs): 59,627752 CPU 0 DPC total execution time (s): 0,878944 CPU 0 DPC count: 351784 _________________________________________________________________________________________________________ CPU 1 Interrupt cycle time (s): 0,898210 CPU 1 ISR highest execution time (µs): 28,230153 CPU 1 ISR total execution time (s): 0,007168 CPU 1 ISR count: 1588 CPU 1 DPC highest execution time (µs): 25,095397 CPU 1 DPC total execution time (s): 0,010771 CPU 1 DPC count: 2356 _________________________________________________________________________________________________________ CPU 2 Interrupt cycle time (s): 0,756155 CPU 2 ISR highest execution time (µs): 17,670781 CPU 2 ISR total execution time (s): 0,000566 CPU 2 ISR count: 903 CPU 2 DPC highest execution time (µs): 35,909273 CPU 2 DPC total execution time (s): 0,002810 CPU 2 DPC count: 1044 _________________________________________________________________________________________________________ CPU 3 Interrupt cycle time (s): 0,803364 CPU 3 ISR highest execution time (µs): 17,264510 CPU 3 ISR total execution time (s): 0,000317 CPU 3 ISR count: 476 CPU 3 DPC highest execution time (µs): 36,010674 CPU 3 DPC total execution time (s): 0,008602 CPU 3 DPC count: 1462 _________________________________________________________________________________________________________ |
Szerző: | hifipisti [ 2018.03.26. 17:30 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Gondolom megy a zenei lejátszás miközben mérek? |
Szerző: | Konzol [ 2018.03.26. 17:47 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Az SOC-eredményei üresen járó gépről származnak. A rendszer folyamatain felül csak egy ssh munkamenet ment. Így össze tudtam vetni a kerneleket. Az alábbi teszt egy CD minőségű flac file hálózaton keresztüli lejátszásakor készült: Kód: ./cyclictest -t 5 -p 80 -n -i 10000
# /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 0.04 0.04 0.05 1/85 2774 T: 0 ( 2770) P:80 I:10000 C: 3445 Min: 6 Act: 11 Avg: 8 Max: 21 T: 1 ( 2771) P:80 I:10500 C: 3281 Min: 6 Act: 7 Avg: 7 Max: 44 T: 2 ( 2772) P:80 I:11000 C: 3132 Min: 6 Act: 8 Avg: 7 Max: 20 T: 3 ( 2773) P:80 I:11500 C: 2996 Min: 6 Act: 6 Avg: 7 Max: 21 T: 4 ( 2774) P:80 I:12000 C: 2871 Min: 6 Act: 8 Avg: 8 Max: 25 |
Szerző: | Konzol [ 2018.03.26. 18:12 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Azt azért látni kell, hogy az előző tesztekben magas prioritású ( -p 80 illetve -p 99 ) prioritású folyamatokkal ment a program. |
Szerző: | hifipisti [ 2018.03.26. 18:23 ] |
Hozzászólás témája: | Re: audio HTPC építése |
A fenti mérés: Win 10 64bit, JRiver 23.0.103 64bit, Fidelizer Pro 8.1. Hangkártya: RME HDSPe AIO. A JRiver 44.1KHz/16bit Flac-ot játszott le Kerner Streaming-el |
Szerző: | Toto [ 2018.03.27. 02:19 ] | ||
Hozzászólás témája: | Re: audio HTPC építése | ||
Virtuális memória kikapcsolva rajta. Meg még csomó minden. Kizárólag Jriver 19-hez építve. Esetleg még a MPD elfut rajta. És ez a 64 bites verzió.
|
Szerző: | miczo [ 2018.03.27. 06:48 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Elvégezhetnél egy latency mérést üresjárási állapotban, valamint zene lejátszás közben úgy, hogy a lejátszó magas, vagy realtime prioritáson fut. |
Szerző: | hodyka57 [ 2018.03.27. 06:56 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Toto Látom Te a jRiver 19-et preferálod, a többivel mi a gond ? (újak ) Köszi |
Szerző: | hifipisti [ 2018.03.27. 09:13 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Az én mérésem realtime prioritással és zenei lejátszás közben történt, ahogy azt már írtam. |
Szerző: | Konzol [ 2018.03.27. 09:25 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Nem rosszak azok a számok, sőt! Igaz, hogy szerénytelenül el van látva a vas erőforrásokkal Az azért feltűnő, hogy a grafikus felület mennyire "belerondít" a rendszerbe. Ha közben egerészel még sokkal rosszabb a helyzet. Az eseményvezérelt GUI teljesen aszinkron, míg a lejátszás elvileg szinkron folyamat. A kettő között kell valahogy hidat verni. Tiltani az aszinkron folyamtoknak a szinkron folyamat megszakítását ami sokat ront a "felhasználói élményen", pufferelni az aszinkron kapott adatsort, amit szinkron kell tovább feldolgozni - puffer méret a feldolgozó eszközön stb. |
Szerző: | Toto [ 2018.03.27. 10:36 ] |
Hozzászólás témája: | Re: audio HTPC építése |
miczo írta: Elvégezhetnél egy latency mérést üresjárási állapotban, valamint zene lejátszás közben úgy, hogy a lejátszó magas, vagy realtime prioritáson fut. Debugger Engine kell hozzá, ezt onnan tudom, hogy nem tudtam elindítani. Meg még kell pár dolog. Remélhetőleg a memória, és a folyamatok száma nem szökik vissza. +utólag még letiltható pár dolog. De az látszik, hogy elég jó lenne a Windows 8.1, ha még Windows 2000 korszakban lenne a megjelenése. Jriver újabb verziói rosszabbul szóltak. Egeret múltkor a korszerűbb NT rendszeren nem tudtam kimérni. Szerintem itt sem fogom. DWM letiltása azért is fontos, mert alapból DirectX-et használ, az meg videokártya illesztőt, Latency pedig ezt szépen ki is mutatja. Illetve Windows 7-nél tapasztaltam, hogy jobb a hang, ha klasszikus Windows 2000-es téma működik, DWM nélkül. Másik legzavaróbb dolog a HDD kezelés, és a hálózati forgalom általában. Ezt a Windows 8.1-et nem fogom főrendszerként használni, csak a HTPC-re, ha majd lesz. |
Szerző: | hifipisti [ 2018.03.27. 10:39 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Pfűűűű, ez nekem sajnos magas Ha beavatnál a részletekbe, azt megköszönném. A Fidelizer, főleg az új 8.1 nagyon jól szól és az optimalizálást is jól csinálja. A valós idejű lejátszást is jól megoldja, priorizált proci maggal. Mellette elég sok dolgot tudok még úgy csinálni a géppel, hogy nincs hallható dropout. Direkt nincs plusz videó kártya a gépben főleg, hogy ne zajoljon és ne vigyen el extra erőforrást. Az is igaz, hogy ezt a gépet nem csak zene hallgatásra használom, hanem egyéb dolgokra is, tehát nem szándékom mindent teljesen kigyomlálni. Jól gondolom, hogy az USB-s megoldások egy ilyen PCie hangkártyához képest egy nagyság rendel rosszabb latency értéket produkálnak? |
Szerző: | Konzol [ 2018.03.27. 10:52 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Toto írta: Másik legzavaróbb dolog a HDD kezelés, és a hálózati forgalom általában. Ezt a Windows 8.1-et nem fogom főrendszerként használni, csak a HTPC-re, ha majd lesz. FAT, esetleg ExFAT filerendszer használata javallott. Sokkal kevesebb erőforrást igényel. |
Szerző: | Toto [ 2018.03.27. 10:57 ] |
Hozzászólás témája: | Re: audio HTPC építése |
EXT4 fájlrendszer múltkor bevált, szerintem ide is jó lesz majd. Fidelizer pénzkidobás, ezeket az eredményeket el lehet ingyenes módosításokkal is érni. USB-t pedig nem javasolom. Csak a PCI-s kártyát. |
Szerző: | Konzol [ 2018.03.27. 11:00 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Azt hiszem itt a vége valahol ... Kód: ./cyclictest -t 5 -p 80 -n -i 10000
# /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 0.10 0.05 0.06 1/77 2563 T: 0 ( 2559) P:80 I:10000 C: 2369 Min: 6 Act: 7 Avg: 7 Max: 14 T: 1 ( 2560) P:80 I:10500 C: 2256 Min: 6 Act: 10 Avg: 7 Max: 11 T: 2 ( 2561) P:80 I:11000 C: 2154 Min: 6 Act: 7 Avg: 7 Max: 12 T: 3 ( 2562) P:80 I:11500 C: 2060 Min: 6 Act: 7 Avg: 7 Max: 13 T: 4 ( 2563) P:80 I:12000 C: 1974 Min: 6 Act: 7 Avg: 7 Max: 13 root@TDA1543:~# |
Szerző: | Konzol [ 2018.03.27. 11:17 ] |
Hozzászólás témája: | Re: audio HTPC építése |
A Banana eredményei hajszálnyival jobbnak tűnnek, de annak 48Mhz-el magasabb frekvencián jár a RAM-ja ( 672Mhz - 624Mhz ). |
Szerző: | Toto [ 2018.03.27. 14:22 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Windows 8.1-nél befejeztem a fejlesztést, jó lett. Simán mehet egy tabletméretű kijelzőre, meg a HDMI 2.0-ra is másodlagos képernyőként. És persze csakis zenelejátszásra, BD videóra alkalmas. Csak DWM nélkül érdemes használni, azt meg először nem könnyű kikapcsolni, és persze a winlogon így nem is működik. Automatikus bootolás kell. És program is kell, ami visszahozza a Windows 2000-es klasszikus kinézetet. Meltdown/Spectre frissítés nincs rajta, mert lassíthatja a rendszert. Biztos jobb az alap Windows 10, csak már annyi minden sz*rral teliszórják, hogy már ez se biztos. DWM nélkül használhatatlan, és egyre inkább a DWM-re épül az egész, új effektek vannak/lesznek hozzá. Szerintem baró lesz, csak pont nem audiora alkalmas. Csak átlagos zenehallgatásra. |
Szerző: | hifipisti [ 2018.03.27. 15:05 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Üresjáratban így néz ki a dolog. Illetve a JRiver automatikusan elindul a win-el együtt, de nincs lejátszás. A többi paraméter ugyan az, mint fentebb már írtam. Kód: _________________________________________________________________________________________________________
CONCLUSION _________________________________________________________________________________________________________ Your system appears to be suitable for handling real-time audio and other tasks without dropouts. LatencyMon has been analyzing your system for 0:01:03 (h:mm:ss) on all processors. _________________________________________________________________________________________________________ SYSTEM INFORMATION _________________________________________________________________________________________________________ Computer name: DESKTOP-68BLN4N OS version: Windows 8 , 6.2, build: 9200 (x64) Hardware: All Series, ASUS, ASUSTeK COMPUTER INC., Z97-A CPU: GenuineIntel Intel(R) Core(TM) i5-4590S CPU @ 3.00GHz Logical processors: 4 Processor groups: 1 RAM: 16261 MB total _________________________________________________________________________________________________________ CPU SPEED _________________________________________________________________________________________________________ Reported CPU speed: 2998 MHz Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results. _________________________________________________________________________________________________________ MEASURED INTERRUPT TO DPC LATENCIES _________________________________________________________________________________________________________ The interrupt to DPC latency reflects the measured interval in which a DPC could execute in response to a hardware request from the moment the interrupt service routine started execution. Highest measured interrupt to DPC latency (µs): 60,109474 Average measured interrupt to DPC latency (µs): 2,305431 _________________________________________________________________________________________________________ REPORTED ISRs _________________________________________________________________________________________________________ Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal. Highest ISR routine execution time (µs): 27,345564 Driver with highest ISR routine execution time: Wdf01000.sys - Rendszermag módú illesztőprogram-keretrendszer futásidejű modulja, Microsoft Corporation Highest reported total ISR routine time (%): 0,004499 Driver with highest ISR total time: Wdf01000.sys - Rendszermag módú illesztőprogram-keretrendszer futásidejű modulja, Microsoft Corporation Total time spent in ISRs (%) 0,005030 ISR count (execution time <250 µs): 9018 ISR count (execution time 250-500 µs): 0 ISR count (execution time 500-999 µs): 0 ISR count (execution time 1000-1999 µs): 0 ISR count (execution time 2000-3999 µs): 0 ISR count (execution time >=4000 µs): 0 _________________________________________________________________________________________________________ REPORTED DPCs _________________________________________________________________________________________________________ DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution. Highest DPC routine execution time (µs): 62,536358 Driver with highest DPC routine execution time: Wdf01000.sys - Rendszermag módú illesztőprogram-keretrendszer futásidejű modulja, Microsoft Corporation Highest reported total DPC routine time (%): 0,05730 Driver with highest DPC total execution time: rspLLL64.sys - Resplendence Latency Monitoring and Auxiliary Kernel Library, Resplendence Software Projects Sp. Total time spent in DPCs (%) 0,104831 DPC count (execution time <250 µs): 265977 DPC count (execution time 250-500 µs): 0 DPC count (execution time 500-999 µs): 0 DPC count (execution time 1000-1999 µs): 0 DPC count (execution time 2000-3999 µs): 0 DPC count (execution time >=4000 µs): 0 _________________________________________________________________________________________________________ REPORTED HARD PAGEFAULTS _________________________________________________________________________________________________________ Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution. Process with highest pagefault count: none Total number of hard pagefaults 0 Hard pagefault count of hardest hit process: 0 Highest hard pagefault resolution time (µs): 0,0 Total time spent in hard pagefaults (%): 0,0 Number of processes hit: 0 _________________________________________________________________________________________________________ PER CPU DATA _________________________________________________________________________________________________________ CPU 0 Interrupt cycle time (s): 1,151639 CPU 0 ISR highest execution time (µs): 27,345564 CPU 0 ISR total execution time (s): 0,011646 CPU 0 ISR count: 8131 CPU 0 DPC highest execution time (µs): 62,536358 CPU 0 DPC total execution time (s): 0,247768 CPU 0 DPC count: 260835 _________________________________________________________________________________________________________ CPU 1 Interrupt cycle time (s): 1,053583 CPU 1 ISR highest execution time (µs): 10,907272 CPU 1 ISR total execution time (s): 0,000408 CPU 1 ISR count: 398 CPU 1 DPC highest execution time (µs): 57,969313 CPU 1 DPC total execution time (s): 0,006143 CPU 1 DPC count: 1874 _________________________________________________________________________________________________________ CPU 2 Interrupt cycle time (s): 0,748317 CPU 2 ISR highest execution time (µs): 14,078719 CPU 2 ISR total execution time (s): 0,000404 CPU 2 ISR count: 311 CPU 2 DPC highest execution time (µs): 28,004670 CPU 2 DPC total execution time (s): 0,005486 CPU 2 DPC count: 1723 _________________________________________________________________________________________________________ CPU 3 Interrupt cycle time (s): 0,782791 CPU 3 ISR highest execution time (µs): 11,074716 CPU 3 ISR total execution time (s): 0,000222 CPU 3 ISR count: 178 CPU 3 DPC highest execution time (µs): 24,286858 CPU 3 DPC total execution time (s): 0,004844 CPU 3 DPC count: 1545 _________________________________________________________________________________________________________ |
Szerző: | miczo [ 2018.03.27. 16:40 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Ha megnézed az épp nem használt magok (utólsó kettö) IRQ latency értékeit, az mutatja, hogy a vas nagyon combos. Az optimalizált minigépnél pont egy nagysárgrenddel gyorsabb a reakcióideje. A maximum interrupt értékek a minimum 200x-a körül mozognak a terheletlen magon, míg az optimalizált minigépnél ez ~2x!! Ha jól saccolom jitterben ez minimum 1-2 nagyságrend lesz, de ezt úgy lehetne megmondani, ha az adott rendszeren mérnénk egy konkrét jitter értéket is a DA után. Erre sajnos nincs eszközöm, csak elméletileg okoskodom most a digitális oldal mérése alapján. Szóval ez a gép így is elég tisztességes eredményt ad, köszönhetöen az erös vasnak, de van még lehetöség az optimalizálásra. Nem tudom a win8 kernel mit enged.. |
Szerző: | bta [ 2018.03.27. 20:15 ] |
Hozzászólás témája: | Re: audio HTPC építése |
hifipisti írta: Win 10 alatt mivel mértek? Nem mérni kellene, hanem kicsontozni a végletekig: - "modern" appok végleges eltávolítása, áruház kikapcsolása - nem használt W10 összetevők eltávolítása - programok felrakásakor előnyben kell részesíteni a hordozható változatot (ha van ilyen) - erőforrászabáló ill. szükségtelen szolgáltatások szervezeti szintű tiltása, különös tekintettel a "kémfunkciókra" (amit így nem lehet, arra ott van ez) - a többit a létfontosságú szolgáltatások kivételével "kézi" indításúra kell állítani - rendszeres adatvédelmi tisztítás, ha sokat netezel - a lapozófájl a minimálisan elfogadott FIX(!) méret legyen (64 bites W10 / 8GB memória mellett szvsz bátran ki lehet nullázni) Erre jöhet még ráadásnak a Fidelizer. Process Lasso kerülendő... YT-on talán még a legjobb hangja egy RAM cache-elésre átállított Firefoxnak van..)) |
Szerző: | bta [ 2018.03.27. 20:21 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Toto írta: DWM-t utólag célszerű kikapcsolni. Legtutibb kilőni az explorer.exe folyamatot;) Re: "mélyfekete háttér" Viccen kívül, jó gépen (akárhogy is nézzük a PC a lánc eleje, a "forrás"!) és jó rendszeren ezt is meg lehet hallani. |
Szerző: | Konzol [ 2018.03.27. 20:26 ] |
Hozzászólás témája: | Re: audio HTPC építése |
bta írta: Toto írta: DWM-t utólag célszerű kikapcsolni. Legtutibb kilőni az explorer.exe folyamatot;) Re: "mélyfekete háttér" Viccen kívül, jó gépen (akárhogy is nézzük a PC a lánc eleje, a "forrás"!) és jó rendszeren ezt is meg lehet hallani. Ezzel persze dedikált eszközzé válik az asztali pc ami így durva pazarlás pusztán azért mert nem megfelelő szoftver fut rajta... |
Szerző: | Toto [ 2018.03.27. 20:31 ] |
Hozzászólás témája: | Re: audio HTPC építése |
W10/W8.1 esetében elszoktam távolítani egyből a modern appokat, W10 one drive-ot, Cortana-t, beépített keyloggert és diagnosztikát, legalább is annak fő törzsét, mert kitudja, mennyi sunyi programot írtak még ezek, főleg W10 esetében, stb. De a DWM kikapcsolása W10 esetében nagy probléma, gyakorlatilag DWM-re írják az egész rendszert. Viszont találtam olyan okos programot, hogy Ashampoo Core Tuner 2. Ezzel valósidejű prioritást állíthatok be a lejátszónak, és mellette szabályozhatom a processzormagokat is, melyiken fusson a Jriver vagy az MPD és melyiken a többi. Ezenfelül IRQ prioritást tudok állítani a registryben, ami a PCI-s hangkártyának jól jönne. |
Szerző: | Konzol [ 2018.03.27. 20:49 ] |
Hozzászólás témája: | Re: audio HTPC építése |
A helyzet az, ha nem vagyok bejelentkezve ssh-val akkor 71 processz fut az SOC-n. Ebből összesen 4 ami nem kernel szintű. ( getty, sshd, lldma, mpd ). A négy mag miatt ilyen sok a kernel folyamat, csökkenteni ezt màr nem tudtam, vagy ügyetlen voltam és elnéztem valamit. Az mpd "kicsontozása" szintén hatékony módszernek tűnik. Valószínűleg érdemes kicsit a forráskódban is nézelődni... A dsd fordításkori tiltása jelentős kódrészletek kihagyását eredményezi... A mixer "none" beállítás pedig meglepően hatásos. Csak kényelmetlen. |
Szerző: | bta [ 2018.03.27. 20:55 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Konzol írta: Ezzel persze dedikált eszközzé válik az asztali pc ami így durva pazarlás pusztán azért mert nem megfelelő szoftver fut rajta... Az explorer könnyedén újraindítható;) Feladatkezelő->új feladat futtatása... Igazából csak érdekességként írtam... nem vagyok róla meggyőződve, hogy minden körülmények között javít a hangon. Sokkal egyértelműbb, amikor a monitort kapcsolom ki fizikailag. Szó esett itt a procihűtő zajáról... sokkal előnyösebb a szomszéd szobából, lehetőség szerint másik fázisról működtetett PC. Ahogy a routert és egyebeket sem ajánlatos a hifis szobába telepíteni. Kényelmetlen dolgok ezek, dehát valamit valamiért. |
Szerző: | Konzol [ 2018.03.27. 21:18 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Soha nem éreztem semmilyen késztetést, hogy zenét akarjak hallgatni Windowson - igaz, másra se nagyon inspirált sose -, így konkrét tapadztalatom nincs a dologgal, de valszeg egy szerver verzió jobban teljesítene lejátszóként. Azoknak másképp hangolták a kernelét. A "felhaszálói élmény" ( perverz egy elnevezés ) túlzásba vitele a rendszergazdák heves anyázását váltaná ki. És egy windows szerver van, hogy jól teljesít... |
Szerző: | Toto [ 2018.03.27. 21:40 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Nem olyan biztos az. Windows Server 2016-ba tettek egy sandbox funkciót, ami kifejezetten ártott a hangnak. Legjobb Server a 2012-es, ha jól tudom. De teljesen mindegy. Kész lett a W10 RS4 is. Majd szétszedem ezt is, és megnézem mit tud DWM-el. Legkorszerűbb kernel. Jók a modern Windows-ok, csak tudni kell használni. Pont úgy, mint a Linuxot. Meg kell hozzá pár okos program. |
Szerző: | Konzol [ 2018.03.27. 22:00 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Próbáltad mindkettőt, vagy csak olvastad? ( Egy-két óra kattogtatás nem próba, csak bohóckodás ) |
Szerző: | Toto [ 2018.03.27. 22:05 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Windows Server 2016-ot próbáltam, tapasztalatból mondom, hogy sz*r volt a hang. Pedig nem is volt UWP-s alkalmazás. GUI nem sokban különbözött az akkori Windows 10 verziótól. Nem jött be, ennyi. Windows 10 RS4 április 10-én jelenik meg RTM-ként. Most is elérhető, csak insider build-ként, abban meg még van egy-két kacat a többin kívül. Server 2016-ban valami konténeres sz*rságot vezettek be. Ami biztos jó, csak nem a hanghoz. |
Szerző: | Konzol [ 2018.03.27. 22:35 ] |
Hozzászólás témája: | Re: audio HTPC építése |
A W10 professional és az enterprise is támogatja a konténereket... |
Szerző: | Toto [ 2018.03.27. 22:42 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Konzol írta: A W10 professional és az enterprise is támogatja a konténereket... De ott utólagos telepítés van. Azaz nincs alapból rajta. Én továbbra is annyit tudok mondani, hogy sz*r volt a hang a Server 2016-on. Ami szerintem a konténeres alkalmazás miatt volt. Egyébként windows 10 a kernel rajta. Legalább is az akkori verziója. Ugyanúgy a GUI is ugyanaz, meg a beépített megfigyelőprogram is. |
Szerző: | Konzol [ 2018.03.27. 23:11 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Nekem mindegy. A kérdés mondjuk úgy akademikus. |
Szerző: | miczo [ 2018.03.27. 23:15 ] |
Hozzászólás témája: | Re: audio HTPC építése |
A konténeres dolgok a .net keretrendszerhez tartoznak, már xp alatt is volt. Ez nem hiszem hogy bezavarna. A hang és video lejátszás hardverközel részét mindig natív driverek intézik. A windózokban alapvetöen nagyon sok virtualizáció jellegü technika van (.net, java-vm, IIS alapú cuccok), a kernel fölé annyi szerviz és applikációs réteg települ (nem is igazán eltávolíthatóan), hogy nyugodtan azt lehet mondani, a windózok nem realtime jellegü feladatokhoz vannak tervezve. Az audiofil zene lejátszás márpedig erösen az. Ki lehet kapcsolgatni ezt-azt a windózban, amíg egy közel használhatatlan állapotig el nem jutunk. Igazából nem értem minek erölködni, ez az OS nem erre van kitalálva. |
Szerző: | Konzol [ 2018.03.27. 23:49 ] |
Hozzászólás témája: | Re: audio HTPC építése |
XP-hez még mintha lett volna valmi real-time csomag. ( Tuti, hogy volt, szívtam vele egy sort, mert eldobálta a hálózati kapcsolatot bizonyos kártyákkal ) |
Szerző: | Toto [ 2018.03.28. 00:06 ] | ||
Hozzászólás témája: | Re: audio HTPC építése | ||
KernelStreaming viszont van. Az eddigi legjobb cucc Windows alatt. Jriver pedig Win32-es alkalmazás, .NET nélkül, nem tudom, milyen virtualizáció jellegű technika lehet ott. Ugyanez MPD-nél is. Persze, ha x86_64-es a rendszer. Gond, és a valós gond W8 illetve W10 esetében szerintem az, hogy sok sz*r fut közben. Ezeknek a számát kell lecsökkenteni, prioritásokat kiosztani, meg mondjuk felszabadítani CPU core-t az audio kezelőnek és a lejátszóknak.
|
Szerző: | Toto [ 2018.03.28. 00:21 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Amúgy tényleg van win32 subsystem, de ami a legdurvább, van RTX Ez kikerül mindent. x2APIC-t viszont tiltani kell, vagy kicserélni xAPIC-ra. RTX64 kell ide. Persze akkor az MPD-t hozzá kell igazítani. |
Szerző: | Konzol [ 2018.03.28. 08:35 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Csak sikerült végül full RT kernelt fordítanom. :) Kód: root@TDA1541A:~/rt-tests# ./cyclictest -t 5 -p 80 -n -i 10000
# /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 0.08 0.06 0.05 1/77 2291 T: 0 ( 2287) P:80 I:10000 C: 6165 Min: 5 Act: 7 Avg: 6 Max: 14 T: 1 ( 2288) P:80 I:10500 C: 5871 Min: 5 Act: 7 Avg: 6 Max: 17 T: 2 ( 2289) P:80 I:11000 C: 5605 Min: 5 Act: 6 Avg: 6 Max: 12 T: 3 ( 2290) P:80 I:11500 C: 5361 Min: 5 Act: 6 Avg: 6 Max: 13 T: 4 ( 2291) P:80 I:12000 C: 5137 Min: 5 Act: 6 Avg: 6 Max: 13 |
Szerző: | hifipisti [ 2018.03.28. 11:28 ] |
Hozzászólás témája: | Re: audio HTPC építése |
A legtöbb dolog ki van gyomláva már a Win 10-ből (enterprice). Már amit ki tudtam laikusként (automatikusan induló progik, áruház, felhő szolgáltatás, stb.). külön vírusirtó nincs telepítve. Regisztrit rendszeresen takarítom (CCleaner). Kémvírus keresőt is futtatok havi szinten. Így is sok dolog megy a háttérben ezt én is látom. A JRiver 23-tól már 64bites és stabilabbnak, illetve gyorsabbnak tűnik, mint a 32 bites változat. Hangját nem hasonlítottam. A kernel streaming nálam is a legjobban szól. A JRiver úgy van beállítva, hogy a teljes lejátszandó fájlt memóriába húzza és valós időben dekódolja pl. a FLAC-ot. Ez a funkció a 19-ben még nincs benne, viszont hangilag elég sokat hoz a konyhára. Jobban szól így, mint a memóriába, már dekódolva behúzott fájl. Szintén érdekes a dithering kikapcsolása, amit nem javasol a JRiver Nekem így természetesebbnek tűnik a megszólalás. Ez a funkció is hiányzik a 19-ből. Aztán van valami spec digitális szűrő is, amit be lehet kapcsolni (szintén nincs 19-ben), de nekem túl műanyag lesz a hang, ahogy a DSP studio-ban a sample rate konverzió bárhová konvertálása is. Itt is felpuhul és picit műanyag lesz a hang, a részletek elkezdenek összemosódni. Az RME hangkártya saját órájának jittere < 1ns ami nem egy combos érték mégis jól szól |
Szerző: | miczo [ 2018.03.28. 12:07 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Azt olvastam valami ajánlásban (ami win-es gépekre vonatkozott), hogy 100us alatti latency ingadozás már elfogadható jitter szempontból. Azok az alkalmazói programok amiket írsz nem sokat nyomnak a latban, mert csak on-demand jelleggel futnak (mint ahogy a több száz szerviz jelentös része is), viszont pár olyan dolog van ami nagyon lényeges lenne (pl a dma priority, irq beállítások), amiket viszont egy adott alkalmazás kezel és nem férünk hozzá (nem konfigurálható). A hangkártya / rendszer esetében szerintem nem is annyira abszolút jitter vagy latency értékekre kellene gyúrni, hanem hogy a rendszer minnél egyenletesebben tudjon müködni, tehát a latencyben a szórás nagysága és annak spektruma szól bele jobban a kapott hangba. A müanyagosodó hang pl tipikusan a megnövekedett latency ingadozás miatt az idötartományban adatot vesztesz. A jitter növekedése (idötartomány) a finom részleteket (amplitúdó változások) sikálja ki. És a lejátszás még mindig bitpontos, csak az analóg oldalon az idötartományban vész el az infó. |
Szerző: | Toto [ 2018.03.28. 12:54 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Írtam az RTX64-nek, hogy adjanak ingyen kulcsot. Szerintem nem fognak. Így annyit lehet még variálni a CPU és az IRQ prioritáson kívül, hogy processzoraffinitást állítok be a programoknak. Illetve minél kevesebb win32-es programot kell futtatni, csrss.exe-t meg valós idejűre állítani. W10 esetében olyat is meglehet csinálni, hogy MPD működik win32-es programként, kezelőfelülete pedig UWP-s sz*rként. Ezenfelül nem sok mindent lehet tenni Windows rendszeren. |
Szerző: | shany [ 2018.03.28. 13:02 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Abszolút laikusként, nem világos néhány dolog: - A windows elvileg fejlett feladatmenedzsmenttel működik, az előző-, a futó feladatokból látszó trend alapján meg tudja jósolni a majd rendelkezésre álló számítási kapacitásait. Ha egy lejátszóprogram elsődleges prioritást kap, időben ingadozásmentes kimeneti adatfolyamot akar produkálni, akkor a program indításának adott pillanatában kalkulálható lenne, hogy pl. fix 200us latency alkalmazásával mindenképp "bele fog férni" az órejelszinkron kimeneti időzítés, ha esik ha fúj. Ha pedig mégis nagyobb lesz a terhelés a kalkuláltnál, akkor egyéb folyamatokat parkoltat azokra a mikroszekundumokra. Működhet így egy lejátszóprogram? - Ha "jitteres" is a belső adatfolyam a PC-ben, akkor is a hálózati továbbítás, de akár az USB továbbítás másik oldalán akármilyen pontosságúra lehet reclockolni a jelfolyamot. Feltéve, hogy nincs adatvesztés az USB átvitel során, de ez nem valószínű. |
Szerző: | miczo [ 2018.03.28. 14:39 ] |
Hozzászólás témája: | Re: audio HTPC építése |
A fentebb vesézgetett dolgok akkor igazak, ha direkt I2S kimenet vagy PCI hangkártya a kimenet. Ha a DAC-on vagy a hangkártyán van extra bufferelés az valamit javít a helyzeten. Ahogy Konzol is írta korábban, a legvégén a WCLK-nak kellene nagyon pontosnak lennie. Ez kapuzza a DA kimenetet. Szerintem Ian Canada nevü kínai emberke megoldásai nagyon jók I2S-re. Az USB is jó, ha biztosítható a kellöen nagy buffer méret és a pontos óra (ne tudjon alulcsordulni). Nem az adatvesztés lehet ezeknél a probléma, hanem a meg-megtorpanások - nem ér oda idöben az adat, a buffer alulcsordul. Ezt nem hallani (mert a DA mondjuk tartja a jelet) csak romlik a zeneiség. |
Szerző: | Konzol [ 2018.03.28. 14:48 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Egy viszonylag jól érthető rövid leírás az RT folyamatütemezésről: https://wiki.archlinux.org/index.php/Realtime_kernel A magas prioritású folyamatok megkapják a hozzájuk rendelt időszeletet, ami még persze nem garantálja, hogy végeznek is a feladatukkal, másrészt az is igaz, hogy valamennyi időt muszáj fenntartani a rendszer működésben tartásához, harmadrészt vannak olyan folyamatok, amikre nincs hatással a folyamat ütemezés pl. háttértár elérés, busz késleltetés, hálózati forgalom, továbbá egy bizonyos időnél értelmetlen többet kapnia az adott folyamatnak, mert azt nem tudja kihasználni - hírtelen dekódolná villámgyorsan az flac-t, aztán csak malmozna, mert elküldeni nem küldhetné a dac-nak. Az átviteli protokollok általában csomagokkal dolgoznak. Várnak míg össze nem gyűlik megfelelő mennyiségű adat, majd azt gyorsan elküldik ( MTU ismerős lehet az ISDN korszakból, vagy az 1500 byte-os ethernet keret ). Azaz az adatok termelése szakaszos, míg a fogyasztásuk zenéléskor folyamatos. A mindenkori vevő feladata a pufferelés, hogy az adatáramlás közti szünetekben biztosítsa a megfelelő ellátást a fogyasztónak. Szerintem ez az ami nem szokott igazán jól sikerülni. 44.1K/16bit sztereó hangnál 1msec áthidalása ~350 byte puffert igényel, 192k/24biten ~2kbyte-ot. A vevő simán ki tud futni a pufferből, ilyenkor mindegy a reclock. Feltételezem a vevőkben van valamiféle algoritmus az ilyen puffer leürülések kezelésére. Az nem megoldás, hogy az adó orrba szájba küldi az adatokat, mert azt a vevő nem fogja tudni tárolni. Az javít a helyzeten, hogy a vevő kéri az adatot, feltéve hogy időben meg is kapja. Pár tíz usec késleltetés adó oldalon már gondot okozhat. A vevői kérésnek végig kell futnia az USB vagy TCP/IP rétegeken, majd vissza az adatnak ) Szóval kényes egyensúlynak kell fönnállnia a folyamatok közt. ( A mikrogépnél a folyamatból kimarad egy csomó dolog. A dekódolt adatsor DMA-val kerül közvetlenül az I2S hardverre ) |
Szerző: | Toto [ 2018.03.28. 14:59 ] |
Hozzászólás témája: | Re: audio HTPC építése |
Nekem tetszik az új Windows 10 DWM-je, jól mutatna a fluent design az LCD-s érintőképernyőn is. Miközben megfelelő a zenelejátszó is. Nem lenne rossz ezen megoldani, már szedem szét a telepítőt, aztán meglátom, mennyi erőforrást igényel a rendszer optimalizálva. |
Oldal: 11 / 15 | Időzóna: UTC + 1 óra [ nyi ] |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |