Move `SampleFormat` check out of the main stream loop about cpal

[mitchmindtree]

I'm currently looking into implementing this now that #354 has landed.

As a part of this change, I'm thinking about how to best approach the "callback" API for the new Device::build_input_stream/build_output_stream methods.

Rather than the current signature that looks like this:

FnMut(crate::StreamData) + Send + 'static

I'm imagining we could go with something like this.

Input:

FnMut(InputData<T>, &StreamInfo) + Send + 'static

Output:

FnMut(OutputData<T>, &StreamInfo) + Send + 'static

where the *Data type represents the audio data and StreamInfo provides access to other potentially useful information about the stream such as timing information or flags.

The reason I'm thinking we provide a type around the "data" is in case we decide to add support for non-interleaved data in the future. Currently on platforms that only support non-interleaved data (ASIO comes to mind, not sure if there are others) we do the conversion to interleaved behind the scenes, but I can imagine we might want to provide a more transparent API for this in the future.

As for StreamInfo, I might leave this out for now. I plan on looking into adding stream timing in a follow-up API - I might add the StreamInfo type then. I'm also open to better names for this type if anything comes to mind.

[mitchmindtree]

I wonder if it is also worth removing the data_type: SampleFormat field from the Format struct? The Format type is solely used to specify the desired format when calling build_input/output_stream, however with these changes the desired SampleFormat can be inferred from the sample type used within the user's data callback function.

[mitchmindtree]

This has become impossible to implement since the introduction of the EventLoop type, as all streams must now be handled within a single callback, and each stream might be of some different sample format depending on the device it is associated with. #278 may make this possible again, but some serious thought has to be put into how to achieve this while being able to support web audio APIs (see this comment).

[ishitatsuyuki]

I think I'll implement this sometime after the EventLoop deal, but one question is: is there a "default" format that we should expose? I think on most platforms you can choose arbitrary format, but if we need to provide "default" then it would be polymorphic, which doesn't play well with generic API design.

[mitchmindtree]

On second thoughts, the Format type is also used to specify the default format via the Device::default_input/output_format methods.

One option would be to remove the data_type field and have the default_input/output_format return a (Format, SampleFormat)?

An alternative option might be to leave the Format type as is, and instead change the build_input/output_stream methods to take sample rate and number of channels as individual arguments.

Otherwise, we could just leave it as is and assert_eq!(format.data_type, T::FORMAT) at the beginning of each of the build_input/output_stream methods.

[Ralith]

I don't think this has been fixed; as of #359 every relevant example still contains SampleFormat check or an equivalent unwrap in the main loop.

[mitchmindtree]

For anyone following I've responded at #359 here. I'm happy to re-open this if it's decided this is still worth tackling.

[Ralith]

A complete proposal for an improved API has been drafted at #366.