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

How to make playback follow active output device? #338

Closed
nyanpasu64 opened this issue Dec 11, 2021 · 3 comments
Closed

How to make playback follow active output device? #338

nyanpasu64 opened this issue Dec 11, 2021 · 3 comments

Comments

@nyanpasu64
Copy link
Contributor

IIRC currently when you open a WASAPI device in an RtAudio app (BambooTracker), and change Windows's default device (eg. by plugging in a new audio output or headphones), RtAudio (and BambooTracker) continues playing to the old device. Ideally, RtAudio on WASAPI would act like web browsers and music players: by default, it would always play to the current default device when you plug or unplug devices or change the default, unless you explicitly pass a device ID into openStream rather than "follow default device". When unplugging an explicitly chosen device, I'd either stop playback with an error, or fallback to the default device (and if no devices are left, you need to error anyway).

I'm not sure if RtAudio supports that now (one reason I'm no longer confident I want to use it in future projects). I didn't look in depth if it's possible, but AFAIK currently StreamParameters::deviceId has no "follow default device as it changes" mode, and all the code I've seen sets param.deviceId = getDefaultOutputDevice() or similar. I don't know if I can implement this in the application or not.

Possibly related: #194.

@nyanpasu64
Copy link
Contributor Author

Neither does locking and unlocking a mutex on every callback (ALSA), or adding an entire period of excess playback latency (ALSA relying on snd_pcm_writei blocking as backpressure), or double latency when playing through pipewire (ALSA backend talking to the pipewire-alsa library which buffers audio, talking to the pipewire daemon which buffers audio again). But RtAudio does all of them. Automatic device switching has no penalty in the happy path (default device not changed) and measurably improves user experience when the user asks RtAudio to use the default device, then unplugs headphones and wonders why the audio stops playing. To me, being useful for audio apps supersedes concerns over whether it makes RtAudio unsuited for real-time playback (which it already is, IMO).

On the topic of implementation, I've heard that WASAPI (unlike past Windows APIs) requires the app manually track the default device. That would complicate implementation. I'll look into what https://github.com/thestk/rtaudio/tree/newdeviceselection is doing at some point.

@garyscavone
Copy link
Contributor

I am closing this. The supported APIs generally do not provide a mechanism to inform RtAudio when the default device is changed. And even if they did, I don't feel comfortable assuming that the user wants audio to be automatically rerouted to another device. Finally, it would require a lot of extra code to attempt to get it to work, which goes against the basic idea of what RtAudio is meant for.

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

3 participants
@nyanpasu64 @garyscavone and others