turns out audio is really a mess when it comes to xplat things
turns out audio is really a mess when it comes to xplat things
PSomeone should port miniaudio to C#
Lim planning on building it off mach sysaudio, so i dont have to fight the lowest level of xplat
PA fully managed version of that would be sick
Lthat would require a lot more audio bindings than we currently provide lmao
Kyeah
Kthat would require binding to every one of the individual audio backends
Lwe already have the windows ones and JACK
Pez just use SilkTouchX
Li wish JACK was integrated better into OSes that werent linux its so fucking good
Kikr
Maudio drivers need to be signed, which is a pain
Ki remember when i first found JACK and was like oh holy shit this rules
Lfrankly if you didnt need a whole external audio server on Mac/Windows id say JACK is the best cross platform low level audio library
Lbut we arent talking about drivers
Lwe are talking about an audio engine, which abstracts over existing ones
Mwhat's wrong with jack for htat
Lyou need to bundle the whole JACK server on Mac/Windows
Moh i see
Myou dont actually, afaik
Mi mean you could use ASIO
Lbut then you arent using JACK
Land you still have to write multiple backends anyway at that point
Myou can use asio as a bridge to jack
Mok fair
Mthis seems moree like a jack issue than a windows issue
Msounds fixable
Lits not a windows issue, it is a jack issue
LJACK is not really meant as just a "simple audio output" its a professional grade audio system with way more features
MOBS can integrate with jack though, and it doesn't bundle a server
Lyou are meant to have a jack server already
Lit probably expects you to provide your own
Mwhats wrong with that
Lthen.. you have to provide your own
Lso its unsuitable for what we are talking about
Mi thought that was what you wanted
Mo
Kif the goal is to have a cross platform audio playback library for c#/dotnet then requiring end users to have a jack server is suboptimal
L^
Mdo you mean like, having jack as a dependency that autoinstalls?
L?
Kthats a difficult dependency to propogate automatically and again just not really ideal
L^
Lusing JACK on all OSes just isnt feasable for something like what we are talking about
Lwe'd have to have per platform backends
Kmaking a dotnet library as a nuget package that requires end users of the dependant application to install something separate is bad if it isnt necessary for the idea
C@Perksey I've been playing with a pointer type idea: https://codeshare.io/j09BO3
This would allow for
While we would lose out on implicit overloads for mutidimensional, those could be added in as functions using extensions with where clauses, or specific types, to allow for more depth specific functions.
This would allow for
PointerToConst<Pointer<byte>> byteArray; // byte*const*While we would lose out on implicit overloads for mutidimensional, those could be added in as functions using extensions with where clauses, or specific types, to allow for more depth specific functions.
Mi was just wondering why you mentioned JACK earlier
Llinux
Mwe talked about this one time before :D
never figured out whether or not to use it though
never figured out whether or not to use it though
Mor why not