Contrary to claims in the commit message, it introduces an extra memory
copy of all audio samples for no apparent reasons.
This reverts commit 0bdc7268dc.
Instead of AudioSystem.getOutputLatency().
That way, we are sure the get the latency of the current output device.
Note: both methods are hidden and should not be used in favor or
AudioTrack.getTimestamp(). Unfortunately, getTimestamp() returns a valid
timestamp too late (after few seconds) or doesn't work with some phones.
Therefore, the usage of the hidden API is still needed as a backup plan.
cf. https://github.com/google/ExoPlayer/issues/5763
The android team allow the usage of this hidden API, waiting for a new
method in next Android versions.
If "--volume-save" == false, then the volume is set from Open(),
therefore a gain is requested causing the vlc_mutex_assert() in
aout_GainNotify().
The gain should be notified from any aout callbacks, but not from the
Open().
After a mute it seems we need to tell report the new volume otherwise it
assumes it's 0.
We keep the gain so we can compute the proper volume to report on mute.
When starting deferred (likely), ca_Render() is filling the output
buffer with 0s (silence) until the requested start time is reached. When
the host time is near the requested start time, the output buffer is
partially filled with 0s, and partially filled with valid data.
In that particular case, the output buffer offset was not updated
causing the valid data to be copied at the beginning of the output
buffer, leaving some uninitialized data at the end of the buffer.
Fixes#25142
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
The computation was leading to very high render_delay (for example in
some measurement, render_delay = 6148914691236500), and so glitch during
playback with for instance the following warnings:
libvlc video output warning: picture is too late to be displayed
(missing 4279998112535367 ms)
Instead, use int64_t for computations. Unsignedness is kept for
computation on frames / bytes and for storing the initial host_time.
This caused a freeze as the aout returned infinite values from time_get() with
SPDIF output.
Indeed, the inNow time is in the past (time when the callback is executed) and
a substraction with mach_absolute_time() returned a negative value.
The issue is revealed by 303d12153f but the
SPDIF host time had always been wrong.
See the API https://docs.microsoft.com/en-us/windows/win32/api/mmdeviceapi/nf-mmdeviceapi-activateaudiointerfaceasync
It requires a recent mingw-w64 with the added API.
We request the IAudioClient asynchronously and return the found client or NULL
once the async call as completed.
The code originates from the vlc-winrt project with some modifications.
Do not rely anymore on the local "winstore-client" variable to cache the
IAudioClient. A client is queried/used between each Start/Stop calls.
After a flush, i_first_render_host_time is reset to 0 and i_render_host_time
should not be touched since the playback has not started again yet. This caused
the i_first_render_host_time to be never setup.
Regression from f9fce13591Fixes#24876
The timer API is not supported in Winstore builds so switch to something that
works for all.
The timer (thread based) is created once and armed/disarmed when needed.
The render host time was not updated while paused.
This caused the first time_get(), after a unpause, to return a delay way too
early (corresponding to the pause time). This could happen only when the ca
render callback was not triggered between an unpause and a time_get.
This invalid delay caused the insertion of a long silence, that was not
interruptible, hence the impression of a deadlock.
Fixes#24668
Remove AudioUnit framework as it is not found on iOS and only
AudioToolbox is needed.
In addition CoreServices cannot be linked for the iOS/tvOS targets as it
is available starting with iOS/tvOS 12.0+.
As MONOTONIC is defined by POSIX to be the one that ticks during sleep while
mach absolute time does not.
For now (and for 3.0) vlc_tick_now() has the same source than the mach one.
SLresult is defined as an SLuint32 and might not be represented as an
unsigned long int. It is raising warnings when compiling for android
aarch64, so cast it to ensure it's an uint32_t and display it with
PRIu32 instead.
block_t->i_buffer is size_t too and must be displayed with %zu.
