[GH-ISSUE #547] Change of output device on macos doesn't affect librespot playback

kerem commented

2026-02-27 19:30:09 +03:00

Owner

Originally created by @hgvhgv on GitHub (Dec 12, 2020).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/547

I just started using ncspot on macos 10.15.7. When I change the output device via macos (e.g., from speakers to bluetooth), ncspot continues playback over the original device and has to be restarted to switch.

I built librespot today and confirmed that it happens with a simple librespot server and spotify connect. When I run librespot with verbose output, nothing registers when I change the macos output device.

This was already reported on ncspot (https://github.com/hrkfdn/ncspot/issues/339). It is perhaps related to this rodio issue, but the rodio version included with librespot is earlier than this (https://github.com/RustAudio/rodio/issues/327).

If I have time, I might try building rodio and testing it directly there, though the version issue might complicate this.

Originally created by @hgvhgv on GitHub (Dec 12, 2020). Original GitHub issue: https://github.com/librespot-org/librespot/issues/547 I just started using ncspot on macos 10.15.7. When I change the output device via macos (e.g., from speakers to bluetooth), ncspot continues playback over the original device and has to be restarted to switch. I built librespot today and confirmed that it happens with a simple librespot server and spotify connect. When I run librespot with verbose output, nothing registers when I change the macos output device. This was already reported on ncspot (https://github.com/hrkfdn/ncspot/issues/339). It is perhaps related to this rodio issue, but the rodio version included with librespot is earlier than this (https://github.com/RustAudio/rodio/issues/327). If I have time, I might try building rodio and testing it directly there, though the version issue might complicate this.

kerem

2026-02-27 19:30:09 +03:00

closed this issue
added the
wontfix

audio
labels

kerem commented

2026-02-27 19:30:10 +03:00

Author

Owner

@ashthespy commented on GitHub (Dec 12, 2020):

FWIW, there is a WIP branch with newer Rodio #543

@ashthespy commented on GitHub (Dec 12, 2020): FWIW, there is a WIP branch with newer Rodio #543

kerem commented

2026-02-27 19:30:10 +03:00

Author

Owner

@hgvhgv commented on GitHub (Dec 13, 2020):

OK so I recompiled librespot with portaudio backend, and the problem persisted. So it's possibly related to librespot, but is possibly a problem shared by rodio and portaudio. I've always had problems with pulseaudio on macos, so I'm not going to try that.

The recompilation did sound better, though, and I realized that I was experiencing some of the noise with rodio reported elsewhere (e.g., https://github.com/RustAudio/rodio/issues/225, https://github.com/hrkfdn/ncspot/issues/333).

@hgvhgv commented on GitHub (Dec 13, 2020): OK so I recompiled librespot with portaudio backend, and the problem persisted. So it's possibly related to librespot, but is possibly a problem shared by rodio and portaudio. I've always had problems with pulseaudio on macos, so I'm not going to try that. The recompilation did sound better, though, and I realized that I was experiencing some of the noise with rodio reported elsewhere (e.g., https://github.com/RustAudio/rodio/issues/225, https://github.com/hrkfdn/ncspot/issues/333).

kerem commented

2026-02-27 19:30:10 +03:00

Author

Owner

@roderickvd commented on GitHub (May 25, 2021):

Yes this is outside of the scope of librespot, and a consequence of how the backend crates open the playback devices.

@roderickvd commented on GitHub (May 25, 2021): Yes this is outside of the scope of `librespot`, and a consequence of how the backend crates open the playback devices.

kerem commented

2026-02-27 19:30:10 +03:00

Author

Owner

@deed02392 commented on GitHub (Oct 6, 2021):

@roderickvd Is there any backend audio crate that addresses this issue? What is particular about the backend crates that causes the issue?

@deed02392 commented on GitHub (Oct 6, 2021): @roderickvd Is there any backend audio crate that addresses this issue? What is particular about the backend crates that causes the issue?

kerem commented

2026-02-27 19:30:10 +03:00

Author

Owner

@roderickvd commented on GitHub (Oct 6, 2021):

I don't think so. It's not the crates, but the way the lower level OS API opens a stream to a device. For another device to play, a new stream has to be opened. The OS doesn't inform the userspace app this is the case, nor does it reroute the existing stream.

@roderickvd commented on GitHub (Oct 6, 2021): I don't think so. It's not the crates, but the way the lower level OS API opens a stream to a device. For another device to play, a new stream has to be opened. The OS doesn't inform the userspace app this is the case, nor does it reroute the existing stream.

kerem commented

2026-02-27 19:30:10 +03:00

Author

Owner

@deed02392 commented on GitHub (Oct 7, 2021):

Thanks for the reply! But how do other userspace apps handle this so effectively? For example the Spotify desktop app happily and transparently simply starts to output audio to the new system default output device. Why aren't the userspace audio backends that librespot implements doing the same thing?

@deed02392 commented on GitHub (Oct 7, 2021): Thanks for the reply! But how do other userspace apps handle this so effectively? For example the Spotify desktop app happily and transparently simply starts to output audio to the new system default output device. Why aren't the userspace audio backends that librespot implements doing the same thing?

kerem commented

2026-02-27 19:30:10 +03:00

Author

Owner

@roderickvd commented on GitHub (Oct 7, 2021):

It’s a good question but better adressed to the folks at Rodio.

@roderickvd commented on GitHub (Oct 7, 2021): It’s a good question but better adressed to the folks at Rodio.

kerem commented

2026-02-27 19:30:10 +03:00

Author

Owner

@aviwad commented on GitHub (Apr 16, 2022):

still experiencing this problem.

@aviwad commented on GitHub (Apr 16, 2022): still experiencing this problem.

kerem commented

2026-02-27 19:30:10 +03:00

Author

Owner

@roderickvd commented on GitHub (Apr 16, 2022):

For those who are experiencing this but did not read through the posts: yes this issue exists but belongs to a dependency of ours, not librespot itself. Repeating that it does not work here does nothing to further that.

@roderickvd commented on GitHub (Apr 16, 2022): For those who are experiencing this but did not read through the posts: yes this issue exists but belongs to a dependency of ours, not `librespot` itself. Repeating that it does not work here does nothing to further that.

kerem commented

2026-02-27 19:30:10 +03:00

Author

Owner

@aviwad commented on GitHub (Apr 16, 2022):

my bad. just checked the culprit was calp in rustaudio.

@aviwad commented on GitHub (Apr 16, 2022): my bad. just checked the culprit was calp in rustaudio.

kerem commented

2026-02-27 19:30:10 +03:00

Author

Owner

@jackwellsxyz commented on GitHub (May 21, 2022):

There doesn't appear to be any movement on the cpal front to fix this bug in Mac OS at least. This has been open since January 2021. https://github.com/RustAudio/cpal/issues/528. This means playback on Mac OS is a pretty poor experience since you're probably limited to playback through speakers only.

@jackwellsxyz commented on GitHub (May 21, 2022): There doesn't appear to be any movement on the cpal front to fix this bug in Mac OS at least. This has been open since January 2021. https://github.com/RustAudio/cpal/issues/528. This means playback on Mac OS is a pretty poor experience since you're probably limited to playback through speakers only.

kerem commented

2026-02-27 19:30:10 +03:00

Author

Owner

@sjdonado commented on GitHub (Oct 5, 2023):

There doesn't appear to be any movement on the cpal front to fix this bug in Mac OS at least. This has been open since January 2021. RustAudio/cpal#528. This means playback on Mac OS is a pretty poor experience since you're probably limited to playback through speakers only.

you can play on the airpods if they are connected before the service is started

@sjdonado commented on GitHub (Oct 5, 2023): > There doesn't appear to be any movement on the cpal front to fix this bug in Mac OS at least. This has been open since January 2021. [RustAudio/cpal#528](https://github.com/RustAudio/cpal/issues/528). This means playback on Mac OS is a pretty poor experience since you're probably limited to playback through speakers only. you can play on the airpods if they are connected before the service is started

kerem commented

2026-02-27 19:30:10 +03:00

Author

Owner

@xartuu commented on GitHub (May 9, 2024):

The problem continues to occur. I am using ncspot 1.1.0 (https://github.com/hrkfdn/ncspot/issues/339). When connecting an audio device, the music does not automatically switch to the new device.

Unfortunately, this is the only thing and also noticeable when using Spotify in cli, which is a shame. Has anything changed on this subject?

Unless I am mistaken this has been fixed in https://github.com/RustAudio/rodio/issues/225? Can portaudio backend also do this?

@xartuu commented on GitHub (May 9, 2024): The problem continues to occur. I am using ncspot 1.1.0 (https://github.com/hrkfdn/ncspot/issues/339). When connecting an audio device, the music does not automatically switch to the new device. Unfortunately, this is the only thing and also noticeable when using Spotify in cli, which is a shame. Has anything changed on this subject? Unless I am mistaken this has been fixed in https://github.com/RustAudio/rodio/issues/225? Can portaudio backend also do this?

Rows
Columns

[GH-ISSUE #547] Change of output device on macos doesn't affect librespot playback #350