A basic audio library to be used in conjunction with OpenTK. Contains basic sound loading, playing, and streaming, and related functionality mostly aimed at games.
It might be very much worth it writing a custom AL class which copies all the methods from the OpenTK AL wrapper, but also includes the error check, cleaning up all OpenAL calls in the entire library.
We should rewrite the decoding logic to create some form of pipeline that takes a stream as input and outputs the sound buffers. Most importantly, the decoder be ignorant of how much is being read, so that they can be reused for both stream-reading and file-reading.
Hello:
I have some audio files (in AAC format), which are extracted by FFMPEG from one video (MP4 format) file. Letβs say, I have 2 of such audio files: (C:\Audios\1.aac and C:\Audios\2.aac), I want to merge or concat them into one audio file: C:\Audios\merge.aac.
Can I use the repo to do this?
If yes, please share some C# code. I am using Visual Studio 2022 for targeting .NET 6.0 on Windows 10.
I can use FFMPEG to do this, unfortunately, FFMPEG is rather bad in processing audio files. For example, if the original video file has the duration of 1 minute, the audio file extracted from the video has never has the duration of 1 minute, it could be something like: 1.5 minute or others. Any way, it is not suitable for production.
Let me know if I can use the repo to do the job.
Thanks,
Due to strange limitations in number of active/playing sources (see #28), the recommended pattern of using sources is by using a pool of sources that can be reused. This pool would contain a fixed number of sources (could be eagerly or lazily initialised), and can be queried for an unused source.
Needs some design considerations before being implemented.
Ideally the dependencies would be setup as NuGet packages, since this would remove the need to manually update the binaries. OpenTK is on the NuGet package manager. The status of NVorbis is unknown.
Using the direction and cone inner and outer angle, directional sources could be added. Since this is often not necessary, this functionality should be provided in a subclass of Source.
Sources are objects that emit sound. Especially in 3D games, these emitters often correspond to existing game objects. It is therefore likely that elements like position en velocity could be taken from that game object directly. Finding an interface from which these objects can inherit, while still providing the functionality, would be desirable. Due to the required logic, an abstract class is a more likely solution.
Currently the limitations on the number of sources aren't being well understood. We should see what the exact behaviour is under different circumstances, document those, and potentially feed the information into our design decisions.
Since we want to support both whole file loading and file streaming, we should have streams that provide an interface that can be hooked into decoders transparently.
It probably makes more sense to extract the interface of the audio services and mock those in the unit tests than providing a fake audio context. This has several advantages:
No need to set fake audio contexts, which is cleaner.
Testing closer to the actual OpenAL code will provide better test coverage.
It acts as an extra check that no OpenAL interfacing code creeps out of the services, since any of that code would crash without AudioContext, which the tests will never initialise.