sanji

Audacious jest po prostu źle napisany. Potrafi zużyć 25% zasobów CPU tam, gdzie Winampowi starcza 3% a dla XMMS-a 5%. A szkoda, bo jeśli chodzi o sam interfejs to aplikacja bardzo mi się podoba.

Ja mam na niemal identycznej konfiguracji Slackware + XFCE i jestem zadowolony. Zaletą Slackware jes to, że ma się pełną kontrolę nad tym, co się instaluje więc można bez problemu zainstalować tylko potrzebne minimum programów/ bobliotek. Fedora oczywiście niczym nie ustępuje, ale lepiej mi sie ona jednak widzi na mocniejszych (zwłaszcza jeśli chodzi o RAM) maszynach, gdzie można sie juz spokojnie cieszyć lepszą automatyzacją obsługi.

Można jeszcze prościej, arytmetycznie, łopatologicznie. Zakładając, że mina to wartośc pola = 1, a brak miny to 0, wystarczy zsumować wszystkie pola wokół i sprawdzić wynik: int tab[x][y]; if( tab[x-1][y-1]+tab[x][y-1]+tab[x+1][y-1]+tab[x-1][y]+tab[x+1][y]+tab[x-1][y+1]+tab[x][y+1]+tab[x+1][y+1]>0)... <co tam chcesz zrobić, jak jest mina> Wbrew pozorom, to nie jest więcej obliczeń niż w algorytmie Adi1981. Musisz tyko pamiętać o warunkach brzegowych (w algorytmie autorstwa Adi1981 podobnie), bo, jak mina będzie na brzegu, to wskaźniki x i y wyjdą poza granicę tablicy tab[x][y]. Możesz to zrobić na "if-ach" sprawdzając, gdzie jest kursor, ale to aż 5 różnych przypadków wychodzi. Możesz też dołożyć z każdej strony na "bokach" tabilcy po kolumnie/wierszu pozbawionym min, opisującym nic nie znaczące pola leżące poza ekranem.

Ale jeśli np. dysk podaje temperaturę w stopniach Fahrenheita (a WD to z USA, a tam się tą skalę akurat używa), a smartd uznaje ją za temp. w st. Celsjusza, to wartość okazuje się dziwnie akuratna - np.: 118 °F = 48 °C. Ja bym polecał ręką sprawdzić, czy te 117 stopni to nie jakiś błąd, bo już dziwne się wydaje, że jeszcze dysk się kręci i działa. Z drugiej strony, dysk to nie procesor, więc skąd wziąłby tyle mocy cieplnej?

No RAM to na pewno można dokładać, tylko trzeba być ostrożnym i znaleźć takie kości, jakie zaleca producent, a nie pierwsze lepsze, bo łatwo o problemy z kompatybilnością.

Nie znam tego playera, więc spekuluję (nie rusza u mnie , bo mam brak zależności, a nie chce sobie w systemie śmiecić). W jego opcjach masz takie coś: Options relevant to ALSA/OSS output: -R, --realtime - Try to use realtime (SCHED_FIFO) scheduling for ALSA/OSS output thread. Poza tym takie zjawiska najczęściej wynikają z ustwionego bufora programowego. Im większy, tym większe opóźnienia. Proponował bym zainteresować się, jak wyglądają ustawienia programu. O ile, oczywiście, nie jest to wina błędnie napisanej aplikacji.

Ale te nie są jak na razie freeware , choć są wygodniejsze.

Go gitary jest kGuitar - taki odpowiednik GuitarPro. EDIT: Fakt, naśmieciłem. KGuitar nic nagra, jakoś zmylił mnie post morsika.

Teraz jeszcze znaleźć, jaki to ma związek z buforem, liczbą cykli przypadającą na wielkość bufora sprzętu oraz liczbą ramek w cyklu i będzie grało. Okazuje się, że to są ściśle związane ze sobą sprawy, a ich obecność zdaje się wynikać z architektury kart dźwiękowych i tego, czy sterownik i serwer dźwięku potrafią to w pełni wykorzystać. Dziwne jest to, że samo latency, zdaje się wynikać bezpośrednio z wielkości bufora, jednak, czasami działa poprawnie z wartością z palac wyssaną (teoretycznie nie powinno), a czasem wymaga dokładniejszej. Ostatnio znalazłem conieco wyjaśniające linki: http://www.suse.de/~mana/alsa090_howto.html http://linux-muzyka.ixion.pl/tekst.php?id=25084#a -nie dotyczy ALSY, ale na temat.

Mi się raczej wydaje, że po zapisie/odczycie całego bufora jednorazowo, karta wysyła kolejne próbki (kierunek zależny od tego czy odczyt, czy zapis) tak długo, jak pozwoli ilość dostępnych danych/wolnego miejsca w buforze. Działa to pewno na zasadzie dorzucania do pieca - tak aby nie zgasł, ale i z uwzględnieniem ograniczonej ilości opału, jaki się w nim jednorazowo zmieści. Problem w tym, że jka na razie nie znalazłem nic, co by potwierdzało na 100%, że tak jest. No i to przeklęte latency, które nie wiadomo, gdzie tu zmieścić. Rozwiązanie które podajesz, bardzo by uzależniało przetwarzanie od dostępnej mocy obliczeniowej. Przy 44.1kHz daje to 23 us (!) na przeładowanie bufora. To 44100 razy mniej, niż trwa cykl napełniania/opróżniania bufora. Po co miałby więc w ogóle istnieć takie coś jak bufor, skoro i tak, o tym, czy muzyka bądzie się przycinać, czy nie, decyduje odstęp poszczególnych próbek od siebie? Zakładając ponadto, że zapis całego bufora trwa dłużej niż zapis jednej próbki, wykorzystanie bufora zamiast zapisu "próbka po próbce", zdaje się dodatkowo jeszcze bardziej zwiększać ilość potrzebnej mocy obliczeniowej o tyle, ile jest próbek w buforze, czyli np. 4096-cio krotnie. Tak więc wydaje mi się, że nie jest tak, jak piszesz, bo to by było szalenie mało wydajne.

Witam wszystkich! Od jakiegoś już czasu męczę się z API ALSy. Znalazłem wiele informacji, ale utknąłęm na podstawach. Ewentualne tutoriale są bardzo pobieżne, pisane na zasadzie: "o tak to np. się robi: (...)", niektóre podstawy są wałkowane wiele razy, a inne traktowane jak oczywiste i pomijane milczeniem. Wiem coś niecoś o cyfrowym dźwięku. Problemem jest dla mnie jednak kwestia komunikacji ze sprzętem. Posłuże się tu działającym przykładem: #include <alsa/asoundlib.h> static char *alsa_device = "default"; snd_pcm_t *h_in; snd_pcm_t *h_out; unsigned short buf[8*512]; int err; int main(void) { // otwarcie urzadzenia err = snd_pcm_open(&h_in, alsa_device, SND_PCM_STREAM_CAPTURE, 0); if (err < 0) { printf("ERROR (1a): %s\n", snd_strerror(err)); exit(EXIT_FAILURE); } err = snd_pcm_open(&h_out, alsa_device, SND_PCM_STREAM_PLAYBACK, 0); if (err < 0) { printf("ERROR (1b): %s\n", snd_strerror(err)); exit(EXIT_FAILURE); } // ustawienie parametrow urzadzenia err = snd_pcm_set_params(h_in, SND_PCM_FORMAT_U16, SND_PCM_ACCESS_RW_INTERLEAVED, 1, 16000, 1, 300000); // ostatni parametr to "latency" if (err < 0) { printf("ERROR (2a): %s\n", snd_strerror(err)); exit(EXIT_FAILURE); } err = snd_pcm_set_params(h_out, SND_PCM_FORMAT_U16, SND_PCM_ACCESS_RW_INTERLEAVED, 1, 16000, 1, 300000); // ostatni parametr to "latency" if (err < 0) { printf("ERROR (2b): %s\n", snd_strerror(err)); exit(EXIT_FAILURE); } // pętla kopiująca while(1) { err = snd_pcm_readi (h_in, buf, 8*512); // Kopiowanie z wejścia mikrofonowego if (err == -EPIPE) { puts("ERROR (3a): snd_pcm_prepare\n"); // zapobiega wywalaniu się programu na błędach odczytu z urządzenia snd_pcm_prepare(h_in); } else if (err < 0) { printf("ERROR (3a): %s\n", snd_strerror(err)); } err = snd_pcm_writei(h_out, buf, err); // Zapis do wyjścia głośnikowego if (err < 0) { err = snd_pcm_recover(h_out, err, 0); } if (err < 0) { printf("ERROR (3b): %s\n", snd_strerror(err)); break; } } snd_pcm_close(h_in); snd_pcm_close(h_out); } Teraz czas na pytania: 1) Czym jest to "latency" ustawiane jako ostatni parametr funkcji snd_pcm_set_params()? Na pewno jakieś opóźnienie, tylko pomiędzy czym, a czym? 2) Dlaczego dźwięk jest kopiowany z mikrofonu na głośniki w sposób ciągły, choć funkcje I/O wywoływane są jedna po drugiej, na zmianę, a nie jednocześnie? Na pewno to jakieś banały. Wiem, że funkcje *writei()/*readi() to takie rozszerzone funkcje języka C write() i read(), ale w mojej książce o C tych drugich nie ma, a manual jest krótki i rzeczowy. I ani słowa o tajemniczym latency nie widać ... Nie obrażę się też za jakiś pouczający link. Wszystko dobre, byleby na temat.

Nie wiem, jak sprawa wygląda obecnie, ale jak kolega zajmował się z 2 latka temu sprzedażą acerów, to miał większą ilość reklamacji, niż sprzedanych sztuk. Tak np. między innymi każdemu padał prawy zawias od matrycy, dvd-romy często nie łączyły. Straszny badziew. Za małą kasę dostajemy niezły hardware, ale obudowa zrobiona w najtańszy możliwie sposób.

Spróbuj pokombinować z czcionkami "Preferences > Fonts", może nie masz w systemie domyślnej czcionki XMMS-a. Gorzej jeśli okaże się to kwestią kodowania, ale najlepiej zacząć od najłatwiejszego Co do drugiego pytania, to wystarczy zaznaczyć katalog i zamiast podwójnym kliknięciem (jak z pojedynczym plikiem) nacisnąć przycisk "otwórz" (czy jakośtam podobnie).

Jakoś nie widzę specjalnej różnicy pomiędzy Twoim a moim configiem. Poza tym że iwconfig wlan0 essid ... ap .... mode Managed channel ... mam w jednej linijce, ale to nie powinno być problemem. Nie masz przypadkiem filtracji MAC? I pytanie kluczowe: jaka karta (tryb monitor więc chyba Atheros)? Proponuję zrobić tak: iwconfig - po uruchomieniu systemu iwconfig - po powrocie z trybu monitor, jak NetworkManager zaczyna wariować. I pokaż tu wyniki tych dwóch operacji.

Nałatwiej byłby umieścić moduł sterownika niechcianej karty, czyli najwyraźniej snd_via82xx, w /etc/modprobe.d/blacklist Wtedy moduł będzie można załadować tylko manualnie i po starcie systemu, Linux karty nie będzie widział.

Taki efekt wywoluje np. zmiana MAC-a przez ifconfig. Kiedyś to ponoć działało, teraz juz nie. Należy zmienić MAC urządzenia bazowego (zazwyczaj wifi0), a nie tworzonych na nim wiryulanych interfejsów. Ja zmieniam MAC z konsoli (w zasadzie to skryptem, ale na jedno wychodzi) poleceniem ip link set addr nowy_adres_MAC dev wifi0 tak, jak zaleca poradnik madwifi. Można też to zmienić w pliku konfuguracyjnym /etc/sysconfig/network-scripts/ifcfg-<nazwa-twojego-interfejsu>, ustawiając zmienną MACADDR=nowy_adres_MAC. To, co teraz otrzymujesz jest jak najbardziej normalne, przynajmniej na Atherosach.

Więc pytanie brzmi: jak zmieniłeś MAC? Czy jeśli wpiszesz ifconfig [i]interfejs[/i] to wartość HWaddr jest taka jak ustawiłeś?

Wiesz, w sumie to Fedora 9 jest systemem równoległym na osi czasu MS Viście, więc nie ma co się spodziewać, że standardowo wystarczy jej tylko to, co XP potrzebuje. Dziś 1GB to już przecież co najmniej standard. Ja instalowałem dziewiątkę na 512 i sytuacja wyglądała identycznie (może bez tych błędów z javą). Pomogło wywalenie zbędnych (jak dla mnie) usług i pakietów, a było tego sporo. Największą różnicę dało się odczuć po wyrzuceniu SELinuxa, ale wyrzuciłem też PulseAudio i sporą ilość demonów. Po tym wszystkim w zasadzie przestałem się zastanawiać nad szybkim kupnem dodatkowej kości RAMu. Wszystko więc zależy od tego czego potrzebujesz.

Aż tak dokladnie to nie wiem . Pewno do identyfikacji w systemie. Musiłby ktoś z większą wiedzą wyjaśnić.

HWADDR to jest adres fizyczny jaki ma wpisany karta sieciowa. MACADDR jest adresem widzianym z zewnątrz i możesz go softwear-owo ustawić i wtedy w komunikacji system będzie używal go zamiast HWADDR. Co nie zmienia faktu, że HWADDR pozostanie ten sam.

Ja planowałem przejście z DVB na Linuksa. Miałem kilka pytań, więc zarzuciłem tu posta i nikt nie odpowiedział, więc porzuciłem temat. W każdym razie najnowsze pluginy pod Windowsa pozwalają na pobieranie kluczy automatycznie bez połączenia z siecią. Może do wtyczek dla xine też to wprowadzono? Warto sprawdzić. Chociaż w sumie to już niewiele czasu zostało

Jaki masz sterownik grafiki ustawiony w pliku /etx/X11/xorg.conf? Chodzi o pole: Section "Device" ... Driver "twój_sterownik" ... EndSection Fedora, rozumie się, że 9-ka?

KHexEdit jest w paczce kdeutils. Nie trzeba specjalnie szukać.

Bardzo możliwe. Zapędziłem się EDIT: No i po wszystkim trzeba oczywiście sformatować mkfs'em.

Wg mnie powinieneś użyć programu fdisk /dev/twój_dysk (czyli /dev/sda). Trzeba usunąc nim partycję, a następnie w wolnym obszarze utworzyć nową. Domyślnie tworzona jest partycja w systemie plików ext3. Tylko taka drobna uwaga.. Nowa partycja będzie z pewnością miała już inny niż 6, a partycje leżące za nią mogą mieć potem numer o jeden niższy, więc jak coś się zacznie potem sypać, to czeka mała edycja fstab'a.