jeszcze raz temat dzwiekow

ostatnio probuje zrobic z dzwiekiem pod windowsem
cos bardziej zlozonego niz odegranie wave'a

glownie chodzi mi poprawne [1] rownolegle i [2] wzglednie
bezpooznieniowe emitowanie dzwiekow pod windowsem

niestety w necie nie moge poki co (po prawie dwu dniach
szukania) doszukac sie dobrych tutoriali/materialow na ten
temat

poki co glownie skupialem sie na probach i poszukiwaniu info
nt winmm ale z tego co jest napisane waveOutWrite nie bardzo
nadaje sie do produkowania rownoleglych dzwiekow (choc to
nie jest dla mnie zupelnie jasne) pozatym podobno ma duza latencje
ok 30 ms

znalazlem ogolne info nt kernel streaming i ew bylaby to dobra
metoda ale jako programowanie blizej hardware moze byc ew
narazone na sypanie sie aplikacji w zaleznosci od sprzetu

(do tego nie wiem jak to jest z ta niezbedna mi 'rowlolegloscia'
wavow - czyli sprzetowym miksowaniem)

o innych rozwiazaniach mam jeszcze mniejsze pojecie
ale podkreslam ze w pierwszym rzedzie interesuja mnie
szysto systemowe rozwiazania (tj bez dorzucania jakichkolwiek
libow do systemu

ktos moze udzielic jakiejs porady (glownie uwzgledniajace to co
powiedzialem: bez dodatkowych libow i rownolegly dzwiek najlepiej
z mala latencja) - zna chocby jakies dobre materialy do
dokumentacji itp?


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Drogi Fiże, wielki generale Kenobi, czcigodny profesorze Kibonte...


> ktos moze udzielic jakiejs porady (glownie uwzgledniajace to co
> powiedzialem: bez dodatkowych libow i rownolegly dzwiek najlepiej
> z mala latencja) - zna chocby jakies dobre materialy do
> dokumentacji itp?


Zdaje się, że święcie wierzysz w:
1) boskość WinApi (szybkość, funkcjonalność, poprawność koncepcyjną)
2) nie omylność M$ (zwłaszcza jego WinApi jako dzieła więczącego rozwój
systemów operacyjnych)
3) wyższość programowania proceduralnego (język C)

Podczas gdy nawet M$ nie wierzy w 1) i 2) ani nawet w 3):

ad 1) wkrótce po premierze Windows 95 okazało się, że do gier jest
potrzebne coś lepszego niż WinApi - więc szybko dokręcono zestaw
bibliotek DirectX. Nie wiem czemu unikasz DirectX skoro (OIMW) są to
biblioteki C obecne we wszystkich windach od 1998 roku. OIMW DirectX
góruje zarówno szybkością jak i funkcjonalnością nad WinApi. OIMW w
nowszych windach pod WinApi śmiga DirectX.

ad 2) Brnięcie w zaparte w technologie M$ może być uzasadniane a)
stabilnością i b) funkcjonalnością oferowaną przez windę które
przewyższają konkurencję. I faktycznie przewaga M$ Windows jest ogromna
i raczej nie zagrożona. Tym nie mniej ograniczanie się do jednego
systemu to brnięcie w kanał. Można zrozumieć też pogląd że nie warto się
zajmować systemami które nie rokują jako alternatywa wobec Windows (na
ile poważne jest Kubuntu: ostatnie wyszło w kwietniu a do września nie
działały sterowniki NVidia Geforce 2MX (chyba dla pozostałych Geforców
też nie działały bo widziałem podobne nagłówki na liście błędów) bo
jakieś tam ABI nie grało i dopuki odpowiednia ilość użytkowników nie
potwierdziła tego błędu nikt się tym nie zajmował). Dlatego moim zdaniem
rozsądną strategią obronną przed dominacją M$ i przed brnięciem w nie
rokujące systemy są biblioteki wieloplatformowe. Konkretnie mam na
myśli, że zamiast WinApi czy DirectX raczej bym brnął w SDL lub OpenGL i
OpenAL (jeśli już się trzymać czystego C i robienia dem czy gier).

ad 3) Pewną zaletą czystego C jest to, że jest większa świadomość jakie
funkcje się wywołuje, oraz łatwość wywołania dowolnej metody. Jednak pod
względem architektury programu stosowanie C to praktycznie ciągła pogoń
za cechami C++. Plik źródłowy *.c opisuje zawartość pliku *.o w którym
oprócz funkcji często znajdują się również "zmienne globalne" konieczne
by przechowywać dane robocze programu. Więc czym jest taki plik *.o? No,
jest on po prostu obiektem typu singleton. I cały program to seria tych
singletonów zakodowanych w języku C. Więc wybierając język C nie ma
ucieczki przed obiektówką jeśli chodzi o architekturę programu. Dlatego
moim zdaniem naiwnością jest wypieranie się obiektówki rzekomo przez
kodowanie w czystym C. Natomiast łatwość wywołania jakiejś metody ma
znaczenie tam gdzie projekt programu jest zły i trzeba stosować triki.
Przyznam, że to jest problem z bibliotekami w C++ - kiedy nie wszystko
mogę zrobić po swojemu, albo zgodnie z jakimś najnowszym trendem. Tym
nie mniej te problemy raczej nie przekonają mnie by wyprzeć się
stringów, kontenerów i uogólnionych algorytmów oraz reszty oferowanej
przez takie biblioteki jak Qt.

W sumie ja mogę zrozumieć dlaczego ktoś brnie w C i WinApi. Może być
tak, że z projektowaniem programów nie najlepiej sobie radzi i go to nie
interesuje i chce poćwiczyć WinApi (zwłaszcza gdy wymaga tego pracodawca
czy uczelnia). W tym wypadku - ok - jest to świadoma decyzja.

do góry

W dniu 2011-10-03 09:24, fir pisze:
>
> jeszcze raz temat dzwiekow
>
> ostatnio probuje zrobic z dzwiekiem pod windowsem
> cos bardziej zlozonego niz odegranie wave'a
>
> glownie chodzi mi poprawne [1] rownolegle i [2] wzglednie
> bezpooznieniowe emitowanie dzwiekow pod windowsem


Skoro to i tak gierka, a chcesz odpalać cały harmider
bitwy, a nie 'gong' podczas mp3, to spróbuj DirectX.

pzdr
bartekltg

do góry

Szyk <s...@o...pl> napisał(a):

> Drogi FiĹźe, wielki generale Kenobi, czcigodny profesorze Kibonte...
>
>
> > ktos moze udzielic jakiejs porady (glownie uwzgledniajace to co
> > powiedzialem: bez dodatkowych libow i rownolegly dzwiek najlepiej
> > z mala latencja) - zna chocby jakies dobre materialy do
> > dokumentacji itp?
>
>
> Zdaje się, że święcie wierzysz w:
> 1) boskość WinApi (szybkość, funkcjonalność, poprawność koncepcyjną)
> 2) nie omylność M$ (zwłaszcza jego WinApi jako dzieła więczącego rozwój
> systemĂłw operacyjnych)
> 3) wyższość programowania proceduralnego (język C)
>
> Podczas gdy nawet M$ nie wierzy w 1) i 2) ani nawet w 3):
>
> ad 1) wkrótce po premierze Windows 95 okazało się, że do gier jest
> potrzebne coś lepszego niż WinApi - więc szybko dokręcono zestaw
> bibliotek DirectX. Nie wiem czemu unikasz DirectX skoro (OIMW) są to
> biblioteki C obecne we wszystkich windach od 1998 roku. OIMW DirectX
> góruje zarówno szybkością jak i funkcjonalnością nad WinApi. OIMW w
> nowszych windach pod WinApi śmiga DirectX.
>
> ad 2) Brnięcie w zaparte w technologie M$ może być uzasadniane a)
> stabilnością i b) funkcjonalnością oferowaną przez windę które
> przewyższają konkurencję. I faktycznie przewaga M$ Windows jest ogromna
> i raczej nie zagrożona. Tym nie mniej ograniczanie się do jednego
> systemu to brnięcie w kanał. Można zrozumieć też pogląd że nie warto
siÄ
> ™
> zajmować systemami które nie rokują jako alternatywa wobec Windows (na
> ile poważne jest Kubuntu: ostatnie wyszło w kwietniu a do września nie
> działały sterowniki NVidia Geforce 2MX (chyba dla pozostałych Geforców
> też nie działały bo widziałem podobne nagłówki na liście błędów) bo
> jakieś tam ABI nie grało i dopuki odpowiednia ilość użytkowników nie
> potwierdziła tego błędu nikt się tym nie zajmował). Dlatego moim zdaniem
> rozsądną strategią obronną przed dominacją M$ i przed brnięciem w nie
> rokujące systemy są biblioteki wieloplatformowe. Konkretnie mam na
> myśli, że zamiast WinApi czy DirectX raczej bym brnął w SDL lub OpenGL i
> OpenAL (jeśli już się trzymać czystego C i robienia dem czy gier).
>
> ad 3) Pewną zaletą czystego C jest to, że jest większa świadomość jakie
> funkcje się wywołuje, oraz łatwość wywołania dowolnej metody. Jednak pod
> względem architektury programu stosowanie C to praktycznie ciągła pogoń
> za cechami C++. Plik źródłowy *.c opisuje zawartość pliku *.o w którym
> oprócz funkcji często znajdują się również "zmienne globalne" konieczne
> by przechowywać dane robocze programu. Więc czym jest taki plik *.o? No,
> jest on po prostu obiektem typu singleton. I cały program to seria tych
> singletonów zakodowanych w języku C. Więc wybierając język C nie ma
> ucieczki przed obiektówką jeśli chodzi o architekturę programu. Dlatego
> moim zdaniem naiwnością jest wypieranie się obiektówki rzekomo przez
> kodowanie w czystym C. Natomiast łatwość wywołania jakiejś metody ma
> znaczenie tam gdzie projekt programu jest zły i trzeba stosować triki.
> Przyznam, Ĺźe to jest problem z bibliotekami w C++ - kiedy nie wszystko
> mogę zrobić po swojemu, albo zgodnie z jakimś najnowszym trendem. Tym
> nie mniej te problemy raczej nie przekonają mnie by wyprzeć się
> stringĂłw, kontenerĂłw i uogĂłlnionych algorytmĂłw oraz reszty oferowanej
> przez takie biblioteki jak Qt.
>
> W sumie ja mogę zrozumieć dlaczego ktoś brnie w C i WinApi. Może być
> tak, Ĺźe z projektowaniem programĂłw nie najlepiej sobie radzi i go to nie
> interesuje i chce poćwiczyć WinApi (zwłaszcza gdy wymaga tego pracodawca
> czy uczelnia). W tym wypadku - ok - jest to świadoma decyzja.

co do c++/oo wypowiadalem sie juz gruntownie i nie mam checi powtarzac
tego kolejny raz bo boje sie przymulac wlasną osobe (zawsze wole pogadac
o czyms chocby banalnym ale dla mnie nowym) <- sam ten komentarz jest
juz troche przymulasty bo tez go powtarzam ktorys raz

co do winapi to wcale nie jestem takim fanem mS, (winapi nie jest za ladne,
np to przekazywanie struktur ktore nie wiadomo czy sa wewnetrznie kopiowane
i mozna je zwolnic, co idzie w ktora strone itp (jest to swojego rodzaju
koszmarne naduzycie c), pozatym brzydkie nazwy itp,
z kolei np com, directx, albo c# sa chyba jeszcze gorsze )

ale generalnie jak juz programuje to lubie 'niskopoziomowe' fundamentalne
rozwiazania, ktore daja mi prosty interfejs i pozwalaja duzo zrobic samemu,
chyba nie ma tu o czym za duzo gadac,

to co lubie to ladne i cienkie 'layery' nad hardware - np mozna uznac
za takie layery c nad procesorem, ogl nad gpu i winapi nad systemem -
naturalnie kieruje sie wlasnie ku takim layerom of my choice

(kiedys mialem ambicje by lepiej nauczyc sie winapi ale obecnie
po prostu mam zalozony szkielet aplikacji i winapi sie praktycznie
wogole nie zajmuje, podobnie mam zreszta z ogl ktore opanowalem tylko
w podstawie)

poszukuje teraz wlasnie takiego niskiego interfejsu w domenie obslugi
dzwieku pod winda (i troche topornie mi idzie z braku dostatecznego info -
olalem chwilowo ai i od dwu dni szukam i czytam o ew api do odgrywania
rownolegle dzwiekow pod winda, dowiedzialem sie sporo nowego ale poki co nie
dosc by elegancko zrobic sobie taki fundament

nie wiem w jakim kierunku pojdzie rozwoj komputeryzacji na swiecie itp
ale specjalnie sie tym nie przejmuje, mam w domu windowsa to pisze pod
winapi, [ linuxem sie specjalnie nie interesuje raczej po prostu z lenistwa,
zreszta jak kiedys spytalem kolege archetypicznego linuksiarza czy linux
jest szybszy od windy to powiedzial ze niestety nie (gdyby byl szybszy
to moze bardziej by mnie zachecal) ]

tak wogole to watek o dzwieku pod winda i akurat teraz tym tematem jestem
najbardziej zainteresowany,

co do visualstudio/c++/oo/gcc/java itd itp to niespecjalnie interesuje mnie
jakiekolwiek naklanianie kogokolwiek by tego uzywal badz nie uzywal, ja pisze
na takie 'niskie layery' i tyle





--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

kenobi <f...@g...pl> napisał(a):

> Szyk <s...@o...pl> napisał(a):
>
> > Drogi FiĹźe, wielki generale Kenobi, czcigodny profesorze Kibonte...
> >

profesorem moglbym serio zostac, dobrze czulbym sie jako profesor,
co do okreslenia 'wielki generale' to ten kto nie ogladal gwiezdnych
wojen moze nie wie ze kenobi byl za czasow wojen klonow generalem
czyli to pojecie general odnosi sie blizej do tamtejszego pojecia generalstwa,
(a nie do generalow z czasow napoleona czy cos takiego)
podoba mi sie postac kenobiego - zwl evan mcgregor odbrze zagral i wypadl,
jako general widze siebie raczej jako _skromnego_ generala ;-)

> >
> > > ktos moze udzielic jakiejs porady (glownie uwzgledniajace to co
> > > powiedzialem: bez dodatkowych libow i rownolegly dzwiek najlepiej
> > > z mala latencja) - zna chocby jakies dobre materialy do
> > > dokumentacji itp?
> >
> >
> > Zdaje się, że święcie wierzysz w:
> > 1) boskość WinApi (szybkość, funkcjonalność, poprawność koncepcyjną)
> > 2) nie omylność M$ (zwłaszcza jego WinApi jako dzieła więczącego rozwó
> j
> > systemĂłw operacyjnych)
> > 3) wyższość programowania proceduralnego (język C)
> >
> > Podczas gdy nawet M$ nie wierzy w 1) i 2) ani nawet w 3):
> >
> > ad 1) wkrótce po premierze Windows 95 okazało się, że do gier jest
> > potrzebne coś lepszego niż WinApi - więc szybko dokręcono zestaw
> > bibliotek DirectX. Nie wiem czemu unikasz DirectX skoro (OIMW) są to
> > biblioteki C obecne we wszystkich windach od 1998 roku. OIMW DirectX
> > góruje zarówno szybkością jak i funkcjonalnością nad WinApi. OIMW w
> > nowszych windach pod WinApi śmiga DirectX.
> >
> > ad 2) Brnięcie w zaparte w technologie M$ może być uzasadniane a)
> > stabilnością i b) funkcjonalnością oferowaną przez windę które
> > przewyższają konkurencję. I faktycznie przewaga M$ Windows jest ogromna
> > i raczej nie zagrożona. Tym nie mniej ograniczanie się do jednego
> > systemu to brnięcie w kanał. Można zrozumieć też pogląd że nie warto
> siÄ
> > ™
> > zajmować systemami które nie rokują jako alternatywa wobec Windows (na
> > ile poważne jest Kubuntu: ostatnie wyszło w kwietniu a do września nie
> > działały sterowniki NVidia Geforce 2MX (chyba dla pozostałych Geforców
> > też nie działały bo widziałem podobne nagłówki na liście błędów) bo
>
> > jakieś tam ABI nie grało i dopuki odpowiednia ilość użytkowników nie
> > potwierdziła tego błędu nikt się tym nie zajmował). Dlatego moim
zdaniem
>
> > rozsądną strategią obronną przed dominacją M$ i przed brnięciem w nie
> > rokujące systemy są biblioteki wieloplatformowe. Konkretnie mam na
> > myśli, że zamiast WinApi czy DirectX raczej bym brnął w SDL lub OpenGL
i
> > OpenAL (jeśli już się trzymać czystego C i robienia dem czy gier).
> >
> > ad 3) Pewną zaletą czystego C jest to, że jest większa świadomość jaki
> e
> > funkcje się wywołuje, oraz łatwość wywołania dowolnej metody. Jednak po
> d
> > względem architektury programu stosowanie C to praktycznie ciągła pogoń
> > za cechami C++. Plik źródłowy *.c opisuje zawartość pliku *.o w
ktĂłrym
> > oprócz funkcji często znajdują się również "zmienne globalne"
konieczne
>
> > by przechowywać dane robocze programu. Więc czym jest taki plik *.o? No,
> > jest on po prostu obiektem typu singleton. I cały program to seria tych
> > singletonów zakodowanych w języku C. Więc wybierając język C nie ma
> > ucieczki przed obiektówką jeśli chodzi o architekturę programu. Dlatego
> > moim zdaniem naiwnością jest wypieranie się obiektówki rzekomo przez
> > kodowanie w czystym C. Natomiast łatwość wywołania jakiejś metody ma
> > znaczenie tam gdzie projekt programu jest zły i trzeba stosować triki.
> > Przyznam, Ĺźe to jest problem z bibliotekami w C++ - kiedy nie wszystko
> > mogę zrobić po swojemu, albo zgodnie z jakimś najnowszym trendem. Tym
> > nie mniej te problemy raczej nie przekonają mnie by wyprzeć się
> > stringĂłw, kontenerĂłw i uogĂłlnionych algorytmĂłw oraz reszty oferowanej
> > przez takie biblioteki jak Qt.
> >
> > W sumie ja mogę zrozumieć dlaczego ktoś brnie w C i WinApi. Może być
> > tak, Ĺźe z projektowaniem programĂłw nie najlepiej sobie radzi i go to
nie
> > interesuje i chce poćwiczyć WinApi (zwłaszcza gdy wymaga tego
pracodawca
> > czy uczelnia). W tym wypadku - ok - jest to świadoma decyzja.
>
> co do c++/oo wypowiadalem sie juz gruntownie i nie mam checi powtarzac
> tego kolejny raz bo boje sie przymulac wlasną osobe (zawsze wole pogadac
> o czyms chocby banalnym ale dla mnie nowym) <- sam ten komentarz jest
> juz troche przymulasty bo tez go powtarzam ktorys raz
>
> co do winapi to wcale nie jestem takim fanem mS, (winapi nie jest za ladne,
> np to przekazywanie struktur ktore nie wiadomo czy sa wewnetrznie kopiowane
> i mozna je zwolnic, co idzie w ktora strone itp (jest to swojego rodzaju
> koszmarne naduzycie c), pozatym brzydkie nazwy itp,
> z kolei np com, directx, albo c# sa chyba jeszcze gorsze )
>
> ale generalnie jak juz programuje to lubie 'niskopoziomowe' fundamentalne
> rozwiazania, ktore daja mi prosty interfejs i pozwalaja duzo zrobic samemu,
> chyba nie ma tu o czym za duzo gadac,
>
> to co lubie to ladne i cienkie 'layery' nad hardware - np mozna uznac
> za takie layery c nad procesorem, ogl nad gpu i winapi nad systemem -
> naturalnie kieruje sie wlasnie ku takim layerom of my choice
>
> (kiedys mialem ambicje by lepiej nauczyc sie winapi ale obecnie
> po prostu mam zalozony szkielet aplikacji i winapi sie praktycznie
> wogole nie zajmuje, podobnie mam zreszta z ogl ktore opanowalem tylko
> w podstawie)
>
> poszukuje teraz wlasnie takiego niskiego interfejsu w domenie obslugi
> dzwieku pod winda (i troche topornie mi idzie z braku dostatecznego info -
> olalem chwilowo ai i od dwu dni szukam i czytam o ew api do odgrywania
> rownolegle dzwiekow pod winda, dowiedzialem sie sporo nowego ale poki co
nie
> dosc by elegancko zrobic sobie taki fundament
>
> nie wiem w jakim kierunku pojdzie rozwoj komputeryzacji na swiecie itp
> ale specjalnie sie tym nie przejmuje, mam w domu windowsa to pisze pod
> winapi, [ linuxem sie specjalnie nie interesuje raczej po prostu z lenistwa,
> zreszta jak kiedys spytalem kolege archetypicznego linuksiarza czy linux
> jest szybszy od windy to powiedzial ze niestety nie (gdyby byl szybszy
> to moze bardziej by mnie zachecal) ]
>
> tak wogole to watek o dzwieku pod winda i akurat teraz tym tematem jestem
> najbardziej zainteresowany,
>
> co do visualstudio/c++/oo/gcc/java itd itp to niespecjalnie interesuje mnie
> jakiekolwiek naklanianie kogokolwiek by tego uzywal badz nie uzywal, ja
pisze
> na takie 'niskie layery' i tyle
>

mam wrazenie ze znowu sie lekko przepracowalem, od trzech dni nierobie
prawie nic innego tylko przegladam info o tych api dzwiekowych i bibliotekach
(fmod, openal, bass, audiere... razem z wymienionymi api i jeszcze czymstam
jest tego z dziesiec)
przydalaby mi sie jakas duza wanna z duza iloscia piany i dobre zarcie
bo padne trupem (jak rasowy nerd w stosie zaplesnialej pizzy) choc moze
nie jest tak do konca bo takie intensywne fazy szukania info miewam raz na
jakis czas (wzglednie nieczesto nawet)






--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry