Spotify web player in moOde local display

[TheOldPresbyope]

Can confirm that the workaround indeed works.
Just use these three commands in order and you will be able to use the Spotify Webplayer on your system.

Code:

sudo moode-apt-mark unhold
sudo apt install chromium-browser:armhf
sudo moode-apt-mark hold

Interesting and couple of questions.

1. Do you think this could be used to provide a generalized feature for accessing and playing music from streaming services?

2. Can chromium-browser be configured to route audio to locally attached USB or I2S ]audio devices?

As I said earlier, this isn't really a use-case I'm interested in, but I haven't seen a reply from the OP yet, so here's my 2-cents worth.

I'd expect this would work for any streaming service which provides an in-browser player experience. 

To test, I flashed the 32-bit moOde 8.2.4 image to another uSD card and fired it up on an RPi3B+ with an Official 7-in touch screen and a USB DAC (actually, my Creative Tech USB-BT adapter, which enumerates as a USB audio device). I chose the 32-bit image to minimize the hackery; of course I added the requisite libwidevinecdm0 library.

I configured moOde to output to my Creative Tech adapter and tested everything was working by listening via Bluetooth earphones to several radio stations.

I tried starting the local display om three different streaming services: Spotify (open.spotify.com), Qobuz (play.qobuz.com), and Youtube Music (music.youtube.com). I didn't try Tidal or Amazon Music.

1) Qobuz advises it needs a screen at least 1024 wide and won't go further.

2) Spotify comes up and after signing in, I can browse and play tracks. However, the Chromium browser is playing to the first alsa card which is the RPi3B+ headphone jack, confirmed by looking at /proc/asound/card0/pcm0p/sub0/status and later by plugging in some earbuds.

3) Youtube Music, same behavior as with Spotify.

Observations:

1. I have no idea how you'd blend this with the existing moOdeUI.


2. Signing into these web apps is annoying. The popup keyboard doesn't work in the browser so I had to plug in a USB keyboard. I haven't figured out a way to preserve the credentials between sessions. (In any case, some folks might feel squiggy about saving credentials on a relatively insecure system. I know I do for some.)

3. In general, the sign-in processes are tuned to modern Internet Security practices. For example, my trial Youtube Music account is tied to my Google account which entails 2FA. Things get messy.

4. I thought the Youtube Music layout looked good and worked well with the touch-screen size and aspect ratio. Spotify seemed, well, a bit more fiddly.

5. I haven't found Google documentation which clearly states the variables involved with alsa device selection. Some search hits (StackOverflow, for example) suggest using an environmental variable ALSA_CONFIG_PATH to redirect to a different alsa.conf file. That's an alsa-project variable and I don't know how to use it in the moOde context. Other hits suggest using an undocumented Chromium-Browser startup switch --alsa-output-device.[1] The syntax seemed to be (to use second alsa card for example):

Code:

chromium-browser ... --alsa-output-device=hw:1,0

That's not working for me; I'm still getting output from card 0, the headphone jack, even when I try enclosing the value in quotes --alsa-output-device="hw:1,0" Indeed, I can use the local browser to play YouTube Music to card 0 while using the moOdeUI on a remote browser to play a radio station to my preset selection: card 1.

I've also seen a different syntax suggested for this option but I believe it was based on using PulseAudio.

Perhaps I'm missing something simple but I've confessed before that the whole ALSA subsystem is a mystery to me.

Regards,
Kent

[1] This switch shows up in Peter Beverloo's wonderful list, of course, but with no syntax suggested.