https://linen.dev logo
Join Discord
Powered by
# lime
  • a
    maybe with haxe bindings as well it would be special
  • b
    (remembers me into trisitter 😂 )
  • a
    web audio api is very similar to OpenAL in places
  • b
    (i mean also was from rust-spice there .)
  • a
    \:D yeah all cool stuff is rust
  • b
    its the rust 
    sync
    into parallele computing what makes all this possible i am think .)
  • b
    anyway .. i am sometimes need to implement pure web-js AudioBuffer into
  • b
    sample there to test out all scopes
  • b
    also the 
    mixing
    at runtime should be on GPU (^_^)
  • b
    by `adding`+`normalizing` the produced texture-datas into another pass
  • b
    before putting into the Audio->Queue (that should also be into really small 
    continues
    buffers to have no 
    lag
    ... not found best WaYet to doing this ~_~)
  • a
    with web audio there will be lag I think
  • a
    to get unbroken audio you need larger buffers
  • a
    it's kinda shitty
  • b
    oh nooo 😢
  • a
    gpu audio stuff is best on native
  • a
    and even open al is laggy
  • a
    need something more low level like portaudio
  • a
    (or maybe this cpal thing)
  • b
    my buffersize into testcase is like this now (~1-2seconds)
  • a
    grig is using portaudio but I think there are some problem because of the haxe garbage collector
  • b
    the rusty 
    cpal
    thing and all can also not be more do as what browsers allow -_-
  • a
    yeah it will still rely on web audio
  • b
    then maybe better for me is to use web audio instead (to write haxe js externs is more easy for me)
  • a
    but I think it's doing wasm audio worklet (the new cool stuff)
  • a
    either way, I think there will always be latency via the browser
  • b
    oh ... but also supported by all most used web-browsers ?
  • a
  • a
    I think so nowadays
  • b
    ooh.. thats looks good then ^^
1...119120121...138Latest