Kategoria: Linux

Opublikowane w

Optymalizacja MPD.

Jakiś czas temu znalazłem coś, co uważam za ostateczne rozwiązanie dla muzyki pod Linuksem. Ale, po pewnym czasie używania, stwierdziłem, że coś to MPD za duży apetyt ma na procesor. Przypomniał mi o tym sirmacik przy problemach z „charczącym” dźwiękiem, których powodem była różna częstotliwość muzyki i karty. Konkretnie – odtwarzanie Radio Baobab owocowało zużyciem procesora ok. 8-12% wg top (strumień ogg). Niby żaden dramat, bo laptop demonem szybkości nie jest, ale szybki test na mplayerze pokazał, że jemu wystarcza 3-5%.

Oczywiście mplayer to inna bajka – ma wykrywanie procesora podczas uruchomienia, a MPD takich wodotrysków niestety nie ma (strumienia PR 3, czyli Trójki też nie umie odtworzyć, niestety Trójka działa w MPD, wymagany odpowiedni format źródła i odpowiednia wersja MPD – w 0.15.12-1.1 nie działało, mimo zmiany formatu, w 0.15.15-2 z Debiana unstable działa). Zaczął się więc debug. Po pierwsze, trafiłem (nie po raz pierwszy) na świetną stronę opisującą tuning MPD. Po wypróbowaniu wszystkich praktycznie wszystkich sposobów na wyłączenie resamplingu, po braku jakichkolwiek efektów, byłem gotów na przekompilowanie MPD i bibliotek z włączeniem optymalizacji na PIII (bo karta – tania karta USB – uparcie działała w 48 kHz), ale…

Drugiego dnia dobrzy ludzie na IRCu zwrócili moją uwagę na niepozorny i zdecydowanie niewyeksponowany w owym czasie (czytaj: słowa o nim nie było) na wspomnianej stronie parametr samplerate_converter. Okazało się, że jest obecny i opisany w konfigu (cóż, tam nie szukałem, skoro jest dedykowana strona o tuningu). Okazało się, że po dodaniu w konfigu linii:

samplerate_converter            "internal"

MPD zużywa dokładnie tyle procesora, co mplayer – 3-5%. Różnica w jakości jest słyszalna, ale jeśli ktoś słucha głównie radia internetowego, na słabym sprzęcie audio i nie na słuchawkach to spokojnie i bezboleśnie daje się słuchać. Jeśli ktoś ma słaby sprzęt lub nie ma koprocesora, to wręcz nie ma wyboru. 😉

PS. Oczywiście dopisałem stosowny fragment na ww. wiki, w sumie wypada od tego zacząć, żeby sprawdzić, czy o resampling chodzi… Nawiasem, jeśli jest problem z dźwiękiem pod Linuksem, szczególnie w mpd czy mplayerze – przerywa, harczy, tnie, to prawdopodobnie też kwestia ustawień resamplingu. Ww. strona na wiki podaje przyczynę i sposoby rozwiązania.

Opublikowane w

Upgrade Lenny do Squeeze – co poszło źle.

Ponieważ system po nieudanej aktualizacji już działa (w ogóle okazało się, że przyczyną „problemów z grubem” była w rzeczywistości najprawdopodobniej niedociśnięta taśma od stacji dysków) i mogę dostać się do swoich danych, to pora na konkrety i przestrogę.

Komunikat, który mówił o problemach z przejściem na dependency based boot przy upgrade z Lenny’ego do Sarge Squeeze i który może nie tyle zignorowałem, co chciałem zająć się nim po reboocie (bo zapisałem) wyglądał dokładnie tak:

Unable to migrate to dependency-based boot system

Tests have determined that problems in the boot system exist which prevent migration to
dependency-based boot sequencing:

insserv: warning: script 'K20atieventsd' missing LSB tags and overrides, insserv: warning: script
'atieventsd' missing LSB tags and overrides,

If the reported problem is a local modification, it needs to be fixed manually. If it's a bug in the
package, it should be reported to the BTS and fixed in the package. See
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot for more information about how to fix the
problems preventing migration.

To reattempt the migration process after the problems have been fixed, run "dpkg-reconfigure sysv-rc".

Skrypt atieventsd pochodzi z flgrx, z którego nie korzystałem od migracji na Lenny’ego. Taka zemsta ATI/AMD zza grobu.

Ale co sobie powalczyłem, to powalczyłem (kolejne sprawności zdobyte: instalator nie jest taki świetny i ma głupie defaulty dla instalacji gruba – kto to widział, że przy instalacji wszystkiego na sdb i niczego na sda chce umieścić gruba na sda?; rescue mode daje radę). Okazało się, że CD-ROM też już nie działa – zasilacz od dawna był słaby i miał problemy z kręceniem dwoma dyskami, ale teraz doszło do tego, że i jednym nie kręci, jeśli CD-ROM jest podpięty. No chyba, że stacja dyskietek tak bruździła. Nie wiem, nie wnikam, działa – nie dotykam (ładne rymowane motto, swoją drogą).

UPDATE: Inna możliwa przyczyna, to własny – a nie dystrybucyjny – kernel. Dziś kolejna osoba miała problem ze swoim kernelem na Squeeze, identyczne objawy (pusty /dev), a na dystrybucyjnym działało OK. Instalacja linux-image-2.6-amd64 (lub linux-image-2.6-486 dla systemów 32-bitowych) przed rozpoczęciem upgrade’u do Squeeze wydaje się dobrym pomysłem. 😉 Zresztą jest to opisane w release notes procesu aktualizacji Lenny do Squeeze (wersja robocza; TBH nie czytałem przed aktualizacją – nie wiem czy był już dostępny – mea culpa).

Opublikowane w

Historia pewnego upgrade

Minęły prawie 2 lata odkąd zrobiłem upgrade tej maszynki do Lenny’ego. Stwierdziłem, że Squeeze, którego używam od dłuższego czasu jest dobry, przydałoby się parę nowych pakietów no i można przetestować jak ten upgrade wychodzi. KDE 3.5 też jakoś nie jest tym, co mi ostatnio pasuje (a pasuje mi LXDE), więc stwierdziłem, że parę dni wolnego to dobry moment, żeby zrobić upgrade.

Problem numer jeden, który uniemożliwił mi zalecaną wersję upgrade’u, to za mała ilość wolnego miejsca. 1 GB wolnego na /, po porządkach 1,3 GB. Zdecydowanie nie to, co tygrysy lubią najbardziej. Postanowiłem, że po prostu podmienię wpisy w sources.list z lenny na squeeze, zrobię wajig update; wajig upgrade a następnie wajig dist-upgrade. Wcześniej wywaliłem jeszcze javę i OpenOffice. Gołe dist-upgrade niestety nie mieściło się.

Update poszedł bez problemu, po nim kontrolny reboot. Wszystko ładnie działa. Pora zatem na dist-upgrade. Ten też w zasadzie przebiegł bezproblemowo. Jedyne co pojawiło się z dziwnych rzeczy, to ostrzeżenie, że nie może korzystać z dependency based boot, które skrypty przeszkadzają i gdzie szukać pomocy. Oczywiście zapisałem sobie te komunikaty, dałem OK. Update się zakończył, pora na reboot.

I tu zaczęły się schody. Przy próbie montowania /home z osobnej partycji, stwierdził, że /dev/hda3 nie istnieje i zaproponował uruchamianie w maintaince mode. Hm! Stwierdziłem, że pewnie kwestia kernela (mam własny), więc doinstaluję dystrybucyjny. Prawie się udało, niestety grub nie chciał się zaktualizować – brak dysków w /dev. Faktycznie ich nie było. Trochę powalczyłem ze skryptami startowymi, które były prawdziwą przyczyną zamieszania (bez większych sukcesów, namierzyłem jedynie nieuruchomiony hald) i stwierdziłem, że skoro / jest na osobnej partycji, to najszybciej będzie zainstalować system debootstrapem. Przy okazji zmigruję z ext3 na ext4.

Tylko jak uruchomić debootstrap, jeśli USB jest nieczynne (dziękujemy padniętym kondensatorom na płycie), a live nie ma? Przełożę dysk! Tak też zrobiłem. Niedługo później system był zainstalowany. Teoretycznie, bo aktualnie przy wejściu do gruba wykonuje malowniczy reboot.

Właśnie ściągam płytę instalacyjną. Mam nadzieję, że nagrywarka i czytnik są sprawne i że po zainstalowaniu instalatorem będzie się bootował.

Podsumowując: mam dość upgrade’ów, a konkretnie żonglowania sprzętem, na dłuższy czas, a już na pewno nie na sprzęcie, gdzie w prosty sposób nie można odpalić live. Najlepiej z USB.