Rename sink and stream

[yara-blue]

As discussed in #815 (comment) this renames parts of rodio so they actually make sense.

This builds upon: #815, it should be merged first

PS: ignore branch name, I wanted to introduce a new source trait here but the rename takes priority.

[yara-blue]

No need for an in depth review, more requesting it to be sure you agree with the idea of the changes.

The content of the PR is just a find replace.

[yara-blue]

oh actually this needs a change-log entry :). I'll go ahead and add that.

[roderickvd]

I like the change from Sink to Player.

However, I am less sure about the rename from OutputStream to MixerOsSink:

1. "Os" may be misleading: it suggests OS-level audio, but many backends are userspace (JACK, PulseAudio, PipeWire). Future outputs could be files or network endpoints.

2. "Mixer" is an implementation detail. Users shouldn't need to know whether it uses a mixer internally.

I suggest to rename to DeviceSink if we want consistency with both cpal and a future Sink trait that encompasses device/file/network outputs.

Instead of open_mixer_sink we could then do:

• DeviceSinkBuilder::open() - Mixer is the default implementation
• DeviceSinkBuilder::open_queued() - For in the future, or...
• DeviceSinkBuilder::new().with_queue().open() - To configure a queue

[yara-blue]

1. "Os" may be misleading: it suggests OS-level audio, but many backends are userspace (JACK, PulseAudio, PipeWire). Future outputs could be files or network endpoints.

Then those could be FileSink or NetworkSink.

2. "Mixer" is an implementation detail. Users shouldn't need to know whether it uses a mixer internally.

I don't agree, the default right now is mixing. Yes that works for all but it also wastes cpu cycles for all. If you just need a queue you should not be forced to go through the mixer API and pay the runtime cost of mixing.

I suggest to rename to DeviceSink

I'm okay with an OS -> Device rename.

and a future Sink trait that encompasses device/file/network outputs.

Are you suggesting we have an "all encompassing" Sink struct? I would be against that. It seems useful to have a clear distinction in sinks. If users truly need to abstract over those we could offer them a trait (they may Box it themselves).

Instead of open_mixer_sink we could then do:

* `DeviceSinkBuilder::open()` - Mixer is the default implementation

* `DeviceSinkBuilder::open_queued()` - For in the future, or...

* `DeviceSinkBuilder::new().with_queue().open()` - To configure a queue

I have a little rodio experiment going on where I have:

SinkBuilder::play(source: impl Source);
SinkBuilder::queue();
SinkBuilder::mixer();

Mixer is just shorthand for:

let (MixerSource, MixerHandle) = mixer::new();
builder.play(MixerSource);
return MixerHandle;

How about we go with: play, open_queue and open_mixer?

[roderickvd]

1. "Os" may be misleading: it suggests OS-level audio, but many backends are userspace (JACK, PulseAudio, PipeWire). Future outputs could be files or network endpoints.

Then those could be FileSink or NetworkSink.

I agree and have their own builders.

2. "Mixer" is an implementation detail. Users shouldn't need to know whether it uses a mixer internally.

I don't agree, the default right now is mixing. Yes that works for all but it also wastes cpu cycles for all. If you just need a queue you should not be forced to go through the mixer API and pay the runtime cost of mixing.

I agree that it's wasteful and shouldn't be necessary.

and a future Sink trait that encompasses device/file/network outputs.

Are you suggesting we have an "all encompassing" Sink struct? I would be against that. It seems useful to have a clear distinction in sinks. If users truly need to abstract over those we could offer them a trait (they may Box it themselves).

Yes I was also thinking a trait, so that a user can plug in a DeviceSink or FileSink and let it be entirely opaque.

I have a little rodio experiment going on where I have:

SinkBuilder::play(source: impl Source);
SinkBuilder::queue();
SinkBuilder::mixer();

How about we go with: play, open_queue and open_mixer?

Looks good.

[yara-blue]

wonderful! I'll go and make the changes now :)