eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingWinMM / DirectSound / Kernel Streaming / ASIO / GSIF ?
Ilość wypowiedzi w tym wątku: 5

  • 1. Data: 2011-10-03 07:24:53
    Temat: WinMM / DirectSound / Kernel Streaming / ASIO / GSIF ?
    Od: " fir" <f...@g...SKASUJ-TO.pl>


    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/


  • 2. Data: 2011-10-03 13:00:55
    Temat: Re: WinMM / DirectSound / Kernel Streaming / ASIO / GSIF ?
    Od: Szyk <s...@o...pl>

    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.


  • 3. Data: 2011-10-03 13:46:52
    Temat: Re: WinMM / DirectSound / Kernel Streaming / ASIO / GSIF ?
    Od: bartekltg <b...@o...pl>

    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


  • 4. Data: 2011-10-03 13:55:28
    Temat: Re: WinMM / DirectSound / Kernel Streaming / ASIO / GSIF ?
    Od: " kenobi" <f...@g...pl>

    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/


  • 5. Data: 2011-10-03 16:12:58
    Temat: Re: WinMM / DirectSound / Kernel Streaming / ASIO / GSIF ?
    Od: " " <f...@g...pl>

    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/

strony : [ 1 ]


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: