1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
|
.. _concepts:
************
Architecture
************
The overall architecture of Mopidy is organized around multiple frontends and
backends. The frontends use the core API. The core actor makes multiple backends
work as one. The backends connect to various music sources. The core actor use
the mixer actor to control volume, while the backends use the audio actor to
play audio.
.. digraph:: overall_architecture
"Multiple frontends" -> Core
Core -> "Multiple backends"
Core -> Mixer
"Multiple backends" -> Audio
Frontends
=========
Frontends expose Mopidy to the external world. They can implement servers for
protocols like HTTP, MPD and MPRIS, and they can be used to update other
services when something happens in Mopidy, like the Last.fm scrobbler frontend
does. See :ref:`frontend-api` for more details.
.. digraph:: frontend_architecture
"HTTP\nfrontend" -> Core
"MPD\nfrontend" -> Core
"MPRIS\nfrontend" -> Core
"Scrobbler\nfrontend" -> Core
Core
====
The core is organized as a set of controllers with responsiblity for separate
sets of functionality.
The core is the single actor that the frontends send their requests to. For
every request from a frontend it calls out to one or more backends which does
the real work, and when the backends respond, the core actor is responsible for
combining the responses into a single response to the requesting frontend.
The core actor also keeps track of the tracklist, since it doesn't belong to a
specific backend.
See :ref:`core-api` for more details.
.. digraph:: core_architecture
Core -> "Tracklist\ncontroller"
Core -> "Library\ncontroller"
Core -> "Playback\ncontroller"
Core -> "Playlists\ncontroller"
Core -> "History\ncontroller"
"Library\ncontroller" -> "Local backend"
"Library\ncontroller" -> "Spotify backend"
"Playback\ncontroller" -> "Local backend"
"Playback\ncontroller" -> "Spotify backend"
"Playback\ncontroller" -> Audio
"Playlists\ncontroller" -> "Local backend"
"Playlists\ncontroller" -> "Spotify backend"
Backends
========
The backends are organized as a set of providers with responsiblity for
separate sets of functionality, similar to the core actor.
Anything specific to i.e. Spotify integration or local storage is contained in
the backends. To integrate with new music sources, you just add a new backend.
See :ref:`backend-api` for more details.
.. digraph:: backend_architecture
"Local backend" -> "Local\nlibrary\nprovider" -> "Local disk"
"Local backend" -> "Local\nplayback\nprovider" -> "Local disk"
"Local backend" -> "Local\nplaylists\nprovider" -> "Local disk"
"Local\nplayback\nprovider" -> Audio
"Spotify backend" -> "Spotify\nlibrary\nprovider" -> "Spotify service"
"Spotify backend" -> "Spotify\nplayback\nprovider" -> "Spotify service"
"Spotify backend" -> "Spotify\nplaylists\nprovider" -> "Spotify service"
"Spotify\nplayback\nprovider" -> Audio
Audio
=====
The audio actor is a thin wrapper around the parts of the GStreamer library we
use. If you implement an advanced backend, you may need to implement your own
playback provider using the :ref:`audio-api`, but most backends can use the
default playback provider without any changes.
Mixer
=====
The mixer actor is responsible for volume control and muting. The default
mixer use the audio actor to control volume in software. The alternative
implementations are typically independent of the audio actor, but instead use
some third party Python library or a serial interface to control other forms
of volume controls.
|
