Mopidy as Mumble music bot

I understand you may already have e.g. Navidrome or Jellyfin on your local network and may be annoyed by having to install "yet another" media server.

A bit of explanation of why we're using Mopidy instead of e.g. Subsonic:

Mopidy plays audio to a local, hardware audio output by default. However, you don't want to hear audio through on the built-in speakers of your server where Mopidy will be running. You want sound to be heard in a channel on your Mumble server.

This section focuses only on the basics:

1. Installing Mopidy and a web UI for it
2. Getting it to download and play audio from youtube videos
3. Playing the youtube video's audio to your local headphones or speakers

In further sections, you'll learn how to broadcast Mopidy's audio output to the network and get Mumble to consume that audio stream.

I recommend following the below instructions on your personal computer first. When you are sure everything is working - move the setup to your server.

[file]
enabled = true
media_dirs = /path/to/folder/containing/music/files

pip install Mopidy-Youtube # this is how I install mopidy-youtube, if you used another way, skip this
pip install yt-dlp

[youtube]
enabled = true
youtube_dl_package = yt_dlp
# yt_dlp with an underscore, not with a dash

Currently Mopidy should be only playing audio to your local headphones or speakers.

In this section, you'll move one step closer to playing your music in Mumble - you'll take Mopidy's audio output and broadcast it on your network, so other applications can do something with the audio. One such application could be … a Mumble bot that'd listen to the audio you are broadcasting and play it back in Mumble. wink wink wink in the section after this one cough

Streaming to the network is really easy to set up (once you have the code handed to you on a silver plattter haha). There's only one step - modify your ~/.config/mopidy/mopidy.conf like this:

[audio]
output = audioconvert ! audio/x-raw,format=S16LE,rate=48000,channels=2 ! udpsink host=127.0.0.1 port=5004

The syntax is a bit uncommon, but this is how you write gstreamer pipelines. There's an example of gstreamer syntax on the Mopidy wiki too.

Basically, the above snippet does this:

1. Takes the raw audio played by Mopidy
2. Converts it to a format that the Python library for interacting with Mumble servers supports - see add_sound here
3. Broadcasts it on your network using UDP

Now that you have an audio stream being broadcasted on your network, you just need a bot that'll listen to that stream and play it back in your Mumble's server channel as if it were "speaking".

I have to thank user bitconnector from github for writing this example of a music bot that plays a local audio file in a Mumble channel. I wouldn't have figured out how to do this without it.

  import socket
  import time
  import subprocess as sp
  import pymumble_py3

  UDP_IP = "127.0.0.1"
  UDP_PORT = 5004
  sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

  # REMEMBER TO CHANGE THE IP HERE TO YOUR MUMBLE SERVER'S IP
  # If your server needs a passsword to connect to it, use the password= argument
  # If your server uses a port different than the Mumble default of 64738, use the port= argument and pass the port as a number
  mumble = pymumble_py3.Mumble('93.184.216.34', 'mopidyplayer', stereo=True, reconnect=True)
  mumble.set_codec_profile('audio')
  mumble.start()
  mumble.is_ready()   #wait for Mumble to get ready to avoid errors after startup
  mumble.set_bandwidth(192000)

  sock.bind((UDP_IP, UDP_PORT))

  while True:
      while True:
	  raw_music, addr = sock.recvfrom(65507)
	  if not raw_music:
	      break
	  mumble.sound_output.add_sound(raw_music)

      while mumble.sound_output.get_buffer_size() > 0.5:  #
	  time.sleep(0.01)
      time.sleep(2)

• Why not just implement a Mopidy-Mumble extension than go through all this…
• There are probably smarter/lower latency way of broadcasting the audio packets from the Mopidy gstreamer pipeline.
  I'm just using raw UDP but there's also RTP , WebRTC and so on.
  \\ RTP can be done using the rtpL16pay pipeline component in gstreamer in Mopidy. It outputs only big endian S16BE so you'd need to swap the endianness on the Python script side, using raw_music[::-1], because pymumble only takes S16LE little endian.

Instead of streaming audio directly from Mopidy's [audio] output to the Mumble bot like I've shown above, you might've come across Mopidy's wiki recommendation:

If you want to play the audio on another computer than the one running Mopidy, you can stream the audio from Mopidy through an Icecast audio streaming server.

Unfortunately, audio streamed from Icecast will have a lot of delay. When you press "Play" in the web UI, you'll hear sound in Mumble after a couple of seconds, instead of instantly. Same if you stop the playback. The delay makes listening to things in Mumble rather unenjoyable.

Here's what Thomas B. Ruecker - one of the Icecast maintainers - has to say on the topic (source, accessed at 2023-06-25):

Don't use Icecast if you need sub-second latency!

Don't use Icecast if you need sub-10-second latency and don't have full control over the whole chain of software and network!

Yes, this is an answer, not a comment. Icecast is not designed for such use cases. It was designed for 1-to-n bulk broadcast of data over HTTP in non-synchronized fashion.

What you are explaining sounds like you really should consider something that was designed to be low latency, like web-RTC.

If you think you really should use Icecast, please explain why. Because your question speaks otherwise. I'm all for more Icecast use, I'm it's maintainer after all, but its application should make sense.

Additionally, streaming audio directly from Mopidy's [audio] output is also simpler, because you need to only set up Mopidy and the Mumble bot. Here you need Icecast in addition. Nonetheless, I used Icecast for this purpose for a while. If for some reason you need to too, some instructions are below.