Ive completed my initial pass of review and audit of firewheel and bevy_seedling.
TL;DR: Significant work is needed to make this fit for upstreaming.
Firstly I want to recognize the tremendous effort that has gone into these crates, I
don't intend any of my criticisms to be taken the wrong way. I admire the work and want
to improve it.

`firewheel` has nontrivial UB that must be resolved and general safety practices
need improvement, but that is not actually the largest problem. The biggest problem
is actually that firewheel depends on bevy, meaning upstreaming bevy_seedling would
become a publishing nightmare on version bumps. We would need to coordinate with
firewheel to publish, which is a nonstarter. Thus, the options are:
1. make firewheel not depend on bevy (this has UX implications, and i do not recommend)
2. upstream both firewheel and bevy_seedling.
Between these two options I think 2. is the right choice, for a few reasons:
1. I don't think firewheel is "the wgpu of audio" as it claims. It only has a cpal backend.
firewheel is more akin to bevy_render, since it has nodes and a dsp graph
(render node systems + render graph analogue), and cpal is more akin wgpu in this analogy.
ALSA/JACK/WASAPI/ASIO/CoreAudio etc are equivalent to Vulkan/Metal/DirectX/OpenGL/WebGPU etc.
2. We ideally want to own our audio graph infrastructure and share graph infra with the ecs.
We already have plenty graph infrastructure, and a cursory reading of the schedule compiler
shows this is a very similar problem space, althought with different requirements and tradeoffs.
3. Audio effect chains and nodes will eventually need to be versioned in editor workflows,
and we can't afford to not have migration in our hands. This is non-standardized asset data,
not mainstream file formats. We currently always do this type of thing in-house.
4. We want to own this unsafe code for liability reasons. I do not think its a good idea to
depend on a crate with this much unsafe and have to be vetting every upgrade. This needs to
follow bevy's pr review process and code standards, because there is actual attack surface
here. Loading remote assets (like maliciously crafted effect chains for example) could be
an avenue of exploit via buffer overruns or something of the sort.
5. We already depend on cpal, through rodio. rodio has many issues which make it unsuitable
for game use, and this would allow replacing it wholesale while keeping the same platform
support, and giving us room to grow.
6. We also already depend on symphonium, again through rodio. Its a bit illusion-of-choice
in this regard, but this is pretty clearly the better architecture to me.

I have yet to do benchmarking and compile time testing, but I don't expect any surprises here
judging from the code I read. It is mostly high quality, some questionable structuring decisions
but nothing fundamentally unfixable. Iterative improvement and PRs should get this reasonably
close to "global maxima" good implementation.

Assuming we're in agreement about upstreaming both firewheel and bevy_seedling, there are two
reasonable ways to go about it i believe. The main issue with upstreaming firewheel is the
internal crate structure. Prefixing all eight firewheel internal crates with bevy_ and then
slamming them in crates/ is pretty terrible for a variety of reasons. It pollutes our crate
namespace, suggests that firewheel is fundamentally tied to bevy to function, and is plain
lazy. So we can either
A. We create a bevy_firewheel crate which contains all firewheel subcrates, and the firewheel
top level crate itself, and we take ownership of the crate publishing entirely. bevy_firewheel
becomes the interface bevy_audio (seedling) uses, enabling all the optional bevy impls by default,
and the internal firewheel top level crate continues to have bevy disabled by default but optional.
Non bevy users can depend on this firewheel without ever touching bevy, and we then incrementally
improve firewheel on bevy main from there. This follows the pattern our macro subcrates follow,
and is technically feasible. However, I don't particularly like this approach.
B. We butcher firewheel and seedling to extract a minimal bevy_audio replacement, ditching all the
nodes and graph stuff and going for a lean, feature-parity replacement with the door open for
later incrementally bringing in the dsp graph features, on bevy's own terms and standards.
I have a somewhat clear vision of what this should look like, and am pretty confident it is
possible. I would appreciate collaboration here; ideally I can continue doing mostly rendering work
and simply guide this effort and review/direct it. But I am also open to hacking together an MVP.

To avoid this being a list of only negatives, here are some positives I was on the lookout for
and was satisfied with finding:
- There is a lot of care taken to avoid allocation on the audio thread and being "realtime" safe.
- There is silence optimization. This is very important for performance in practice, because
games arent always playing audio through every effect chain.
- There is (optional) denormal flush to zero. Denormal numbers still have a pretty big perf hit
these days.
- There is a wealth of effects which would be very useful for games. It is good that these are
"proving out" the architecture is flexible enough for all the uses games will need.
- Documentation is mostly very good. I'll be PRing some improvements but very happy with what i saw.
- Test coverage is quite reasonable and inspires confidence.

The last thing I want to note is that both bevy_seedling and bevy_audio need api improvements imo.
*When* we do these changes is up for discussion. I am not sure if its worse to hammer bevy_seedling
into fitting bevy_audio's somewhat flawed apis, or if its better to fix bevy_audio's flawed apis
and then match seedling to that, or simply outright replace bevy_audio with bevy_seedling's current
api and then fix seedling's api, or if its better to fix seedling's api and then replace bevy_audio
with that. There's pros and cons to all of them. I'm slightly partial to keeping seedling apis as-is
for upstreaming and then fixing later, but can be convinced otherwise.

Either way the immediate steps are clear, I have my work cut out for me fixing up firewheel UB
and general safety practices. While I do this, I'd like to get consensus on which of the approaches
I proposed we should take, and build some level of trust and commitment to move forward with this.
I'd also like to gauge to what extent @BillyDM and @Corvus Prudens (and anyone else) can help.