[C# / C] DirectSound en winmm.dll

[Verwijderd]

Voor een project waar ik mee bezig ben, moet er een ontwerpbeslissing gemaakt worden, namelijk het gebruik van DirectSound om een microfoon uit te lezen of de dll winmm.dll gebruiken hiervoor.

Is er iemand die enige ervaring heeft met deze twee componenten en met name of er een (duidelijk) snelheidsverschil is bij het gebruik van de een tov de andere.

Volgens mij:
Intern zal DirectSound waarschijnlijk ook gebruik maken van deze winmm.dll en zou er nauwelijk verschil moeten zijn in snelheid, maar ik heb hierover op Google eigenlijk geen informatie gevonden over een eventueel verschil in snelheden. 'Het gewoon uitproberen' is eigenlijk niet echt een optie omdat mijn programmeerkennis niet dusdanig is dat ik dat 'even in elkaar zet'.

edit:

De applicatie die ik wil maken (in een C# applicatie) moet gebruikt worden voor (onder andere) audiochat, er zal dus continu gebruik gemaakt worden van de geluidskaart.
Wanneer er gebruik gemaakt gaat worden van de winmm.dll zal een deel (waarschijnlijk) geprogrammeerd worden in C (een DLL).
DirectX zou direct via C# aangesproken worden.

Kan iemand verheldering brengen?

[ Voor 11% gewijzigd door Verwijderd op 09-06-2005 16:04 ]

[NMe]

Was het niet zo dat die winmm.dll gebruik maakt van de Windows API-functies, waardoor er niet meer dan een stream tegelijk afgespeeld kan worden naar de geluidskaart? Ik heb weinig met de Windows API gedaan, dus ik ben er niet zeker van, maar volgens mij zat die limitatie erin.

Ik zou in elk geval waarschijnlijk DirectSound gebruiken, maar dat is meer een gevoelsmatige keuze dan een goed onderbouwd statement.

[H!GHGuY]

ik heb net 2 topics terug geantwoord dat ik liever Windows Audio gebruikte...

ik heb een hele tijd terug een kleine VoIP app gemaakt, en had toen wat rondgeneusd over de verschillen.

het grote verschil zit hem in de buffercontrole.
bij windows audio reserveer je een 10tal buffers die je in een queue zet. afhankelijk van afspelen/opnemen zijn deze leeg/vol natuurlijk. wanneer een buffer klaar is (afgespeeld/opgenomen)
krijg je'm terug om hem opnieuw te vullen/leegmaken. daarne stop je hem terug in de queue

in DirectSound werk je met circulaire (begin = einde) secondary buffers waarin je een stuk lockt, en de data manipuleert. (locken is in dit geval wel een kopie!)

het grote verschil zit em nou in hoe et afgespeeld wordt. In mijn geval was het zo dat als ik geen data kreeg van de andere kant:
Windows Audio had geen buffers meer om af te spelen tot ik weer data kreeg en stopte met spelen
DirectSound speelde telkens opnieuw dezelfde buffer (dus deze moet je dan zelf pauzeren/resumen)

ik had bovendien wat moeilijkheden met de synchronisatie in DS en met het bewerken van die buffers etc. Uiteindelijk vond'k windows audio beter in het geval van mijn toepassing en heb ik DS er volledig uitgesloopt

[Verwijderd]

@ NMe:

Volgens http://www.codeproject.com/audio/wavefiles.asp zou Windows XP/2000 meerdere streams moeten kunnen afhandelen met een techniek dat kernel mixing wordt genoemd. Echter denk ik dat het voor mijn toepassing (audio chat) niet zoveel uit zal maken, omdat ik alle data die binnenkomt (RTP pakketten met de audio data) in dezelfde buffer(s) plaats.
Of denk ik er nu iets te simpel over?

@HIGHGuY:
Het lijkt erop dat beide oplossingen voor mijn toepassing even goed zouden werken, en maakt het voor wat betreft snelheid allemaal niets uit, maar de DirectX oplossing vergt meer geheugen. Zou dit problematisch veel meer zijn?

Waarom moet bij het locken van een buffer deze gekopieerd worden? Theoretisch wordt er toch met behulp van (bijvoorbeeld) een boolean het geheugen gebied als 'in gebruik' gemarkeerd, zodat een proces/thread/wat-dan-ook weet dat het stuk geheugen/resource al gebruikt wordt en dat er even op gewacht moet worden?

[H!GHGuY]

Verwijderd schreef op vrijdag 10 juni 2005 @ 16:36:
@HIGHGuY:
Het lijkt erop dat beide oplossingen voor mijn toepassing even goed zouden werken, en maakt het voor wat betreft snelheid allemaal niets uit, maar de DirectX oplossing vergt meer geheugen. Zou dit problematisch veel meer zijn?

Waarom moet bij het locken van een buffer deze gekopieerd worden? Theoretisch wordt er toch met behulp van (bijvoorbeeld) een boolean het geheugen gebied als 'in gebruik' gemarkeerd, zodat een proces/thread/wat-dan-ook weet dat het stuk geheugen/resource al gebruikt wordt en dat er even op gewacht moet worden?

dat geheugengebruik moet je je denk ik niets van aantrekken hoor... daarbij kies je als ik het me nog wat herinner, zelf hoe groot je buffer is.

dat kopieren van die buffer wordt door DX zelf gedaan:

code:

Circulaire buffer |-----|-------------|-------------------------------------------|
                      /           /
                    /   kopie   /
schrijfbuffer      |------------|
jouw buffer        |------------|

aangezien de thread van DX verder speelt als jij die schrijfbuffer krijgt kan het niet dat jij schrijft in de schrijfbuffer terwijl DX ervan leest natuurlijk... daarom een kopie waar jij je data inplaatst, en waar DX dan wanneer het em past de juiste dingen meedoet.

maar wat je met de buffers wel/niet mag aanvangen staat duidelijk aangegeven in de SDK hoor.
je mag bvb van een afspeelbuffer niet verwachten dat hij de afgespeelde data bevat etc...