Getting sound close to bare metal


#21

I think it’s I/O Kit you want if you’re in Apple land, here’s an overview of the stack…
https://developer.apple.com/library/archive/documentation/MusicAudio/Conceptual/CoreAudioOverview/WhatisCoreAudio/WhatisCoreAudio.html


#22

Great! I’ll look into the windows some more. I think driver dev is a good place for me. I’ll have to start with JUCE being a beginner but down the line driver development seems most appropriate.


#23

In most multi tasking environments, the abstraction layer between driver and application serves an important role: it allows multiple applications to use the device at the same time (this was a problem on linux for a long time).
If you talk directly to the driver, you will be responsible, that everything else still works (by appearing as driver to them), or you create an exclusive mode, which is not what most users want.

The abstraction layers I remember:

  • OSX: CoreAudio, Soundflower (is CoreAudio, but appears as backend and driver)
  • Windows: Wasapi, DirectX, ASIO, …
  • Linux: OSS, alsa, gstreamer, jack-it…

I am not sure, if pushing further down on software abstraction layers bring you the benefit that you are hoping for, but that’s just my opinion.


#24

It does look interesting TBH, good luck - Less competition for the rest of us! :sunny: days


#25

So basically JUCE exists for a reason. I’m most worried about dependcy issues with using JUCE over some other abstraction. I figure if I can do my processing closer to the lower level I’ll have something built from the ground up.


#26

Nothing in JUCE stops you from doing your lowest level DSP code even as plain C functions, if you so wish. That would be compatible with pretty much any platform or other framework out there. (Even assembler should be possible but I don’t have any experience with that.)