The additional thread to feed the AudioTrack was unnecessary.
Because the AudioTrack API is blocking when data is written,
and internally it buffers data, writing the data as soon
as it is received from the network leads to better playback
performance. It is also much simpler.
The previous approach was to list buttons in a TableLayout.
However, this approach does not work well if there are more
items than can fit on the screen.
To allow scrolling of items, and also a better presentation
of said items, use a ListView.
If the child device disconnects unexpectedly, alert the
user, in case they were not expecting the disconnect.
The audio file being played is originally from here:
https://freesound.org/people/pan14/sounds/263655/
Previously the monitor activity would only support one connection,
after which the activity would need to be restarted. With this change,
if a connection is established with a parent device but is eventually
disconnected the child device will begin advertising again.
Note that because the child device can only support one connection
at a time currently, after the connection is established it will
now stop advertising. When a connection is lost and advertising
starts again, it may end up advertising as another service. E.g.
ProtectBabyMonitor (2)
instead of
ProtectBabyMonitor
If the screen is rotated by default Android destroys the
activity and recreates it. This causes issues if a child and
parent are already paired, as the connection is lost.
To prevent Android from destroying the Activity, instead
invoke a configuration change on an orientation or resize.
If the screen turns off, the child device will be unable to
record from the microphone. Keep the screen on in the monitor
activity to keep microphone on.
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.
