Switch to Rodio for audio playback.

[sashahilton00]

We've discussed this briefly in Gitter over the past day or so, hence this issue is a tracking issue. The core functionality of Librespot is to provide a library for accessing music and metadata via the Spotify API, and enabling playback as a connect device. Imo it shouldn't be the job of the library to handle audio playback functionality.

Increasingly, as the number of audio backends available has increased, the number of issues related to librespot's implementation of the various backends have also increased, to the point where issues with audio backend implementations accounting for almost the same number of issues (#183, #158, #89, #68, #48, #45, #32, #29, #28) as the rest of the functionality of librespot does. Hence, I proposed that instead of having a number of imperfect implementations for the various audio backends, we hand off that functionality to rodio.

Rodio is an audio decoding and playback library written in rust, which uses lewton and cpal to handle decoding and playback respectively. We already use lewton for decoding, whilst cpal provides a better interface to the various platform-dependent audio backends (ALSA for linux, Coreaudio for OSX, WASAPI for Windows). By moving to Rodio, we can cut most of the time spent working on playback issues, and focus on adding features/fixing bugs librespot, which I imagine most people would prefer. Whilst also fixing bugs we encouter with rodio, leading to a better audio library for rust in general.

There are evidently a few people who use jackaudio and pulseaudio with librespot, and the tradeoff of using Rodio would likely be that support for other backends would be dropped, since a significant benefit to using Rodio would be the elimination of all the backend/sink clutter that playback curerntly uses. Is this something that those of you that use pulseaudio, etc. feel would make librespot significantly harder to use, or can you accomodate it?

[mfeif]

I'm a pulseaudio user and fan; to me, paradoxically perhaps, having pulseaudio be backend lets me do LESS with librespot: I can let PA send the sound where I want, and do to the sound what I want. If I can only dump into hardware, I can do less.

Seems like one of the benefits to rodio (which is really cpal) is to support multiple OS's... and I'm not sure that librespot is going to do that for non-unix targets.

I do imagine that chasing down these bugs related to all the various outputs is getting to be a big deal, so I have sympathy for this position.

But if indeed the "core functionality" is "enabling playback" then I for one want it to enable playback :-) Ditching Pulse would be a negative for me. Yes, I can route back to Pulse from alsa, but pulse is the modern standard, alsa is low-level.

I obviously understand that maintainability and sanity of the devs is priority #1 however.

TL;DR: For me, it'd make librespot worse, but I can accommodate it.

[sashahilton00]

@mfeif thanks for the feedback. When you say one of the benefits of cpal is to support multiple OS's, but you don't see librespot doing that, afaik it compiles on OS X, Linux and Windows. What other targets are we lacking support for?

Also, as far as I know pulseaudio uses ALSA for playback, though I agree that it's easier to use pulse than using ALSA directly.

[mfeif]

@sashahilton00 I didn't realize librespot worked on Windows, sorry. I saw that this library works on Windows and iOS (and "Emscripten"?) and thought it might therefore not be a good match. I stand corrected.

Pulseaudio does use ALSA for hardware drivers. Alsa has some feature above the hardware level too, which makes it confusing, but pulse sits on alsa and makes it have a nicer API. Pulse itself does stuff to audio like resampling, remixing, sync'ing streams among several outputs, moving streams when an output disappears (like a USB card), sending to networks and so on. It remembers different volume levels for different applications, it allows you to send some streams to one device and others to another, it is smarter about switching things off when you plug-in headphones, etc.

In my experience with librespot, it often gets a buffer underrun on ALSA, and hopefully cpal would prevent that, as pulseaudio does.

I suppose I wish that there were another way to abstract the sound output that included pulse, which is considered important on linux... there's a reason that Debian/Ubuntu/Redhat all use it by default. There are also people who hate it, I suppose because they think it's unnecessary if one only wants to play sound.

Thanks for hearing me out.

[janderholm]

Lewton does not have support for fixed point Vorbis support, and sadly there doesn't seem to be a lot of progress on that front: RustAudio/lewton#9

Dropping Tremor in favor of Lewton means dropping support for targets without FPUs and that would be a bit disappointing for as that would keep me from using it completely. I would consider helping out to add support for fixed point Vorbis in Lewton but sadly I am completely inept at anything that has to do with mathematics and signal processing.

Also there seem to be a lot of open issues on cpal, at least one is blocking for librespot RustAudio/cpal#85

[mfeif]

I've been considering my comment; I think that by forcing ALSA to default its' output to pulse, I can get back all the things I need.