Mam taki problem, a zbyt wielu informacji w internecie na ten temat niema.
Mam do napisania program w RtLinuxie, ktory m.in bedzie generowal na wyjsciu karty dzwiekowej sygnal sterujacy. Czestotliwosc tego sygnalu musi byc stala, wiec dlatego wymagany jest kernel RealTime typu hard.
Przegladajac gotowe przyklady w necie, to wyglada na to, ze moge wziac gotowa moja funkcje fun, wrzucic ja do ktoregos z przykladow, tak zeby to wygladalo np. tak:
Kod: Zaznacz cały
rt_task_init(&task, fun, 0 , 3000, 1);
rt_task_make_periodic(&task, (RTIME)rt_get_time()+(RTIME)1000LL, (RTIME)(RT_TICKS_PER_SEC / 8192LL));
W zalaczonych do RTLinuxa przykladach sa sterowniki dla protu COM (rt_com). I wlasnie to spowodowalo ze zaczalem sie zastanawiac, czy nie bede musial tez specjalnie przepisac sterowniki do karty dzwiekowej lub powyczyniac z nimi inne czary.
Prosze o jakies wskazowki, moze ktos w tym grzebal bardziej powaznie i moze mi pomoc lub naprowadzic.
Czy ktos wie moze jak to jest przy programowaniu z wykorzystaniem karty dzwiekowej? Jaki maksymalnie mozna wycisnac z niej okres probkowania?
Pozdrawiam
-------------------------------------------------------------------
Teraz juz wiem...
Moze komus sie przyda, bo w sieci byly opisywane takie problemy. Takie wywolanie jakie opisalem bedzie bez sensu, bo jadra pracujace w czasie rzeczywistym bedzie sie odwolywalo do innego jadra, ktore juz tych wymogow nie spelnia.
Trzeba by miec przepisane sterowniki dla czasu rzeczywistego. Tak zrobiono w dla:
com -> rt_com RTLinuxie oraz dla
sieci w RTAI -> RTnet
Generalnie przenoszenie czegos do czasu rzeczywistego czasami sie nie oplaca - wiecej przy tym pracy niz korzysci. Bo generalnie komputery sa coraz szybsze, karta dzwiekowa ma swoj bufor, jest DMA. Dodatkowo korzystajac ze zwyklego jadra z dodaniem jakis lat typu lowlatency mozemy bawiąc się dzwiekiem z dobrą jakoscią.
I tym razem okazalo sie ze plastycznosc linucha jest wieksza niz konkurencji
Pozdrawiam
