Sziasztok!
Egy ideje ismét fő oprendszerként használok linuxot, névlegesen épp Linux Mint 17-et. Én Windowsról jöttem át és ott a foobar2000-et használtam zenehallgatásra. Itt most annak a linuxos klónját, a Deadbeef-et használom, egyébként remekül bevált, szeretem.
Na most nekem Windowson sosem esett szinte meg az, hogy akár 100% terhelésnél is, de akadozott volna a zenelejátszás. Ellenben linuxon az a baj, hogy megy a zene és én elindítok mondjuk valami terhelő folyamatot, ami kihasználja jól a gépet és megesik bizony, hogy szaggat, akadozik a zene. A hang-alrendszer pulseaudio tudtommal, az alapot nem váltottam le.
Tudja valaki, mivel lehetne ezt kiküszöbölni? Esetleg a zenelejátszót nagyobb prioritásúvá kéne tenni? Nem hiszem, hogy ezzel egyedül csak én találkoztam eddig.
Hozzászólások
Le tudnád írni, hogy hogyan tudnám a problémát reprodukálni?
--
trey @ gépház
Hát pl megy a zene a háttérben szépen, aztán elkezdesz olyasmit csinálni, ami nagyon zabálja a procit/ramot/diszket. Sajnos nincs konkrét módszer rá ami beugrana, de sokszor találkoztam ezzel már Linux alatt. Nyilván nem netezés közben történik, hanem mondjuk ha fordítasz közben, vagy tömörítesz vagy effélék.
Szerk.: Sokszor gondoltam már rá, hogy azért lehet ez, mert linuxon, illetve tán a *NIX világban majdnem minden szerver-kliens felépítésű és talán az a szűk keresztmetszet, nem?
Linux Mint 17 Cinnamon 64-bit
Tudom, hogy nem teljesen releváns, de nekem nem szakadozik a deedbeef. Fordítás, upgrade, tömörítés során sem. Ach 64-et használok. Szerintem valami más gond lesz ott.
Tévedés ne essék, többnyire nem szakadozik! Csak néha, amikor meg van terhelve a gép, pl nagy diszk terhelés mellett. Ennek a miértjét nem értem igazából. Amúgy relatíve friss install, nem kotortam különösebben bele a rendszerbe. Meg nem Mint specifikus a gond, nem is gépspecifikus, mert másik gépen is találkoztam már ezzel mindennapi használatnál. Ez inkább amolyan általános linuxos bibi. Kicsit olyan, mint amikor nagy terhelésnél a kurzor is meg-meg tud akadni, ami szintén kevésbé jellemző Windowson. Itt is a szerver-kliens modellt gyanúsítóm régóta. Tipikus linuxos (vagy xorgos) gebasz, ami évek óta így van.
Amúgy bár a masina nem a legújabb, de azért nem olyan gyenge, hogy ez legyen a szűk keresztmetszet:
ASUS M2N deszka
AMD Athlon64 X2 6400+
2x2GB DDR2-800 RAM CL5
GeForce GT610 + nvidia driver
Linux Mint 17 Cinnamon 64-bit
Hát passz. Nálam otthon (chakra 64) sem jelentkezik. Utoljára ilyen meg-megakadást kb. 6-8 éve láttam linuxon.
Mivel régi gép + új OS kombó, ezért rákérdezek: DMA be van állítva?
hdparm -I [device neve] | grep -i dma
Linux Mint 17 Cinnamon 64-bit
Ez jól néz ki , nem ez lesz a probléma.
Inkább a hangkártya driverre, vagy a pulseaudio-ra gyanakodnék. Nálam hasonló konfigon a Skype "recsegett" régen, de látszólag nem terhelésfüggő volt.
+1
első linux-os váltásomnál pulseaudio még elég problémás volt, nem tudom most is az-e, gyakorlatilag ugyan ezt produkálta, de kb fél évre rá egy frissítés után megszűnt (akkor végül más miatt, de vissza is váltottam windows-ra)...kiemelném, nem ma volt, 5+ éve.
"Ez inkább amolyan általános linuxos bibi"
miva?
--
Debian GNU/Linux
Mivel csak Linux alatt találkoztam ilyennel, ezért nem a géppel van baj, hanem az OS valamelyik komponensével.
Linux Mint 17 Cinnamon 64-bit
A zene lejátszás hard real-time feladat, mivel ha egyetlen csomag is későn érkezik, akkor az már hallható. Nekem régebben akkor fordult ilyen elő, amikor a latency-t próbáltam minél kisebbre állítani. A lejátszás blokkokban történik, és a blokkméretből adódik egy latency (késleltetés). Ha a blokkméretet és a latency-t kicsire állítjuk, akkor már nagyon kicsi késés is problémát okozhat. Viszont ha a latency és blokkméret nagyobb, akkor hosszabb elakadásokat tolerál a rendszer. Tehát az első, amit megpróbálnék, az az, hogy a blokkméret állítható-e a driverben, és ha igen, akkor nagyobbra venném. Ettől nem lesz semmi rosszabb (ha nem studiózni akarsz).
A másik dolog, amit meg lehet nézni, az az, hogy van-e valami gyengébb minőségű driver a gépeden? Például régebben túlterhelt USB meg tudta akasztani a rendszert, vagy volt olyan touchpadem, amitől minden másodpercben egy frame-t kihagyott a video lejátszás. Nem debuggoltam ki az okot, de odáig eljutottam, hogy a modult letiltva megoldódik a probléma. Tehát ilyenekkel is lehet szórakozni.
Köszi!
Érdekes kérdést vetettél fel. Pl az alaplap USB vezérlője egy érdekes vadállat... nVidia nForce chipset ugye. Na most pl Windows alatt ha bedugtam a Logitech Dual Action controllerem, akkor nem működött, noha plug & play lenne. :\ Nem ismerte fel egyszerűen. Linux alatt sem! Viszont a VIA 4 portos USB2.0 PCI kártyámmal perfektül megy. Amúgy nincs sok USB eszköz. Az egerem USB. A billentyűzet egy régi IBM darab, PS/2-es. Ami még USB, az a multi kártyaolvasóm (gépbe építhető 3.5", azon 4 eszköz is lóg). Az 2db belső header-t foglal el. Egy port a 4 olvasónak 1 pedig az előlapi kivezetésnek.
De beszéljen helyettem az lspci:
Ami viszont érdekel, az a latency. Hogy vehető nagyobbra?
Szerk.:
Linux Mint 17 Cinnamon 64-bit
Amikor foglalt a busz, magam is tapasztaltam a jelenséget, pl. Fedorán a selinux-policy-targeted csomag telepítése sok CPU-t és HDD-t képes megenni.
Amit most írok, fogadd erős fenntartással, de úgy emlékszem, a pulseaudio a minimális, de szükséges latency-hez dinamikusan állítja a buffer méretet, mégpedig talán úgy, hogy amikor alulcsordul a buffer, megnöveli annak méretét. Viszont akkor már késő, mert szerintem akkor már épp elakadt a hang egy pillanatra.
Aki jobban tudja, ez pontosan hogyan van, kérem, pontosítson!
Ha a tsched=0 paraméterezést használod, akkor megszakításhoz lesz időzítve a dolog, több erőforrás megy rá, de szerintem nincs mit tenni, ha irreálisan soká kerül a vezérlés a zenelejátszó programra. Például swap-elés miatt, nagy iowait miatt, akármi oknál fogva.
Ezzel csak azt akartam mondani, hogy a tsched=0 sem lesz tuti megoldás. A gond az, hogy maga a lejátszó alkalmazás nem merev időzítésű, ugyanakkor a bufferből a hang állandó sebességgel ürül. Az oprendszer kb. semmit sem garantál az alkalmazás időzítésére.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Emlékszem korábban ezt kellett beállítani, hogy ne sisteregjen a Skype. Azt nem használok már, szóval nem tudom, hogy így van-e még, de most beállítottam. Majd meglátjuk hosszabb távon.
Linux Mint 17 Cinnamon 64-bit
A Skype-ot már normálisan illesztették a pulseaudio-hoz, szóval amiatt nem kell. Inkább csak méláztam a dolgon, mert akármilyen statikus is a buffer kezelése, akármennyire nagy is a buffer, mindig lehet annyira későn adni a vezérlést egy process-nek, hogy alulcsorduljon a buffer.
A gond abból következik, hogy az operációs rendszer nem valós idejű időzítésekre van kitalálva, így csak reménykedhetünk abban, hogy nem lesz baj.
Hasonlatként a TCP jut eszembe. A protokoll biztosítja a csomag hibátlan megérkezését - szemben az UDP-vel -, hiszen hibánál ismétel, de ha elvágják a kábelt, akkor azon a TCP sem segít. Szóval vannak korlátjai a dolognak.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ilyen gondom nekem is volt és pont Linux Mint-tel, bár én akkor még a 14 vagy 15-ös változatát használtam. Nem akarom a rendszerre fogni, de én azóta váltottam. Nekem ez akkor javult meg, mikor a (nagyon!) lassú HDD-ről egy elég gyors SSD-re váltottam és deadline ütemezőt kezdtem használni Fedora KDE-vel. A gép egyébként elég erős 8GB ram és i5-2410M van benne, tehát ebből az is következik, hogy nekem a HDD teljesen visszafogta a rendszert és bármit csináltam zenehallgatás mellett, akkor a zenelejátszó egy kicsit megakadt.
Nálam nagyobb IOwait esetén akadozott (System Load Indicator), tipikusan 100+ megnyitott böngészőablak esetén, amikor a Firefox úgy megterheli az SSD-t, hogy még az egérmozgatás is szaggat. Néha munkámból fakadóan előfordul az 500 megnyitott oldal is.
Ilyenkor volt, hogy helyre sem állt a PulseAudio a Firefox kilövésével, mindent kb 60%-os sebességgel, másodpercenként kb. 2-3 megszakítgatással játszott le 0 közeli prociterhelés mellett is. Próbáltam a PulseAudio újraindítását, de az nem segített, így maradt a teljes újraindítás. 1-2 havonta belefért. Végül kapott még a rendszer memóriát (8-->16GB) és egy kis Firefox-tuningot, így ez utóbbi jelenség megszűnt.
Javaslat: nézd meg melyik alkalmazás okoz magas IOWait-et, és azt próbáld optimalizálni/lecserélni.
Rendszer: Ubuntu 12.04
Jobban belegondolva sok írás/olvasás közben szokott ez leginkább történni. Amúgy többször volt ilyen, amikor még NTFS partíción voltak az adatok. Most ext4 és tök jó, ritkán történik ilyen. A Torrent partícióm pedig btrfs, az még gyorsabb. (lemezről lemezre közel 90MiB/s -el mozgattam!)
Linux Mint 17 Cinnamon 64-bit
-
Több lehetőség is adódhat:
- növeld az erőforrásigényes háttérprogram nice szintjét (habár ez inkább a cpu-ra vonatkozik, de egy próbát megér) vagy
- csökkentsd a zenelejátszó progi nice szintjét
vagy esetleg
- ulatencyd-t próbáld ki, nekem bevált (habár hang akadozásom nincs)
Jó lenne megállapítani, hogy melyik szoftver réteg felelős a hibáért. Tedd meg hogy vlc-vel is megnézed a lejátszást nagyobb terhelés alatt, hogy kizárjuk hogy a foobar a hibás. De reprodukálhatóan. Tehát ugyanazt a terhelési műveletet futtasd vlc közben is, amely megakasztotta a foobar-t.
Még mindig deadbeef-et használok... :D
Amúgy menet közben rájöttem, hogy nagy lemez írás/olvasáskor van ez! Pl sok gigányi adatot mozgatok/másolok. Renszerint érintett benne a rendszer-diszk is. Ez magyarázat lehet?
Linux Mint 17 Cinnamon 64-bit
SSD-d van vagy HDD? Ha SSD, akkor az elevator=deadline kernel parametert bele kell tenni a boot-hoz. Ha lemez, akkor szerintem nem kellene hogy ez okozza, mert az nem vesz el annyi CPU-t.
Ha HDD-d van, akkor szerintem lehet hogy a lejátszó progi nem optimális. Akkor azt mondom teszteld VLC-vel a lejátszást nagy I/O terhelés mellett.
Lehet a program nem optimális, nem tudom... de most egy ideje nem volt már gond. Kikapcsoltam minden DSP-t meg ilyenek. Nem tudom van-e köze hozzá, de a program pythonban íródott azt hiszem. Más programot nem használtam. Ezt azért használom, mert olyan, mint a foobar2000 Windows alatt: testreszabható a kinézet, semmi fölösleges csicsa vagy ilyesmi, csak a lényeg. Amúgy HDD-t használok.
Linux Mint 17 Cinnamon 64-bit
Esetleg még annyit ötlet, hogy akadozásnál a lejátszó folyamat CPU használatát kellene megnézni.
Lejátszáshoz én ezt használtam régebben: Audacious
http://hup.hu/node/103511
http://audacious-media-player.org/
Az nem tetszik. Egyedül a deadbeef váltotta be a reményeimet az interface-t illetően, névleg, hogy minimalista, pont mint a foobar2000 és testre is szabható.
Linux Mint 17 Cinnamon 64-bit
Nem hiszem, hogy klienstől függ. Alulcsordul valamelyik buffer. Vagy a pulseaudio, vagy a hangkártya buffere. Gyakrabban kellene bele tunkolni az adatot, de nagy i/o terhelés esetén ez nem valósul meg.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nálam terheléstől független akadozik a Ritmusdoboz hanglejátszása.
Megfigyeltem, hogy ilyenkor a "Kimeneti" hangerő csúszka nullára ugrik egy pillanatra a hangbeállítások alatt.
Nekem úgy rémlik, hogy azóta szopódom ezzel, amióta a HDMI csatira dugtam az új monitort, amin van Jack dugó is (üresen)...
Ja, meg random elmegy egy pár másodpercre a kép néha.
Szintén nVidia van a dologban (videokároly).
https://www.youtube.com/watch?v=_36yNWw_07g&feature=youtu.be&t=10s
Nálam akkor van ilyesmi, ha leterhelődik a disk nagyon. Ha pl nagy filokat másolok. De akkor is ha neki áll swappelni a rendszer, mert tele lesz a memória. Valami az I/O ütemezővel lehet. Én próbáltam állítgatni egy időben, de nem igazán sikerült rendesen megoldanom. És mivel ritkán jelentkezik nem szórakoztam vele túl sokat. De azért fura ügy.
Nálam 6+ éves gépen ilyen nincs. Se HDD-vel, sem pedig SSD-vel, ahol nagy átvillelel másolódnak fájlok és a CPU-t teljesen megeszi alatta. Érdemes lenne lenyomozni a problémát.