NAudio
NAudio copied to clipboard
naudio
Is NAudio active anymore?
Hi,
There have been numerous pull requests regarding similar issues:
- https://github.com/naudio/NAudio/pull/1113
- https://github.com/naudio/NAudio/pull/1192
Yet, project maintainer does not take any initiative to take a look into these.
Is NAudio still alive?
Unfortunately, it doesn't seem to be actively maintained or developed anymore. What's even more unfortunate is that there doesn't appear to be a decent alternative within the .NET ecosystem, which is quite sad.
For the time being, and I hope for the future, I've created a stripped-down fork called Sonic Boom that's maintained. You can find the GitHub repository here. It also includes ogg playback and looping. (NuGet package is pending verification, it'll be on NuGet.org soon.)
hi all, apologies for not responding to this sooner. I did write a while back about the future of NAudio here - https://markheath.net/post/naudio-20-year-anniversary which I'd encourage people to read for context on where I am with NAudio.
This year I have had some health problems with back pain and so needed to step away from some of my commitments and so I haven't been as responsive to PRs and GitHub issues as I would have liked.
There was a fork someone else made of NAudio a while back called CSCore - don't know if that is still being actively maintained. And am open to discussing bringing someone onto the NAudio team as a maintainer if that would be preferable to a fork (feel free to contact me offline @nightblade9 if you like).
Interesting, I didn't know CSCore was a fork of NAudio! I'm pretty sure it's also no longer maintained.
I'm probably not the right person to be a maintainer, as I barely understand what the PRs are doing and how the code works. In fact, that's why I stripped out a lot of functionality from my fork: less to maintain, to focus on what I need.
@markheath I can definitely help, for now, with merging PRs, updating to .NET 8, and cleaning up tests, as I did in my own fork. If you're interested or want to discuss further, let me know.
@markheath and @nightblade9
Perhaps I can help on adding Span<T> and ArrayPool support.
I am doing heavy use of encoding, mixing provides. Writing and reading to and from IWaveProvider in NAudio.
I do not fully understand different formats og audio 🙂 But performance optimization, use of Span and ArrayPool etc.
For now in the projects that I work on, there is a lot af copying of small audio streaming data, and adding Span support can help.
CSCore borrowed a lot from NAudio but also rewrote a lot - seemed a shame as I would have liked to have collaborated rather than having two projects. But haven't heard from that project in a while.
I understand wanting to strip it down - there is a lot of stuff in there, and testing it is a time-consuming process. Its one of the main reasons I can't easily accept PRs - I need to be sure that the code works before bringing it into NAudio, and on GitHub the contributions can be of mixed quality.
@rdyhalt have you taken a look at the Span branch of NAudio - I did go through the whole thing and make a span version, which I nearly released, but some VB.NET programmers said that it wasn't supported for them. Hopefully that's no longer an issue. I think Span tidies a lot of stuff up, and you could always make an adapter so that people who implemented IWaveProvider the old way can still use their old code.
To be honest, NAudio probably needs a V3 with some breaking changes, getting rid of supporting lots of very old legacy stuff, and modernizing the interface to use things like Span, but also async await is needed in a few places to access all the features of WASAPI.
@markheath I can definitely contribute to the testing side. A lot of companies I worked at moved from Moq to NSubstitute, because of their financial thing - Moq requires per-developer licenses, and it sends web requests from time to time.
If you can also upload somewhere the files used in integration tests, we can get those working, and maybe even get a CI pipeline going in this repo.
I have a list of 24 PRs I merged, knowing nothing about the underlying code. They were almost all trivial merges. If that's helpful, let me know.
Updating to .NET 8 should also be fairly easy. There were no breaking API changes that I saw.
FYI @nightblade9 and @markheath The projects I work on, use .NET 8 and .NET 9 I have not found any bugs or problems with NAudio. But, the use of byte[] arrays is "a pain" when using System.IO.Pipelines and other memory management where there is no direct access to the underlying memory.
But enable nullable and the use of Span<T> takes some time.
@markheath I will have a look at the Span branch. But I am not a VB.NET developer. Then, may be there is not an issue any more with VB.NET and Span..
Re: Span... VB still doesn't have support for such; however, with that said... as long as there is an "optimized" path (Span) and a "less optimized" path (for languages that don't support Span) - possibly a wrapper around the Span methods where the performance impact gained by using Span is gained for languages that fully support Span and the negative impact for those that don't is only in affect for languages that don't. And although specifically talking about VB here, there are more languages using .NET than C#, VB and F#. ;-) (As to how many of those are potentially using NAudio, unknown... but I can confirm that at least one VB developer is using NAudio and he has two thumbs. 👍😎👍)
I'll also add that I'm also interested in seeing NAudio progressing toward (more) support for cross-platform; whatever shape that might take. I seem to recall that there was some work taking place on this, breaking up functionality in such a way that the core was cross-platform and platform-specific assemblies in tow.
I can definitely contribute to the testing side.
Feel free to reach out to me on any testing needed (especially on anything VB related).
I'd like to see it being actively maintained too. I'm not sure why there seems to be so little interest from MS themselves in maintaining an audio library for .NET. I guess they're totally focussed on server-side stuff and audio is considered more desktop-tier. Should .NET be something where people are only "meant" to develop server-side stuff in it?
I'd also like to see Naudio continue. It's really the only option for audio in .NET. One of the projects I maintain depends completely on it.
Same here. I've tried literally every C# option by now (CSCore, NAduio, System.Media.AudioPlayer, libVNC) and keep coming back to this.
I've started what I hope will be a community fork, please support it by using it or, more importantly, opening PRs to fix stuff. I don't know anything about digital signal processing. https://github.com/nightblade9/SonicBoom
@rdyhalt
Span and ArrayPool would be a very nice addition. Perhaps some optional support for intelIPP or intelMKL would be interesting for fast arraytype conversions or array operations. I have to admit that small buffers (typically here) are not optimal with such libraries maybe.
Well , NAudio is pretty much the only option for audio manipulation and playback for .NET out there - and there are still so many missing features and bugs to fix yet. I would also like to see this project to continue in the next years. I would like to say at this point that I am working on a project that uses it and have made a handful of optimizations in the interop code. I believe at some point to upload it publicly and some of the fixes it does to upload them here too. For any interop code that you need (COM interop, better interop signatures, Unsafe class and goes on) and for file formats, feel free to contact me. About crossplatforming , I additionally work on a prototype for listening audio on OSX with pure C# and NAudio abstractions. This would be great for the next step on NAudio - to leave out of the Windows nutshell if possible.
This issue shall be pinned so that more users know the situation and discuss the future.
Why don't MS take any interest in funding NAudio development? .NET is their platform, they have basically infinite money, and they won't even hire 1 or 2 devs to make sure .NET has at least one decent audio library.
Why don't MS take any interest in funding NAudio development? .NET is their platform, they have basically infinite money, and they won't even hire 1 or 2 devs to make sure .NET has at least one decent audio library.
Digital audio is indeed a difficult development task without properly understanding core digital audio aspects. MS wouldn't take that burden because they possibly do not have developers that know how to write code for digital audio but also is not in their roadmap because they have never encountered such use case and due to this library and many other reasons. I don't think that they will ever take care of for audio development , especially when they focus only on the question 'how to develop a server app?'. Even for me that I work with digital audio a couple of years now and have explored almost every aspect of it, I can't say that is easy to write audio code. And this is becoming harder when you want to do it with .NET .
The .NET ecosystem is vast and vibrant, and it should not rely solely on Microsoft for everything. Open-source projects like NAudio are a testament to the community's ability to create and maintain valuable tools. If the original maintainer of NAudio is unable to continue, it is indeed a great opportunity for other community members to step up and take over. In fact, this kind of community-driven development is one of the strengths of open-source projects.
If no one is willing to take over, it might be better to archive the project and let other forks evolve into new main branches. This way, the community can still benefit from the original work, while also allowing for new ideas and improvements to emerge.
If the community always expects Microsoft to take over everything when there is a need, that would be a significant failure for the .NET ecosystem. The community should be able to support and drive the development of open-source projects on its own.