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
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
|
; This is an example configuration file that illustrates
; the structure of the configuration.
; It doesn't show all possible options. A more detailed example
; is available in doc/advanced.mux
;
; It contains two services, one DAB and one DAB+, and also shows
; both the file input useful for offline processing, and the
; ZeroMQ input useful in a 24/7 scenario.
; More information about the usage of the tools is available
; in the guide, which can be found on the
; www.opendigitalradio.org website.
;
; As you can see, comments are defined by semicolons.
;
; It consists of six mandatory sections, whose relative order in this
; file are of no importance.
; The general section defines global multiplex parameters.
general {
; the DAB Transmission mode (values 1-4 accepted)
dabmode 1
; the number of ETI frames to generate (set to 0 to get an unlimited number)
nbframes 10
; boolean fields can accept either false or true as values:
; Set to true to enable logging to syslog
syslog false
; Enable timestamp definition necessary for SFN
; This also enables time encoding using the MNSC.
tist false
; The management server is a simple TCP server that can present
; statistics data (buffers, overruns, underruns, etc)
; which can then be graphed a tool like Munin
; The doc/stats_dabmux_multi.py tool is a suitable
; plugin for that.
; If the port is zero, or the line commented, the server
; is not started.
managementport 12720
}
remotecontrol {
; enable the telnet remote control server on the given port
; This server allows you to read and define parameters that
; some features export. It is only accessible from localhost.
; Set the port to 0 to disable the server
telnetport 12721
; the remote control server makes use of the unique identifiers
; for the subchannels, services and components. Make sure you
; chose them so that you can identify them.
}
; Some ensemble parameters
ensemble {
id 0x4fff ; you can also use decimal if you want
ecc 0xec ; Extended Country Code
local-time-offset auto ; autmatically calculate from system local time
; or
;local-time-offset 1 ; in hours, supports half-hour offsets
; all labels are maximum 16 characters in length
label "OpenDigitalRadio"
; The short label is built from the label by erasing letters, and cannot
; be longer than 8 characters. If omitted, it will be truncated from the
; label
shortlabel "ODR"
}
; Definition of DAB services
services {
; Each service has it's own unique identifier, that is
; used throughout the configuration file and for the RC.
srv-fu {
id 0x8daa
label "Funk"
; you can define a shortlabel too.
}
srv-ri {
id 0x8dab
label "Rick"
}
}
subchannels {
sub-fu {
; This is our DAB programme, using a file input
type audio
inputfile "funk.mp2"
bitrate 128
id 10
protection 3
}
sub-ri {
; This is our DAB+ programme, using a ZeroMQ
type dabplus
; Accepts connections to port 9000 from any interface.
; Use FDK-AAC-DABplus as encoder
inputfile "tcp://*:9000"
bitrate 96
id 1
protection 3
; ZMQ specific options, mandatory:
; Maximum size of input buffer, in AAC frames (24ms)
; when this buffer size is reached, some frames will be
; discarded to get the size again below this value.
; As the present implementation discards entire AAC superframes,
; (5 frames = 120ms) the effect will clearly be audible.
zmq-buffer 40
; At startup or after an underrun, the buffer is filled to this
; amount of AAC frames before streaming starts.
zmq-prebuffering 20
; In an ideal scenario, where the input rate exactly corresponds
; to the rate at which the frames are consumed by dabmux, you
; see the buffer level staying around the zmq-prebuffering value.
; Network latency jitter can make it temporarily go lower or higher.
; Encoder clock drift will make the buffer either slowly fill or
; empty, which will create intermittent glitches.
}
}
; In our simple example, each component links one service to one subchannel
components {
; the component unique identifiers are used for the RC.
comp-fu {
; According to specification, you should not define component labels if
; the service is only used in one component. The service label is sufficient
; in that case.
service srv-fu
subchannel sub-fu
}
comp-ri {
service srv-ri
subchannel sub-ri
}
}
; A list of outputs
outputs {
; The unique-id can be used by the remote control or the statistics server
; to identify the output
; Output RAW ETI NI to standard output
stdout "fifo:///dev/stdout?type=raw"
; ZeroMQ output example
; This output does not back-pressure the multiplexer.
; Listen on all interfaces, on port 9100
;zmq "zmq+tcp://*:9100"
; Output ETI-over-TCP. This is like piping a RAW ETI NI data stream
; into a TCP socket, except that the output can handle simultaneous
; connections.
; 0.0.0.0 means "listen on all interfaces"
; This output does not back-pressure the multiplexer.
;tcp "tcp://0.0.0.0:9200"
; Throttle output to real-time (one ETI frame every 24ms)
;throttle "simul://"
; Important! For real-time operation, you need to have exactly one
; output that applies back-pressure to ODR-DabMux, otherwise it will run
; at the highest possible rate on your system!
;
; For an output to a pipe, the data consumer at the other end of the pipe
; will dictate the multiplexing rate to ODR-DabMux.
;
; If you use the zmq+tcp:// or the tcp:// output,
; you must also enable a simul:// output!
}
|
