| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
This change helps avoiding conflict with talloc.h from libtalloc.
|
|
|
|
| |
Replace with the more general mp_tag_str().
|
|
|
|
|
|
| |
Note that hresult_to_str() (coming from wasapi_explain_err()) is mostly
wasapi-specific, but since HRESULT error codes are unique, it can be
extended for any other use.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is another attempt at making files with sparse video frames work
better.
The problem is that you generally can't know whether a jump in video
timestamps is just a (very) long video frame, or a timestamp reset. Due
to the existence of files with sparse video frames (new frame only every
few seconds or longer), every heuristic will be arbitrary (in general,
at least).
But we can use the fact that if video is continuous, audio should also
be continuous. Audio discontinuities can be easily detected, and if that
happens, reset some of the playback state.
The way the playback state is reset is rather radical (resets decoders
as well), but it's just better not to cause too much obscure stuff to
happen here. If the A/V sync code were to be rewritten, it should
probably strictly use PTS values (not this strange time_frame/delay
stuff), which would make it much easier to detect such situations and
to react to them.
|
|
|
|
|
|
|
| |
It existed for XP-compatibility only. There was also a time where
ao_wasapi caused issues, but we're relatively confident that ao_wasapi
works better or at least as good as ao_dsound on Windows Vista and
later.
|
|
|
|
|
| |
All the wasapi files were including both ao_wasapi.h and ao_wasapi_utils.h.
Just merge them into a single file.
|
|
|
|
| |
This is something else that has nothing to do with audio rendering.
|
|
|
|
| |
this function was removed earlier, but the prototype was missed
|
|
|
|
| |
This makes it clearer that state->device is being allocated.
|
|
|
|
| |
In attempt to simplify the audio event thread, this can now be moved out.
|
|
|
|
|
| |
If these error conditions are triggered, the called function will have already
output a sufficiently informantive error message.
|
|
|
|
|
| |
In get_device_desc, don't alloc the return value until we know there
wasn't an error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Normally, PulseAudio accepts any combination of sample format, sample
rate, channel count/map. Sometimes it does not. For example, the channel
rate or channel count have fixed maximum values. We should not fail
fatally in such cases, but attempt to fall back to a working format.
We could just send pass an "unset" format to Pulse, but this is not too
attractive. Pulse could use a format which we do not support, and also
doing so much for an obscure corner case is not reasonable. So just pick
a format that is very likely supported.
This still could fail at runtime (the stream could fail instead of going
to the ready state), but this sounds also too complicated. In
particular, it doesn't look like pulse will tell us the cause of the
stream failure. (Or maybe it does - but I didn't find anything.)
Last but not least, our fallback could be less dumb, and e.g. try to fix
only one of samplerate or channel count first to reduce the loss, but
this is also not particularly worthy the effort.
Fixes #2654.
|
|
|
|
|
|
|
| |
pa_format_info_valid() does not do this. (Although there is a proposed
patch on the PulseAudio mailing list.)
See #2654.
|
|
|
|
| |
No real functional changes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Given 5.1(side), this lets it pick 5.1 from [5.1, 7.1]. Which was
probably the original intention of this replacement stuff. Until now,
the opposite was done in some cases.
Keep the old heuristic if the replacement is not perfect. This would
mean that a subset of the channel layout is an inexact equivalent, but
not all of it.
(My conclusion is that audio output APIs should be designed to simply
take any channel layout, like the PulseAudio API does.)
|
|
|
|
|
| |
Rather than creating a new string from the device instance. This will allow
moving the change_init to the main thread before the device is loaded.
|
| |
|
|
|
|
| |
This is no longer required by anything else
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unify and clean up listing and selection. Use common enumerator code for both
operations to avoid duplication or inconsistencies.
Maintain, but significatnly simplify manual device selection by id, name or
number. This actually fixes loading by name which didn't really work before
since the "name" displayed by --audio-device=help differed from that used to
match the selection, which used the device "description" instead.
Save the selected deviceID in the private structure for later loading. This will
permit moving the device selection into the main thread in a future commit.
|
|
|
|
|
|
|
|
| |
Apparently it's only wine where the qpc_position returned by
IAudioClock_GetPosition can be overflowed. So actually do the rescaling
correctly, but throw away the result if it looks unreasonable.
this fixes a regression in 5afa68835ade9f21f9c709f791319bf9d2e35265
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make sure that subtraction of performance counters is done correctly.
Follow the *exact* instructions for converting performance counter to something
comparable to the QPCposition returned by IAudioClient::GetPosition
https://msdn.microsoft.com/en-us/library/windows/desktop/dd370889%28v=vs.85%29.aspx
Also make sure that subtraction of unsigned integers is stored into a signed
integer to avoid nastiness. Also be more careful about overflow in the
conversion of the device position into number of samples.
Avoid casting mp_time_us() to a double, and use llrint to convert the
double precision delay_us back to integer for ao_read_data.
Finally, actually check the return value of ao_read_data and add a verbose
message if it is not the expected value. Unfortunately,
there is no way to tell WASAPI when this happens since the frame_count in
ReleaseBuffer must match GetBuffer.
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
| |
also make failure non-fatal
|
|
|
|
|
| |
In particular, try and release/null the interface so that it won't be
marshalled.
|
|
|
|
|
| |
Also make sure that CoReleaseMarshalData is called if errors occur before
unmarshalling.
|
|
|
|
|
| |
also remove a log message in AOCONTROL_UPDATE_STREAM_TITLE since
none of the other controls have one.
|
| |
|
|
|
|
| |
this was only ever used for a verbose message
|
| |
|
|
|
|
|
| |
IUnknown_Release() might be alright, but stay on the safe
side.
|
|
|
|
|
| |
Make sure that the proxy has been created before using it. This will be
used when a future commit makes proxy setup optional.
|
|
|
|
|
|
|
|
|
| |
Do not try and set/get master volume in exclusive if there is no
hardware support. This would just uselessly change the master slider,
but have no effect on the actual volume.
Furthermore if getting hardware volume support information fails, then assume
it has none.
|
|
|
|
|
| |
the ao_control_vol_t cast was happening outside AOCONTROL_GET/SET_VOLUME
which is the only place that would be valid
|
|
|
|
|
|
| |
It was complicated and not even very intuitive to the user.
If you are controlling the master volume, you just have to be
prepared to deal with the consequences.
|
|
|
|
|
| |
this avoids having to check if we're exclusive or
shared for every control
|
|
|
|
| |
this is encountered trying to set up COM proxies in wine
|
|
|
|
|
|
|
|
| |
A manually added af_volume could lead to muted audio when switching to a
new file. af_volume keeps the last volume set by AF_CONTROL_SET_VOLUME
to return it with AF_CONTROL_GET_VOLUME, but the initial value is 0. So
the mixer volume was forced to 0 when unintializing the filter chain and
reading back the previously set volume.
|
|
|
|
| |
(Why is this code so complex?)
|
|
|
|
|
|
|
|
|
|
|
| |
If there were many AO drivers without device selection, this added a
"Default" entry for each AO. These entries were not distinguishable, as
the device list feature is meant not to require to display the "raw"
device name in GUIs.
Disambiguate them by adding the driver name. If the AO is the first, the
name will remain just "Default". (The condition checks "num > 1",
because the very first entry is the dummy for AO autoselection.)
|
|
|
|
|
|
|
| |
Of course, only FFmpeg has av_clipd(), while Libav does not. (Nevermind
that it doesn't do much more than the mpv MPCLAMP() macro. Supposedly,
libavutil can provide optimized platform-specific versions for av_clip*,
but of course nothing actually does for av_clipf() or av_clipd().)
|
|
|
|
|
|
|
| |
libswresample doesn't do it - although it should, but the patch is stuck
in limbo.
Probably reduces problems with artifacts on downmixing in some cases.
|
|
|
|
|
|
|
|
| |
Remove known useless device entries from the --audio-device list (and
corresponding property). Do this because the list is supposed to be a
high level list of devices the user can select. ALSA does not provide
such a list (in an useable manner), and ao_alsa.c is still in the best
position to improve the situation somewhat.
|
|
|
|
|
|
|
|
|
| |
The ALSA doxygen says:
IOID - input / output identification ("Input" or "Output"), NULL
means both
This bug was blatantly introduced with commit cf94fce4.
|
|
|
|
|
| |
This was required to work around XP linking issues and is no longer
required.
|
|
|
|
|
| |
otherwise we were incorrectly adjusting the hardware master volume
in exclusive mode with softvol=auto
|
|
|
|
|
|
|
|
|
|
| |
Apparently, some audio drivers do not support the DTS subtype, but
passthrough works anyway if the AC3 subtype is set. Just retry with
AC3 if the proper format doesn't work. The audio device which
exposed this behavior reported itself as
"M601d-A3/A3R (Intel(R) Display Audio)".
xbmc/kodi even always passes DTS as AC3.
|
| |
|
|
|
|
|
|
| |
Place speakers in standard positions equidistant from the listener.
use standard coordinate system
|
|
|
|
|
|
| |
Try and and choose the closest sample format to the one requested.
fixes #2494
|
|
|
|
| |
the next commit will use uninit within init
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just set the ratio directly by working around the intended semantics of
the API function. The silly rounding stuff we had isn't needed anymore
(and not entirely correct anyway).
Note that since the compensation is virtually active forever, we need to
reset if it's not needed. So always run this code to be sure to reset
it.
Also note that libswresample itself had a precision issue, until it
was fixed in FFmpeg commit 351e625d.
|
|
|
|
| |
Was masked by FFmpeg's terrible headers, but failed with Libav.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Deal with jittering Matroska crap timestamps. This reuses the mechanism
that is needed for frames without PTS, and adds a heuristic to it. If
the interpolated timestamp is less than 1ms away from the real one, it
might be due to Matroska timestamp rounding (or other file formats with
such rounding, or files remuxed from Matroska).
While there actually isn't much of a need to do this (audio PTS
jittering by such a low amount doesn't negatively influence much), it
helps with identifying jitter from other sources.
|
|
|
|
|
|
|
| |
Instead of requiring the decoder to set the PTS directly on the
dec_audio context (including handling absence of PTS etc.), transfer the
packet PTS to the decoded audio frame. Marginally simpler, and gives
more control to the generic code.
|
|
|
|
| |
Unused; last uses removed with the previous two commits.
|
|
|
|
|
| |
Same deal as with previous commit. "waveext" is less arbitrary and at
least supports 3/7 channels.
|
|
|
|
|
|
|
|
| |
Essentially we'd use something random, just because it's part of the srt
of traditionally used ALSA channel mappings. But each driver can do its
own things.
This doesn't let me sleep at night, so remove it.
|
|
|
|
|
|
|
|
|
| |
This could accidentally change some spdif formats to AAC (because AAC is
the first on the list and will match first). spdif formats are
inherently uninterchangeable, so treat them as their own class of
formats (like int vs. float).
Might fix some issues with ao_wasapi.c.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Actually, it didn't really require that before (most work was avoided),
but some bits had to be run anyway. Separate the speed change into a
light-weight function, which merely updates already created filters, and
a heavy-weight one which messes with filter insertion.
This also happens to fix the case where the filters would "forget" the
current speed (force resampling, change speed, hit a volume control to
force af_volume insertion - it will reset speed and desync).
Since we now always run the light-weight function, remove the
af_scaletempo verbose message that is printed on speed setting. Other
than that, all setters are cheap.
|
|
|
|
|
|
| |
For some reason, the encoder didn't like that the AVPacket already had
fields set. I'm not quite sure, but this might just be invalid API
usage. Do it as it's recommended.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to effectively swap the last channel pair. See commit 4e358a96
and 5a18c5ea for details.
Doing this seems rather strange, as 7.1 just extends 5.1 with 2 new
speakers, and 5.1 doesn't need this change. Going by the HDMI standard
and the Intel HDA sources (cited in the referenced commits), it also
looks like 7.1 should simply append two channels to 5.1 as well. But
swapping them is apparently correct. This is also what XBMC does. (I
didn't find any other applications doing 7.1 PCM using the ALSA channel
map API. VLC seems to ignore the 7.1 case.) Testing reveals that at
least the end result is correct.
"Normal" ALSA 7.1 is unaffected by this, as it reports a different
(and saner) channel layout.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of constructing an ALSA channel map from mpv ones from scratch,
try to find the original ALSA channel map again. Th result is that we
need to convert channel maps only in one direction. If we need to map
a mp_chmap to ALSA, we fetch the device's channel map list, convert
each entry to mp_chmap, and find the first one which fits.
This seems helpful for the following commit. For now, this only gets rid
of mapping back the trivial MONO mapping, which alone would still be
acceptable, but with other channel layout mogrifications it gets messy
fast. While we need to do something awkward to keep our channel map
reordering for VAR chmaps (which basically gives nicer output and
possibly slightly better performance), this is still the better
solution.
|
| |
|