librespot-org
Expose possible mixer opening errors
This should address the possible panic found in #1478 by exposing the errors that might occur while opening a device.
The binary will now exit when it encounters an issue while opening the mixer.
Fixes #1478
@ers4691, @kingosticks Could you take a look at the changes and maybe give me some feedback if that is what you had in mind? I just want to be sure I didn't misunderstood the expected behavior you discussed in #1478.
Tl;dr; The binary exits with 1 when encountering issues when starting the mixer. For example when a requested alsa device isn't available.
I'm not quite there yet. First of all, it's great that there is no longer a Panic error.
But think about the use case: librespot should be running on your home server. You now want to listen to Spotify on your old stereo system. Switch on your old amplifier, switch on the DAC that is connected to the home server and select the home server as the loudspeaker with your Spotify client (mobile). And now the music should start playing. In other words, the query if an Alsa mixer is present is too early at the time of starting librespot.
I don't know whether it's worth the effort. Thanks for fixing the panic error.
I see. Thanks for that input, I think I understand now what you try to do. It's probably possible (at least when you use zeroconf), but would overload this PR for sure.
Maybe you also search for a solution where librespot is auto started when the DAC is added to the system? Because when you remove/shutdown the DAC, I would suspect that librespot crashes/panics anyways? So you would need to restart it anyways later. Or how is you workflow there? I would like to understand if there is really a use case here, or if this is rather a job for a separate application like spotifyd (don't know if the support something like that, but that application is specifically designed to run as service).
Tho if you use an already authenticated librespot device, we would need to change something in the connect implementation.
Otherwise this whole idea of a late player initialization wouldn't be currently possible as the code in the connect implementation is in our control and can't be modified. If that is what you desire you could open a feature request and we might consider/implement it in the future. In terms of work to do, I currently don't see a lot of roadblocks, but that is something you really see when implementing it :)