I have bluetooth configured and working as per this thread:
My usage case is a bit unusual, maybe a bit of a niche:
My RPI 3b is running OSMC and also acting as a snapcast server (and client, although it’s muted 99% of the time). I would like to be able to send the bluetooth input to snapcast - is it possible to redirect bluetooth to a FIFO or stdout without affecting Kodi’s audio output?
Are you directing Kodi’s output to snapcast, then? If so, I guess snapcast appears as a ALSA device and you could simply direct blue-alsa-aplay to that by redefining snapcast as pcm.!default.
If snapcast isn’t fed through ALSA, things will be more complicated. You could have a look on bluez-alsa’s github where you will find a few other ‘niche’ cases that may help.
I wasn’t clear, I think. I don’t want to send Kodi’s output to snapcast, just the A2DP sink. I don’t have any music configured in Kodi, just video.
I was able to get it working as I had wanted to over the weekend - so in case it comes up for anybody else, it was a three step process:
source = pipe:///tmp/bluefifo?name=Bluetooth
pcm.bluetooth {
type plug
slave.pcm rate48000Hz
}
pcm.rate48000Hz {
type rate
slave {
pcm writeFile # Direct to the plugin which will write to a file
format S16_LE
rate 48000
}
}
pcm.writeFile {
type file
slave.pcm null
file "/tmp/bluefifo"
format "raw"
}
[Unit]
Description=A2DP Playback
After=bluealsa.service syslog.service
Requires=bluealsa.service
StopWhenUnneeded=true
[Service]
ExecStartPre=/bin/sleep 3
ExecStart=/usr/bin/bluealsa-aplay -D bluetooth --profile-a2dp 00:00:00:00:00:00
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=A2DP-Playback
Restart=on-failure
[Install]
WantedBy=bluetooth.target
I suppose if you’re not also running the snapcast client on the OSMC system you could just define the pcm device as the default device (pcm.!default instead of pcm.bluetooth) and then you wouldn’t have to edit the service file. But in my case I am, and that worked up to a point. As soon as I unmuted the snapcast client on the OSMC system it fed its output right back into the named pipe which made things interesting to say the least. Defining another pcm device worked around that issue.
None of this seems to affect OSMC’s audio output in any way.
This no longer works quite right with the 2021.08-1 release. On Kodi 18.9 I had these options for the Audio Output Device:
ALSA: DEFAULT (BCM2835 ALSA BCM2835 ALSA)
ALSA: BLUETOOTH
ALSA: RATE48000HZ
ALSA: WRITEFILE
ALSA BCM 2835 ALSA, BCM 2835 ALSA
PI: HDMI
PI: ANALOGUE
PI: HDMI AND ANALOGUE
With the Kodi output set to PI: HDMI.
Now in Kodi 19.1, my stock audio output devices are as follows:
DEFAULT (VC4-HDMI MAI PCM VC4-HDMI-HIFI-0)
VC4-HDMI, MAI PCM VC4-HDMI-HIFI-0
VC4-HDMI, VIZ E472VLE on HDMI
And with the /etc/asound.conf file above (or with ~/.asoundrc), my options are as follows:
BLUETOOTH
RATE48000HZ
WRITEFILE
None of those, of course, send any audio out via HDMI. So it’s pretty clear that the asound.conf file is just overriding everything else. Not quite sure how to proceed here, although for the time being I’ve just deleted the asound.conf file. Were the PI outputs listed in 18.9 something to do with PulseAudio?
Do you mean HDMI disappears? That can’t be right.
No. With 18.9 the Pi exposed it’s audio devices direct and also through an ALSA driver. With 19.1, we have only ALSA. The only way I can think that HDMI would disappear is if you had overriden the default device. You know all about that as you described it above (although I’ve failed here to reassign default to another card using pcm.!default).
And I can’t reproduce what you are seeing:
Further information - on a fresh instance of OSMC I was able to get the outputs looking like I wanted. I could see the stock VC4-HDMI outputs and the Bluetooth output(s). But after I played audio via bluetooth the VC4 outputs would vanish.
From what I can gather, it must have only worked in 18.9 because the Pi was directly exposing the outputs and thus Kodi was bypassing ALSA. Is it possible to force the Pi to do that now?
