Selecting a non-default Output is pretty much locked down

[sandreas]

Hey @yara-blue ,

as requested, here is some "early feedback". I'd like to select a non-default Output by the device.id from cpal. Unfortunately, the Output struct encapsulates cpal::Device and with it the ability to select a device by id:

Something like this is not possible for Output:

    let device = if let Some(device) = opt.device.clone() {
        let id = &device.parse().expect("failed to parse device id");
        host.device_by_id(id)
    } else {
        host.default_output_device()
    }.expect("failed to find output device");

   // fields are private
   let output = Output {
          default: false,
          inner: device
  };

When enumerating devices the id is not accessible either:

use rodio::speakers::{SpeakersBuilder, available_outputs};

// List all available output devices
let outputs = available_outputs()?;
for (i, output) in outputs.iter().enumerate() {
  // no access to output.device_id either.
    println!("output {}: {}", i, output);
}

// Use a specific device (e.g., the second one)
let speakers = SpeakersBuilder::new()
    .device(outputs[1].clone())?
    .default_config()?
    .open_mixer()?;

So saving and restoring a selected device by a unique device identifier is not possible despite I overlooked something important.

[yara-blue]

as requested, here is some "early feedback".

Thank you so much, super useful!

So saving and restoring a selected device by a unique device identifier is not possible despite I overlooked something important.

Good point, that's quiet an important use-case completely overlooked. We could easily expose a try_from(cpal::Device) however ideally we also have an answer for that use-case.

Straight up deriving Serialize/Deserialize won't work since we would need to run device_by_id on deser..... well technically we could but that feels like an unexpected way for deserialization to fail. Maybe adding a second Output struct called something like OutputId. But at that point we are basically mimicking cpals UI.

I got to think about it for a bit. For now I'll just add a try_from impl to Output.

[yara-blue]

Played around a little and I think we can fully encapsulate cpal's host and device in something that can be serialized and deserialized easily. I'll let you know once it's in!

[sandreas]

Thanks for the quick response. I'm working around this in my fork and see if I can find other things to improve :-)

[sandreas]

@yara-blue

Ok, now that I made the properties of Output public, playback works like expected but shows the fast-forward behaviour when I use the rodio::Player struct. Unfortunately I did not find a way to create a FixedSource for the new approach to playback a file. My current testing code looks like this:

        let file_result = File::open(path);

        if let Ok(file) = file_result {
            let decoder_result = Decoder::try_from(file);

            if let Some(sink) = &self.sink && let Ok(decoder) = decoder_result{
                sink.clear();
                sink.append(decoder);
                if position > zero_duration {
                    let _ = sink.try_seek(position);
                }
                return true;
            }
        }

How would I apply these to the new approach?:

// what to do here instead of File::open / Decoder::try_from????            
let source_from_file: dyn FixedSource = ...;


let speakers = SpeakersBuilder::new().default_device()?.default_config()?;
let config = speakers.get_config();
let _speakers = speakers.play(source_from_file)?;

[yara-blue]

// what to do here instead of File::open / Decoder::try_from????            
let source_from_file: dyn FixedSource = ...;

The issue is that a Decoder can change parameters on the fly, so those only implement Source (DynamicSource in the new lingo used here). You have two ways to get a FixedSource from a dynamic one:

• source_from_file.try_as_fixed_source()?
• resample_into_fixed_source(sample_rate, channel_count)?

The latter will always work, however at the cost of resampling and converting the channel count. If you open the output first (SpeakersBuilder) you can pass the output's sample_rate and channel_count to resample_into_fixed_source.

In the old system the resampling happened at the end of the pipeline just before output, now we move it to the start. That makes all the parts in between far easier since they no longer need to consider sample rate and channel count changing at any point. It should also be more performant.

[yara-blue]

Oh and it seems I did not yet implement/add seeking behavior 😅 to the sources. (Wanted to get the traits good/ know they work first).