Tracking issue for redesigning the Sink API

[dvdsk]

There are currently two seperate PR's that expand on the Sink's functionality to be more easily used as a 'playlist':

• Allow retrieving the queue signal in a sink when using crossbeam-channel feature #600
• Add a SourcesIdQueueInput that allows manipulating items in the queue #506

This issue is to discuss a new Sink which supports both those applications, maybe by merging those PR's or by making breaking changes to the current Sink.

This should take #613 into account.

[teliosdev]

I think having append return a type that allows the user to register interest in when the sound is finished playing, whether that's sync or async. You may be able to avoid exposing channels at all with this, as the returned (opaque) type can have fn wait(&self) (which blocks the calling thread until the sound is done playing), and async fn stopped(&self), which only completes when the sound is done.

This also allows extension in the future to perform acts upon the specific sound, if that's desired, as well.

You can have this type take &self instead of &mut self by replacing the use of std::sync::mpsc with a Mutex/Condvar for the blocking API. For the async API, you may be able to get away with an AtomicBool/AtomicWaker.

[dvdsk]

We might not strictly need an append with interest since there is EmptyCallback. You could append this to the sink after the sound of interest then you would get a callback fired when the source is done.

This is hard to find, so some documentation effort may be needed. Even then it might be worth wile handling this in the sink via an append_with_callback that does append(source) then append(emptycallback).