The AudioTrack for playing audio from the child device
was sending audio to the voice call stream. It is more
appropriate to use the music stream. In addition, suggest
that the activity control the music stream's volume with
the hardware controls.
Whenever a sample is received from the socket, pass it to
the AudioPlayer thread via a blocking queue. The AudioPlayer
thread will then play the sample and wait for more input.
This thread will be used for playing audio samples. The samples
will be provided by a blocking queue.
It is assumed that the configuration of the passed AudioTrack and
the samples from the blocking queue are compatible.
Attempt to discover any providers of the ProtectBabyMonitor
service on the local network, resolving any which are found.
For now nothing is done with the information on found
providers.
If the send buffer size is large and the receiver is unable
to keep up, then audio samples will collect on the monitor
and lag will accumulate. As only the most recent sample is
important, reduce the send buffer size to the minimum
AudioRecord buffer size.
If a client connects to the advertised ProtectBabyMonitor service,
attempt to service the connection.
For now, simply close the connection instead of sending data.
When the MonitorActivity is started it will create a ServerSocket.
The assigned port is then advertised over mDNS for a
"ProtectBabyMonitor" service.
Eventually, when something connects to the ServerSocket audio
data will be streamed out.
This commit adds the shell of the MonitorActivity. This activity
will register its service on the local network, wait for a connection,
then send audio data.
The StartActivity is the first activity which will be launched
in the baby monitor, and in the future will list the two main
options: become a monitor or a listener.
