3 ms·

Internally, both foobar2000 and Chrome/Electron use ffmpeg for audio processing and codec support. The web audio api allows for writing all sorts of equalizers

Internally, both foobar2000 and Chrome/Electron use ffmpeg for audio processing and codec support. The web audio api allows for writing all sorts of equalizers and audio processing effects. Extensions and query and library management can be coded in JS easily, like VSCode, Hyper and others do. Electron frontend communicating with foobar2000 sdk for every little interaction will lead to a huge mess of performance and latency issues. It's better to rebuild the whole thing in electron instead.

v-yadli 8y ago
> both foobar2000 and Chrome/Electron use ffmpeg for audio processing and codec support not quite true. for example, the ZXTune plugin brings support for a dozen of chiptune formats which is obviously out of scope of ffmpeg. It'll be possible to incorporate webaudio api for codec but that's a resource hog. Also if you're doing decoding work and the GC jitters, you're going to run out of audio buffer (stuttering). If we take one step back and rely on some audio playback API, then gapless play and other issues would be difficult to deal with. > The web audio api allows for writing all sorts of equalizers and audio processing effects. maybe, but that's reinventing the wheel. foobar2000 supports VST plugins, the professional tools used in the audio production industry. there are a few dsp components for webaudio but that's far from satisfactory. > Extensions and query and library management can be coded in JS easily, like VSCode, Hyper and others do. Yes I agree. That way we can make a neat package manager for an audio system. Some Digital Audio Workstations(DAW) have already begun to move this way (Bitwig Studio etc.) > for every little interaction will lead to a huge mess of performance and latency issues. Not quite sure.. Think about how NeoVim is built. But my concern is that, foobar2000 is not built for tightly interacting with a frontend, so yeah, better rebuild a native audio core, and use a modern communication protocol (msgpack maybe?) to do the roundtripping. But again, that protocol could be implemented as a foobar2000 plugin... The downside of using foobar2000 is also obvious. It's close sourced and Win32 dependent. So I'd think about this: ``` Electron frontend <-- msgpack --> Native audio core <--> JackAudio, RtAudio or alike, whatever that bypasses the middleware and directly access the hardware audio buffer ```

v-yadli 8y ago

> both foobar2000 and Chrome/Electron use ffmpeg for audio processing and codec support not quite true. for example, the ZXTune plugin brings support for a dozen of chiptune formats which is obviously out of scope of ffmpeg. It'll be possible to incorporate webaudio api for codec but that's a resource hog. Also if you're doing decoding work and the GC jitters, you're going to run out of audio buffer (stuttering). If we take one step back and rely on some audio playback API, then gapless play and other issues would be difficult to deal with. > The web audio api allows for writing all sorts of equalizers and audio processing effects. maybe, but that's reinventing the wheel. foobar2000 supports VST plugins, the professional tools used in the audio production industry. there are a few dsp components for webaudio but that's far from satisfactory. > Extensions and query and library management can be coded in JS easily, like VSCode, Hyper and others do. Yes I agree. That way we can make a neat package manager for an audio system. Some Digital Audio Workstations(DAW) have already begun to move this way (Bitwig Studio etc.) > for every little interaction will lead to a huge mess of performance and latency issues. Not quite sure.. Think about how NeoVim is built. But my concern is that, foobar2000 is not built for tightly interacting with a frontend, so yeah, better rebuild a native audio core, and use a modern communication protocol (msgpack maybe?) to do the roundtripping. But again, that protocol could be implemented as a foobar2000 plugin... The downside of using foobar2000 is also obvious. It's close sourced and Win32 dependent. So I'd think about this: ``` Electron frontend <-- msgpack --> Native audio core <--> JackAudio, RtAudio or alike, whatever that bypasses the middleware and directly access the hardware audio buffer ```