Use symphonia::io::MediaSource for Reader extensions

[james7132]

This PR does the following:

• Changes both Reader::Extension and Reader::ExtensionSeek to use symphonia::io::MediaSourceStream.
• Removes the File and Vec variants of readers, instead opting to provide a from_file and from_memory associated function to create readers from the File and Cursor<Vec<u8>> implementations of MediaSource.
• Removes the ReadSeek trait.
• Added a dependency on symphonia_core. This crate has no additional dependencies.

This allows Songbird to be extended with streams from Symphonia, which should allows for a common interface for defining user provided streams that also allow easily hooking into Symphonia's ecosystem for in process transcoding. This would likely be more lightweight than reading from a pipe from ffmpeg and allow for transcoding streams fetched from non-local sources (i.e. YouTube, SoundCloud).

One potentially important change is that MediaSourceStream is now used to implement both in-memory and file based Readers. This adds, by default, a 32KB buffer to every reader of the aforementioned types, though it can be configured. If this is an unacceptable cost, it can be changed to Box<dyn MediaSource> instead. It should be noted that MediaSourceStream itself implements MediaSource, but defaulting to a boxing a MediaSourceStream for buffering will result in additional dynamic dispatch which may not be desired.

This PR is still a WIP. It's dependent on a fork of Symphonia to add a Send marker on MediaSource to make it compatible with Songbird's threading model.

[FelixMcFelix]

Thanks for the PR. I think this is a better way of allowing user extension, rather than our current (slightly ad-hoc) decoding setup. I think that I would much prefer Box<dyn MediaSource + Send> right now, as that this means that:

• we only need to re-export one trait to users,
• we get runtime checking of seek-compatibility,
• users don't need to construct and configure a soft-buffered source, if they don't need/want to,
• this shouldn't require you to manually put Send bounds in the upstream crate, hopefully.

Having to pay dynamic dispatch on Files/Cursor<Vec<u8>>s sucks, but it's likely negligible compared to encryption/encoding costs.

I haven't looked too much into symphonia, but I assume you're aiming to put full (reader + decoder) chains into a songbird Reader to get the transcoders you need working?

On another note, I think symphonia looks like a very promising family of crates if we want to change the audio stack down the line (and we probably do!). When I started work on reworking serenity voice, the only other Rust audio stack I knew of was rodio. I think it's worth keeping an eye on this, if it can prevent us from having to (re)implement mkv/ogg/etc. handlers or dynamically link to ffmpeg.

[james7132]

On another note, I think symphonia looks like a very promising family of crates if we want to change the audio stack down the line (and we probably do!). When I started work on reworking serenity voice, the only other Rust audio stack I knew of was rodio. I think it's worth keeping an eye on this, if it can prevent us from having to (re)implement mkv/ogg/etc. handlers or dynamically link to ffmpeg.

There are also projects like rust-av, a pure Rust rewrite of lib-av, a fork of ffmpeg, though that's generally aimed at any form of transcoding, including video. Though it may be useful to extract audio from video containers (i.e MP4 files or YouTube).

Symphonia was the first one I happened on that fit the API of songbird well and supported several of the features similar libraries (i.e Lavaplayer) offer that songbird currently doesn't. Namely container and format definitions, metadata parsing, format probing and transcoding.

If there is a better option for those, songbird may be better served using that ecosystem instead.

I haven't looked too much into symphonia, but I assume you're aiming to put full (reader + decoder) chains into a songbird Reader to get the transcoders you need working?

I'm aiming to replicate the full Lavalink feature set in Oxilink, which relies heavily on many of the features provided by Lavaplayer for zero-IPC transcoding. Symphonia or dynamically linking in ffmpeg should cover the in-process transcoding features that Lavaplayer manually implemented that Songbird currently has no support for.

[FelixMcFelix]

Apologies for force-rebasing next, one or two commits complicate history.

Looks good apart from some nits, thanks. Could I ask that you test the mixing benchmarks (cargo make bench) to ensure that this change doesn't break those? They rely upon Vec-based audio sources.

Formatting should go through nightly rust (cargo +nightly fmt) to get trailing commas etc working correctly.

[james7132]

Output of cargo bench:

Mix stereo source       time:   [621.07 ns 662.54 ns 700.92 ns]
                        change: [-5.7327% +2.1139% +12.968%] (p = 0.69 > 0.05)
                        No change in performance detected.
Found 19 outliers among 100 measurements (19.00%)
  2 (2.00%) high mild
  17 (17.00%) high severe

Mix mono source         time:   [434.42 ns 458.77 ns 483.26 ns]
                        change: [-6.8324% +0.3071% +12.644%] (p = 0.96 > 0.05)
                        No change in performance detected.
Found 17 outliers among 100 measurements (17.00%)
  1 (1.00%) high mild
  16 (16.00%) high severe

[FelixMcFelix]

Thanks very much, looks good to me!