C#: Lydserver, C#/.NET. Ideelt?

[TheMaister]

Har et Unix-basert prosjekt skrevet i C, som er et simpelt rammeverk for å sende lyd over nettverk (noe ala esound). Får kjørt server-koden osv i Windows via Cygwin, men hele opplegget føles svært hacky og buggy i Windows, og ekstremt lite estetisk, så vurderer å gjøre endringer for å tilpasse ting litt til Windows, delvis for å lære litt om hvordan ting er i "den andre leiren". Vil C#/.NET være enkelt og greit å gjøre dette i, isteden for å hacke på C-koden jeg allerede har (bruker pthreads, portaudio og sockets). Skal ideelt sett ikke ha et omfattende GUI til dette, siden det skal være en bakgrunnsservice (daemon).

 

Jeg kan ikke spesielt mye C#, .NET eller Windows-programmering i det hele tatt, men kan litt C++ i hvertfall, hvis det hjelper. Lurer på spesielt på lyd, har .NET en god måte å spille av lyd på, som ikke blir for kryptisk (noe ala libao/portaudio)? Har svært lave krav til lydsystemet, trenger stort sett bare å åpne lydkortet, sette params som samplerate osv, og kjøre på med lyd (helst blocking I/O), helt til jeg stopper streamen. Det må også kunne kjøre på "alle" Windows-maskiner uten å måtte installere noe annet (kan anta at .NET er installert). exe-fila må også være liten og helt self-contained. Noen ideer?

[GeirGrusom]

.NET er helt realistisk til noe slikt.

Sockets og threads er innebygget i .NET framework (kanskje litt selvsagt) men støtte for lyd (annet enn for å spille enkle .wav filer) er ikke innebygget.

Dersom du bruker WaveOut, så vil ikke programmet kreve noen ekstra biblioteker og kjøre på alle Windows systemer som støtter .NET.

Selv foretrekker jeg OpenAL til lyd, men det krever ekstra installasjon. Utover det, har du også SlimDX som er et wrapper bibliotek for DirectX, som har eksponerer to forskjellige DirectX API-er for lyd: XAct og DirectSound. Da vil ingen ekstra installasjon kreves, ettersom siste DirectSound revisjon er fra DirectX 8 (etter det jeg vet) med XAct er fra DirectX 9, som på noen systemer kan kreve oppdatering av DirectX.

 

Du har mange muligheter, DirectSound, XAct og OpenAL har fordeler fremfor Waveout, men waveout vil ikke kreve noen ekstra biblioteker eller installasjon hvis du bruker P/Invoke. Det finnes sikkert biblioteker for waveout også som gjør at du kan spare litt tid, ettersom Waveout er et C API, som ofte er litt tungvint å jobbe med i C# hvis ikke du skriver et wrapper bibliotek.

 

Windows Waveform API

[TheMaister]

Synes waveform API virket nokså kryptisk (tør ikke tenke på DirectSound). Ser at dette med "header" går igjen. Hvilken header er det snakk om? Jeg skal da bare sende rå lyd til lydkortet. Hvordan ville denne pseudokoden sett ut sånn cirka med waveOut?

 

open_soundcard()
set_samplerate(rate)
set_channels(rate)
set_sample_format(S16_LE)

while data_is_available
{
  buffer = read_from_source(bytes)
  sound_write(buffer, bytes)
}
close_soundcard()

 

EDIT: Tror jeg dropper waveOut. Virker jo som latterlig mye arbeid for noe så banalt.

http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=4422&lngWId=3

Endret 23. mars 2010 av TheMaister

[GeirGrusom]

Slappfisk.

Kikk på OpenAL, det er enkelt i bruk. Jeg skrev et waveout bibliotek, men jeg tror det er en bug i det (jeg får bare spraaaaak ut)

edit: NAudio er også verdt å kikke på, men det virker litt Ad Hoc designet. Det har støtte for de fleste lyd API-er.

Endret 24. mars 2010 av GeirGrusom

[TheMaister]

OpenAL, enkelt og enkelt, finnes mye som er enklere

Vel, tok den enkle veien, og omskrev en del C-kode i steden. Gikk mye fortere å porte enn jeg hadde trodd, så.

[GeirGrusom]

OpenAL er vel så enkelt som Linux eksempelet ditt over, som jeg vel viste i en annen tråd.

OpenAL har i tillegg fordelen av å være hardware aksellerert på alle systemer (dersom det er et pluss, som vel kommer an på hva slags program det skal brukes til)

Endret 25. mars 2010 av GeirGrusom

[TheMaister]

Mja, rent subjektivt synes jeg ikke at koden virket spesielt intuitiv, men er sikkert pga at jeg er veldig vandt med open(), write(), close()-idiomet fra Unix, og konseptet med å lage seg en header eller buffer før man sender det til lydkortet blir litt kronglete for min del. Gir mening hvis man skal bake inn posisjon osv inn i lydkilden, though. (OpenAL-koden du viste kjørte ikke på mitt system, btw :\).

[GeirGrusom]

Vel, objektivt sett:

Unix sitt system (uten at jeg har satt meg dypt inn i det) er et state machine system, mens OpenAL bruker en mer objektorientert tilnærming. Fordelen er at du kan jobbe med mange kilder uavhengig av hverandre på en enkel og logisk måte.

Ved siden av det, har også OpenAL hardware aksellerasjon, støtte for 3D og innebygget støtte for Vorbis (med en extension i 1.1)

[TheMaister]

Fikk kjørt koden nå though, bare for å ha testet. Ja, kan være enig i at om man trenger å operere med flere, separate buffere, så hjelper det med den tilnærmingen.

 

Hvordan er det med latency og OpenAL egentlig? Har grusom latency (minimum 200ms) i Windows med mmsystem (via portaudio), i tillegg får jeg merkbar forringet lydkvalitet når lydkilden ikke er i 48000Hz (dårlig resampling?).

Endret 25. mars 2010 av TheMaister

[GeirGrusom]

OpenAL vil jeg tro er relativt dårlig på latency, ettersom det ikke er akkurat hovedpoenget med OpenAL (hovedpoenget er spill) men 200 ms virker litt ekstremt... jeg har ikke testet latency, men jeg kan ikke si at jeg har lagt merke til noe.

Dersom latency er en kampsak, er muligens ASIO noe du burde kikke nærmere på.

 

edit: NAudio for .NET (og Windows) har støtte for ASIO.

Endret 25. mars 2010 av GeirGrusom

[TheMaister]

Vel, latency er jo svært viktig i spill Vil jo ikke at det skal ta et par sekunder fra skuddet går til man hører det liksom. Får 200ms med winmm (som portaudio rapporterer), og prøver jeg å sette den lavere blir det bare skurring :\ ASIO blir kanskje litt overkill though, krever ikke det ekstra driverstøtte hvis man vil ha grei latency?

 

Serveren trenger egentlig ikke så lav latency, men alle "vanlige" APIer jeg har brukt har hatt neglisjerbar latency (ALSA, OSS, osv) med vanlige defaults. Det blir bare litt keitete når en stream tar 200ms å skru av og på

[GeirGrusom]

200 ms kan man ikke leve med. Ofte har latency sammenheng med størrelse på buffer. Du må ha en bufferstørrelse som gir lav latency samtidig som du slipper hakking. Hvor stort har du satt bufferet?

[TheMaister]

Er ikke sikker på bufferet, eller om jeg får satt det i det hele tatt siden jeg bruker PortAudio for å interface med winmm, men jeg bruker "getDefaultLowLatency", som tydeligvis gir 200ms samlet latency. (Det tar ~200ms fra første write() til jeg hører lyd, og ~200ms fra en close() til lyden stopper. Føles sluggish.) "HighLatency" gir omlag ett sekund (?), og er helt ubrukelig. Det morsomme er at jeg får lavere latency i wine enn native, så lurer på hvor feilen kan være. Har testa koden på flere maskiner, og er samme oppførsel. ;v Kan se om jeg får noe openal-kode til virke, og sammenlikne.