4 ms·

What do you mean by "bus" and "module" in this context?

GrantMoyer 2y ago
A module is a piece of software or hardware which is independent in some way. A bus is a shared medium of communication[1]. Often, busses are time-division multiplexed[2], so if you want to use the bus, but another module is already using it, you need to wait. For example, if your audio buffers are ultimately submitted to a sound card over a PCI bus, the submission may need to wait for any ongoing transactions on the PCI bus, such as messages to a graphics card. [1]: https://en.wikipedia.org/wiki/Bus_(computing) https://en.wikipedia.org/wiki/Bus_(computing) [2]: https://en.wikipedia.org/wiki/Time-division_multiplexing https://en.wikipedia.org/wiki/Time-division_multiplexing
- spacechild1 2y ago
  That is one possible interpretation, but not what they meant. That's why I asked because I wasn't sure :)
swatcoder 2y ago
"Bus" (as I was using it) is the path from some audio source to some audio destination and a "module" (as used) would be something that takes a buffer of samples on that bus and does something with it. You might sometimes build an app where (through your operating system) you connect directly with an input device and/or output device and then do all the audio processing yourself. In this case, you'd more or less control the whole bus and all the code processing samples on it and have a fairly true sense of your deadline. (The OS and drivers would still be introducing some overhead for mixing or resampling, etc, but that's generally of small concern and hard to avoid) Often, though, you're either going to be building a bus and applying your own effects and some others (from your OS, from team members, from third party plugins/libraries, etc) or you're going to be writing some kind of effect/generator that gets inserted into somebody else's bus in something like a DAW or game. In all these cases, you need to assume that all processing code that isn't yours needs all the time that you can leave for it and just make your own code as efficient as is reasonable.
- spacechild1 2y ago
  Thanks for clarifying. The terms are highly ambigious (see the sibling answer https://news.ycombinator.com/item?id=40930298 https://news.ycombinator.com/item?id=40930298), that's why I asked. Personally, I would rather use the terms "audio pipeline" or "audio graph" instead of the generic "bus". > In all these cases, you need to assume that all processing code that isn't yours needs all the time that you can leave for it and just make your own code as efficient as is reasonable. Yes. For audio programmers that is obvious, in particular when it comes to plugins, but for novices it might be worth pointing out!
- RossBencina 2y ago
  > You might sometimes build an app where (through your operating system) you connect directly with an input device and/or output device and then do all the audio processing yourself. In case it is not clear, that is the primary case that is addressed by the linked blog post (source: I wrote the blog post).
  - swatcoder 2y ago
    And likewise: in case it wasn't clear, it's a great article! I wasn't meaning to criticize it, just add a little further perspective for the common scenario that many first-time audio programming folks encounter.

A module is a piece of software or hardware which is independent in some way. A bus is a shared medium of communication[1]. Often, busses are time-division multiplexed[2], so if you want to use the bus, but another module is already using it, you need to wait. For example, if your audio buffers are ultimately submitted to a sound card over a PCI bus, the submission may need to wait for any ongoing transactions on the PCI bus, such as messages to a graphics card. [1]: https://en.wikipedia.org/wiki/Bus_(computing) https://en.wikipedia.org/wiki/Bus_(computing) [2]: https://en.wikipedia.org/wiki/Time-division_multiplexing https://en.wikipedia.org/wiki/Time-division_multiplexing

spacechild1 2y ago
That is one possible interpretation, but not what they meant. That's why I asked because I wasn't sure :)

swatcoder 2y ago

"Bus" (as I was using it) is the path from some audio source to some audio destination and a "module" (as used) would be something that takes a buffer of samples on that bus and does something with it. You might sometimes build an app where (through your operating system) you connect directly with an input device and/or output device and then do all the audio processing yourself. In this case, you'd more or less control the whole bus and all the code processing samples on it and have a fairly true sense of your deadline. (The OS and drivers would still be introducing some overhead for mixing or resampling, etc, but that's generally of small concern and hard to avoid) Often, though, you're either going to be building a bus and applying your own effects and some others (from your OS, from team members, from third party plugins/libraries, etc) or you're going to be writing some kind of effect/generator that gets inserted into somebody else's bus in something like a DAW or game. In all these cases, you need to assume that all processing code that isn't yours needs all the time that you can leave for it and just make your own code as efficient as is reasonable.

spacechild1 2y ago
Thanks for clarifying. The terms are highly ambigious (see the sibling answer https://news.ycombinator.com/item?id=40930298 https://news.ycombinator.com/item?id=40930298), that's why I asked. Personally, I would rather use the terms "audio pipeline" or "audio graph" instead of the generic "bus". > In all these cases, you need to assume that all processing code that isn't yours needs all the time that you can leave for it and just make your own code as efficient as is reasonable. Yes. For audio programmers that is obvious, in particular when it comes to plugins, but for novices it might be worth pointing out!
RossBencina 2y ago
> You might sometimes build an app where (through your operating system) you connect directly with an input device and/or output device and then do all the audio processing yourself. In case it is not clear, that is the primary case that is addressed by the linked blog post (source: I wrote the blog post).
- swatcoder 2y ago
  And likewise: in case it wasn't clear, it's a great article! I wasn't meaning to criticize it, just add a little further perspective for the common scenario that many first-time audio programming folks encounter.