Error when opening default stream on iOS

[EriKWDev]

Hi!

I've compiled a project for iOS (aarch64-apple-ios) in release mode. It compiles and runs on macOS, and without rodio the app runs fine on both iPhone and iPad. (iOS 18.1.1 and iOS 17.6.1 respectively)

However, even if rodio compiles and links successfully for the iOS target, when I run I get BuildStreamError(StreamConfigNotSupported)

I'm calling

let output = rodio::OutputStreamBuilder::open_default_stream().unwrap();

and using the latest commit on HEAD of the git repo as the version (70d01daf24)

the project is compiled as a static library and included as a library to link with in Xcode. Initially Xcode complained that it couldn't find some symbols like _AudioComponentFindNext and _AudioUnitUninitialize and some more, but it went away when I explicitly added the AudioToolbox.framework as a linked library as well.

I get the same error in debug mode as well, and also if I try on the simulator with aarch64-apple-ios-sim target

How may I assist in debugging this?

[EriKWDev]

If it is of any help, I tried separating the from_default_device and open_stream calls, and it is the open_stream call which fails.

// let output = rodio::OutputStreamBuilder::open_default_stream().unwrap();
let b = rodio::OutputStreamBuilder::from_default_device().unwrap();
let output = b.open_stream().unwrap();

[dvdsk]

I took a quick look, StreamConfigNotSupported is only returned when the sample type is not supported by rodio, however all sample types that are common are.

Its quite the list, see https://github.com/RustAudio/rodio/blob/70d01daf24da8032b1bc04bfad1ec85d6be3c0f5/src/stream.rs#L320)

Can you debug print your variable b? dbg!(b).open_stream().unwrap() should do it.

[EriKWDev]

Can you debug print your variable b?

I tried but it didn't implement debug 😅 but can make a fork and quickly try

Thanks for having a look so promptly

[dvdsk]

I tried but it didn't implement debug 😅 but can make a fork and quickly try

huuuu thats wierd it should. Its an OutputStreamConfig right?

edit your right!

[EriKWDev]

No worries! Yeah the config implements Debug but the builder doesn't and the field is private..

Anyway, made a fork and here is the debug:

 OutputStreamConfig {
      channel_count: 2,
      sample_rate: 48000,
      buffer_size: Fixed(
          0,
      ),
      sample_format: F32,
  }

[EriKWDev]

Fixed(0) looked a little suspicious. When I made it rodio::cpal::BufferSize::Default instead, it worked!

[dvdsk]

No worries! Yeah the config implements Debug but the builder doesn't and the field is private..

fixed that OutputStreamConfig now implements Debug.

Fixed(0) looked a little suspicious. When I made it rodio::cpal::BufferSize::Default instead, it worked!

Thats super useful! thanks for that discovery!

[dvdsk]

I took a quick look, StreamConfigNotSupported is only returned when the sample type is not supported by rodio, however all sample types that are common are.

this is wrong, StreamConfigNotSupported is not a rodio type but from cpal. We probably should not be using it but use our own to prevent this confusion.

[dvdsk]

So the question is is this our bug or upstream. I am leaning towards the second. The config is coming from cpal's: Device::default_output_config. Which must be returning a SupportedBufferSize::Range {0,0}.

@EriKWDev could confirm this by dbg printing the config passed to the function: with_supported_config in rodio's OutputStreamBuilder::from_device?

[EriKWDev]

Can do it later but heading away at the moment. But yeah might be from cpal this is coming from

[PetrGlad]

BuildStreamError::StreamConfigNotSupported is a cpal error, so it can also be raised there.

I wonder why compiler complains about missing matches in src/stream.rs:440 since it looks like all existing cases are explicitly covered.

I will add an assertion in clamp_supported_buffer_size. Since this is a part of default stream opening helpers maybe we can silently replace Fixed(0) to Default. Or maybe also write a debug message just in case.

[dvdsk]

I will add an assertion in clamp_supported_buffer_size.

good idea

maybe we can silently replace Fixed(0) to Default.

I rather have it fixed in cpal to be honest. That may take a while, we could for now add the workaround in rodio we should document that with a comment linked to a cpal issue.

[PetrGlad]

@dvdsk We may add a ticket to cpal regarding this. BUt I suspect CPAl may not be able to determine buffer size in some cases, so the defaulting logic has to be somewhere anyway.

[PetrGlad]

Found it. cpal's SampleFormat is annotated with #[non_exhaustive] that is why a fallback case is required...

[dvdsk]

@dvdsk We may add a ticket to cpal regarding this. But I suspect CPAl may not be able to determine buffer size in some cases, so the defaulting logic has to be somewhere anyway.

Agreed but having that logic in cpal makes more sense since they have a Default bufferlenght right?

Anyway we cant make the issue till we are sure, and I do not have the hardware required. @EriKWDev there is no rush but to solve this correctly we do need your help yet again :)

[EriKWDev]

I'm more than happy to help out, but won't be back at the mac until later this evening. What are the things you would need debugged?

[dvdsk]

I'm more than happy to help out, but won't be back at the mac until later this evening. What are the things you would need debugged?

Could you check if cpal's beep example works? https://github.com/RustAudio/cpal/blob/master/examples/beep.rs

If it does not then this is a cpal issue. And it would be great if you could then open it there (they might need your help making progress).

If beep does work then.... I will be confused :)

[roderickvd]

Closing this because it's stale. Feel free to reopen if the issue remains, with additional clarification.