4 is the "typical" number of buffers defined by Android's OpenSL ES
implementation, and its code is optimized for this. Also because we
have our own ringbuffer around this, we will always have enough
buffering on our side already.
Allows for more efficient processing.
We need to sleep a bit before destroying the player object
because of a bug in Android in versions < 4.2.
OpenSLES is using AudioTrack for rendering the sound. AudioTrack
has a thread that pulls raw audio from the buffer queue and then
passes it forward to AudioFlinger (AudioTrack::processAudioBuffer()).
This thread is calling various callbacks on events, e.g. when
an underrun happens or to request data. OpenSLES sets this callback
on AudioTrack (audioTrack_callBack_pullFromBuffQueue() from
android_AudioPlayer.cpp). Among other things this is taking a lock
on the player interface.
Now if we destroy the player interface object, it will first of all
take the player interface lock (IObject_Destroy()). Then it destroys
the audio player instance (android_audioPlayer_destroy()) which then
calls stop() on the AudioTrack and deletes it. Now the destructor of
AudioTrack will wait until the rendering thread (AudioTrack::processAudioBuffer())
has finished.
If all this happens with bad timing it can happen that the rendering
thread is currently e.g. handling underrun but did not lock the player
interface object yet. Then destroying happens and takes the lock and waits
for the thread to finish. Then the thread tries to take the lock and waits
forever.
We wait a bit before destroying the player object to make sure that
the rendering thread finished whatever it was doing, and then stops
(note: we called gst_opensles_ringbuffer_stop() before this already).
The OpenSL ES spec defines:
An implementation shall enable creation of at least one such object, but
attempting to create more instances (either by a single application or by
several different applications) may fail.
OpenSL ES implementation in Android is just a 'facade' API on top of
AudioFlinger which will downsample 48kHz into 44.1kHz before
delivering the audio to the underlaying hardware.
We found that it suffer some sort of underrun when the downsample
enters in action so relay on our good resampler to take care of that
and fix the clicks issue. And get an extra bonus of a lower latency.
Make the segments bigger (1 second) as it seems to be the minimum size
we need to not introduce noise.
Sink works in my nexus 7 with rates from 8000 to 44100 and some noise
can be noticed on higger sample rates.
Add some log messages.
Fixed a bit the _player_cb function and properly advance reding in the
ringbuffer.
Still produces noise when the ringbuffer wraps.
