Terhelésre akadozó hang

Linux-haladó

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.

  • 7161 megtekintés

( trey | 2014. 09. 11., cs – 14:12 )

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

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

sudo hdparm -I /dev/sda | grep -i dma
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
	   *	{READ,WRITE}_DMA_EXT_GPL commands
	   *	READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
	    	DMA Setup Auto-Activate optimization

sudo hdparm -I /dev/sdb | grep -i dma
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
	    	DMA Setup Auto-Activate optimization

Linux Mint 17 Cinnamon 64-bit

+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.

( asch v | 2014. 09. 11., cs – 20:32 )

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: 


zsigmond@kisszoba ~ $ lspci
00:00.0 RAM memory: NVIDIA Corporation MCP61 Memory Controller (rev a1)
00:01.0 ISA bridge: NVIDIA Corporation MCP61 LPC Bridge (rev a2)
00:01.1 SMBus: NVIDIA Corporation MCP61 SMBus (rev a2)
00:01.2 RAM memory: NVIDIA Corporation MCP61 Memory Controller (rev a2)
00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev a2)
00:02.1 USB controller: NVIDIA Corporation MCP61 USB 2.0 Controller (rev a2)
00:04.0 PCI bridge: NVIDIA Corporation MCP61 PCI bridge (rev a1)
00:05.0 Audio device: NVIDIA Corporation MCP61 High Definition Audio (rev a2)
00:07.0 Bridge: NVIDIA Corporation MCP61 Ethernet (rev a2)
00:08.0 IDE interface: NVIDIA Corporation MCP61 SATA Controller (rev a2)
00:08.1 IDE interface: NVIDIA Corporation MCP61 SATA Controller (rev a2)
00:09.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2)
00:0b.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2)
00:0c.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:0a.0 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 62)
01:0a.1 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 62)
01:0a.2 USB controller: VIA Technologies, Inc. USB 2.0 (rev 65)
02:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610] (rev a1)
02:00.1 Audio device: NVIDIA Corporation GF119 HDMI Audio Controller (rev a1)

Ami viszont érdekel, az a latency. Hogy vehető nagyobbra?

Szerk.: 

zsigmond@kisszoba ~ $ lsusb
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 002: ID 046d:c216 Logitech, Inc. Dual Action Gamepad
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 003: ID 058f:6362 Alcor Micro Corp. Flash Card Reader/Writer
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 09da:9090 A4 Tech Co., Ltd XL-750BK Laser Mouse
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Linux Mint 17 Cinnamon 64-bit

( locsemege v | 2014. 09. 12., p – 01:24 )

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:]' <<<locsemege
LOCSEMEGE

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:]' <<<locsemege
LOCSEMEGE

( kisssandoradam | 2014. 09. 12., p – 09:13 )

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.

( NCK | 2014. 09. 12., p – 13:25 )

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

( deje | 2014. 09. 12., p – 21:29 )

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)

( log69 | 2014. 09. 13., szo – 01:14 )

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.

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

( ak0sh | 2014. 09. 13., szo – 14:19 )

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

( prion | 2014. 09. 13., szo – 15:03 )

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.