Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rodio does not respect macOS output device selection. #327

Open
dvtkrlbs opened this issue Oct 7, 2020 · 7 comments
Open

Rodio does not respect macOS output device selection. #327

dvtkrlbs opened this issue Oct 7, 2020 · 7 comments

Comments

@dvtkrlbs
Copy link

dvtkrlbs commented Oct 7, 2020

When i change the output device rodio continues to play the audio on old device.
Screen Shot 2020-10-07 at 08 01 13

@Akirami
Copy link

Akirami commented Oct 12, 2020

Some weird thing here too (MacOS 10.15.6), with the new version (0.12) sink work, play_raw not, sometime Result return the error "no device" and sometime there is no error but no sound either.

Also, if i declare:

let (_stream, stream_handle) = OutputStream::try_default().unwrap();

just before i spawn a thread and append a source to a sink in the thread, there is no error but no sound either.

All is fine if i downgrade the rodio version back to 0.11.

I've no time this day and i'll investigate next week by reading diff between version 0.11 and 0.12, let me know if you want me to open a new topic with more detail.

Edit: I just noticed that sinks also need a thread :: sleep to work properly, without it there is no sound and no errors. It's weird because it forces us to define a minimum duration for each sink played and i don't think this is the expected behavior for it.

@toothbrush
Copy link

Hello! I wonder if there was any progress on this one? I'm also running into this issue.

@tuzz
Copy link
Contributor

tuzz commented Aug 6, 2021

@dvtkrlbs: I don't think rodio will automatically re-create the OutputStream when the default system device is changed, that's probably something you'd have to check for and do yourself, perhaps by polling cpal::available_hosts().

@kaihagseth
Copy link

I have messed around with cpal, and was able to get this to work. Unfortunately, I am no where near familiar enough with rust, audio and osx to make a proper fix. The issue seems to be that cpal generates its AudioUnit with "HalOutput" device from coreaudio, which is related to a specific audio device. If this is changed to "DefaultOutput", librespot starts responding when i change audio output device.
Screenshot 2022-02-20 at 19 36 53

I guess this should be an issue for the cpal project and address how they deal with the osx default output.

@est31
Copy link
Member

est31 commented Feb 20, 2022

PRs (to cpal) welcome!

@kaihagseth
Copy link

This issue should be resolved now, through the fix in cpal just above.

@est31
Copy link
Member

est31 commented Feb 28, 2022

I'll leave this open until a new cpal release with the fix is out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants