| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
There is not much of a reason to have these wrappers around. Use POSIX
standard functions directly, and use a separate utility function to take
care of the timespec calculations. (Course POSIX for using this weird
format for time values.)
|
|
|
|
|
| |
The main reason for this was compatibility; but some associated problems
have been solved in the previous commit.
|
|
|
|
| |
Useful for debugging cases when no standard orders are used.
|
| |
|
|
|
|
|
| |
Remove the requirement from mp_chmap that speaker entries must be
unique. Use this to get rid of all the redundant NA speaker IDs.
|
|
|
|
|
| |
While mpv has no internal equivalent representation, they can still be
used as physical CoreAudio formats. Thus this label is confusing.
|
|
|
|
| |
(I won't do this, but someone else seeing this might.)
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes, ALSA will return channel layouts with padded channels (NA
speakers). Use them instead of failing.
This still includes the old "braindeath" code to retry with a layout
without NA channels. This might be helpful for performance, and also the
padded channel layout string looks confusing.
To be fair, I have not encountered a case yet which would really need
this, and for which the old "braindeath" code did not fix it.
|
|
|
|
|
| |
One side effect is that the warning about too many channels goes away,
and is replaced with printing the ALSA channel map as "unknown".
|
|
|
|
|
| |
It seems if the format was already set, setting the same format will
not cause a property change.
|
|
|
|
|
|
|
|
|
|
|
| |
volatile barely means anything.
The polling is kind of bad too, but relatively harmless as device
opening/closing is a rare event, and the format change is not expected
to take long.
Remove the pointless talloc call too (must have been a leftover
from previous refactoring).
|
|
|
|
| |
PCM is digital too.
|
| |
|
|
|
|
|
|
| |
No reason to keep them separate. It's an artifact from the old
ao_coreaudio.c, which kept usage of two different APIs in the same file.
Removes a forward reference too.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of trying to use af_format_conversion_score() (which tries to be
all kinds of clever), just compare the raw bits as a quality measure. Do
this because otherwise, weird formats like padded 24 bit formats will be
excluded, even though they might be the highest precision formats for
some hardware.
This means that for now, the user would have to check whether the format
is usable at all before calling ca_asbd_is_better(). But since this is
currently only used for ao_coreaudio.c and for the physical format, it
doesn't matter.
If coreaudio-exclusive should get PCM support, the best would be to
revert this change, and to add support for 24 bit formats directly.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Move all of the channel map retrieval/negotiation code to a separate
file. This will (probably) be helpful when extending
ao_coreaudio_exclusive.c.
Nothing else changes, other than some minor cosmetics and renaming,
and changing some details for decoupling it from the ao_coreaudio.c
internals.
|
|
|
|
|
| |
Instead, apply a trick to make the caller allocate enough space on the
stack.
|
|
|
|
|
|
| |
It appears this is the reason coreaudio-exclusive does not work without
explicitly specifying a device, even if the default device maps to
something passthrough-capable.
|
|
|
|
| |
Didn't use the properties it was supposed to use.
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of always picking a somehow better format over the previous one,
select a format that is equal to or better the requested format, but is
also reasonably close.
Drop the mFormatID comparison - checking the sample format handles this
already.
Make sure to exclude channel counts that can't be used.
|
|
|
|
|
|
| |
If for example the physical format is set to stereo, the reported
multichannel layout will actually be stereo. It fixes itself only after
the physical format is changed.
|
|
|
|
|
|
|
|
|
|
|
|
| |
ao_coreaudio uses AudioUnit - the OSX software mixer. In theory, it
supports multichannel audio just fine. But in practice, this might be
disabled by default, and the user is supposed to select a multichannel
base format in the "Audio MIDI Setup" utility.
This option attempts to change this setting automatically. Some possible
disadvantages and caveats are listed in the manpage additions. It is off
by default, since changing this might be rather bad behavior for a
normal application.
|
| |
|
|
|
|
|
|
|
| |
If for example the audio settings are set to 5.1 output, but the
hardware does 8 channels natively (HDMI), the reported channel
layout will have 2 dummy channels. To avoid falling back to stereo,
we have to write audio in this format to the device.
|
|
|
|
|
|
| |
ca_label_to_mp_speaker_id() checked whether the last entry was >= 0, but
actually this condition was never true, and MP_SPEAKER_ID_UNKNOWN0 is
not negative.
|
|
|
|
|
|
|
|
|
| |
This should for now be equivalent; it's merely more explicit and will
be required if we add PCM support.
Note that the property listeners actually tell you what property
exactly changed, but resolving the current listener mess would be too
hard. So check for changes manually.
|
|
|
|
| |
As a consequence, it also logs whether mpv can a this format at all.
|
|
|
|
|
|
|
|
|
|
| |
Useful with some of the following commits.
ca_fill_asbd() should behave exactly as before.
Instead of actually implementing the inverse function of ca_fill_asbd(),
just loop over the (small) list of mpv functions and check if any mpv
equivalent to a given ASBD exists.
|
|
|
|
|
|
|
|
|
| |
kAudioFormatFlagIsSignedInteger implicates that it's only used with
integer formats. The mpv internal flag on the other hand signals the
presence of a sign, and this is set on float formats.
Until now, this probably worked fine, because at least AudioUnit is
ignoring the uncorrect flag.
|
|
|
|
|
| |
Should be almost equivalent, unless there are streams on which this call
does not work for unknown reasons.
|
|
|
|
| |
Make it easier to distinguish the fields.
|
|
|
|
|
|
|
| |
Whether this is correct is unknown. This change tripples the latency
from ~15ms to ~45ms.
XBMC does this, VLC does not from what I could see.
|
| |
|
|
|
|
|
|
| |
mp_chmap_from_channels_alsa() doesn't always succeed - there are a bunch
of channel counts for which no defined ALSA layout exists. Fallback to
stereo in this case. (Normally, this code path shouldn't happen at all.)
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
| |
And also use the correct type for the printf call below.
|
|
|
|
|
|
|
|
| |
Silence the usually user-visible warning about unsupported channel maps.
This might be an ALSA bug, but ALSA will never fix this behavior anyway.
(Or maybe it's a feature.)
Log some other information that might be useful.
|
|
|
|
|
|
| |
The message log level shouldn't get to decide whether something fails
or not. So replace the fatal error check on the verbose output code
path with a warning.
|
|
|
|
|
|
|
|
|
| |
Unfortunately, because we have proxy objects (pAudioVolumeProxy,
pEndpointVolumeProxy, pSessionControlProxy) it looks like we still
have to use MsgWaitForMultipleObjects and watch for and dispatch
pending messages:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680112%28v=vs.85%29.aspx
|
| |
|
| |
|
|
|
|
|
| |
af_fmt_is_float and af_fmt_is_planar were previously inconsistent with
AF_FORAMT_IS_SPECIAL/AF_FORMAT_IS_IEC61937
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* unify passthrough and pcm exclusive mode format setting/testing
* set passthrough format parameters correctly
* support all of mpv's existing passthrough formats
* automatically test passthrough with exclusive mode and enable
exclusive if it succeeds, even if it was not explictly requested.
this obviates the need for --ao=wasapi,wasapi=exclusive
* if passthrough fails (such as the device doesn't support the
format), fallback to either exclusive pcm or shared mode depending
on what the user specified. Right now this isn't very useful as
it still fails due to the decoder path remainin stuck on spdif.
fixes #1742
|
| |
|
|
|
|
|
| |
CoreAudio doesn't seem to have this concept. The volume is reset the
next time audio is opened.
|
| |
|
|
|
|
|
|
|
|
|
| |
Take advantage of the fact that list_devs is called with a
hotplug_inited ao. Also eliminate unnecessary nested function
abstraction of hotplug_(un)init and list_devs. However, keep list_devs
in ao_wasapi_utils.c since it uses the private functions get_device_id,
get_device_name and exposing these would require including headers for
IMMDevice in ao_wasapi_utils.h.
|
|
|
|
|
| |
remove depricated and convoluted validation. refer instead to the
--audio-device option.
|
|
|
|
|
|
|
| |
Create a second copy of the change_notify structure for the hotplug
ao. change_notify->is_hotplug distinguishes the hotplug version from
the regular one monitoring the currently playing ao. Also make the
change notification less verbose now that there might be two of them around.
|
|
|
|
| |
This was requested, more or less.
|
|
|
|
|
| |
Rather than defining them ourselves. Thanks to rossy for figuring out
the headers.
|
| |
|
|
|
|
|
|
|
| |
More clearly separate the exclusive and shared mode format discovery.
Make the exclusive mode search more systematic in particular about
channel maps (i.e., use chmap_sel). Assume that the same sample format
/ sample rates work for all channels to narrow the search space.
|
|
|
|
|
|
| |
The code actually uses blocking mode, so opening sound device in non-blocking
mode results in choppy sound. Also, inflating the buffer isn't necessary in
blocking mode, so the function may simply return without doing anything.
|
|
|
|
|
|
|
|
|
| |
The details are described in #1173.
This "features" causes problems to users so often, it's better to remove
it.
Fixes #1173.
|
|
|
|
|
| |
This function already got uglified with debug printing; might as well go
all the way.
|
|
|
|
| |
Might or might not matter.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of maintaining a private ring buffer, use the generic support
for audio APIs with pull callbacks (internally called AO pull API). This
also fixes latency calculations: instead of just returning the
ringbuffer status, the audio playback state is calculated better and
includes interpolation.
The main reason this wasn't done earlier was mid-stream format
switching. The pull API can now handle it (in a way) by destroying and
recreating the AO. This is a bit brutal, but quite simple. It's untested
in this new AO, though. Some details might not be right, like how ot
restores the old format when reloading.
|
|
|
|
| |
Needed by ao_coreaudio_exclusive.c in the next commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This could mute a digital passthrough stream by writing zeros. All other
volume values did nothing.
The comment about MPlayer dying hasn't been true in mpv for quite a
while. It's even possible that it's fixed in upstream MPlayer. mpv will
print a scary error message when trying to change volume with spdif, and
continue normally.
If we really want to mute by writing zeros, we should do it in a
separate filter. But I'm not overly fascinated by this approach; is it
even guaranteed receivers will not be confused by a stream of zeros?
The main reason to remove this is that it's in the way of further
cleanups.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This echanges the two events hForceFeed/hFeedDone for hResume. This
like the last commit makes things more deterministic.
Importantly, the forcefeed is only done if there is not already a full
buffer yet to be played by the device. This should fix some of the
problems with exclusive mode.
This commit also removes the necessity to have a proxy to the
AudioClient object in the main thread.
fixes #1529
|
|
|
|
|
|
|
|
|
| |
This makes things a bit more deterministic. It ensures that the audio
thread isn't doing anything between IAudioClient_Stop(),
IAudioClient_Reset() and setting the sample_count to 0.
Buffer overfilling on resume is still a problem in exclusive mode (see
next commit).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit adds notifications for hot plugging of devices. It also extends
the old behaviour of the `audio-out-detected-device` property which is now
backed by the hotplugging code. This allows clients to be notified when the
actual audio output device changes.
Maybe hotplugging should be supported for ao_coreaudio_exclusive too, but it's
device selection code is a bit fragile.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This requires jumping through multiple hoops on fire. Since the
PulseAudio API is virtually undocumented, I'm not sure if this is
correct either. We only react to sink events, and only to the NEW/REMOVE
events. CHANGE events are ignored, because PulseAudio fires them far too
often - even if the system is completely idle! If pa_sink_info.name can
change, we're in trouble. pa_sink_info.description is not so important,
but it'd also be a bit un-nice if it can change, and we don't update it.
The weird way how the actual AO and the hotplug context share the same
struct (ao) comes in handy here, although context_success_cb() still had
to be duplicated from success_cb() - the unused argument has a different
type.
|
|
|
|
|
|
|
|
|
|
|
|
|
|