| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Replace with the more general mp_tag_str().
|
|
|
|
|
| |
Not particularly important; just being nice and potentially avoiding
problems caused by format setting.
|
| |
|
|
|
|
|
|
|
|
|
| |
ao_coreaudio (using AudioUnit) accounted only for part of the latency -
move the code in ao_coreaudio_exclusive to utils, and use that for the
AudioUnit code.
(There's still the question why CoreAudio and AudioUnit require you to
jump through hoops this much, but apparently that's how it is.)
|
| |
|
|
|
|
|
| |
Currently this is equivalent. On the other hand, all audio code should
reject formats that is not in a category known to it.
|
|
|
|
|
|
|
|
| |
May help with (supposedly) bad drivers, which can put the device into
some sort of broken state when trying to set a different physical
format. When the previous format is restored, it apparently recovers.
This might make the change-physical-format suboption more robust.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Replace all the check macros with function calls. Give them all the
same case and naming schema.
Drop af_fmt2bits(). Only af_fmt2bps() survives as af_fmt_to_bytes().
Introduce af_fmt_is_pcm(), and use it in situations that used
!AF_FORMAT_IS_SPECIAL. Nobody really knew what a "special" format
was. It simply meant "not PCM".
|
|
|
|
|
| |
This saves us the trouble of interleaving the audio data for
no reason.
|
|
|
|
|
|
|
| |
This may or may not fix some issues with the format switching
code. Actually, it seems somewhat unlikely, but then checking
the stream type isn't incorrect either, and is probably
something the API user should always be doing.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
CoreAudio doesn't seem to have this concept. The volume is reset the
next time audio is opened.
|
|
|
|
| |
Needed by ao_coreaudio_exclusive.c in the 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.
|
|
|
|
|
|
|
|
|
|
| |
Previously we let the user use the audio device ID, but this is not persistent
and can change when plugging in new devices. That of course made it quite
worthless for storing it as a user setting for GUIs, or for user scripts.
In theory getting the kAudioDevicePropertyDeviceUID can fail but it doesn't
on any of my devices, so I'm leaving the error reporting quite high and see if
someone complains.
|
|
|
|
|
| |
This can be useful to adjust some other audio related properties
at runtime depending on the audio device being used.
|
|
|
|
| |
useless after 069016fd6c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There where 3 major errors in the previous code:
1) The kAudioDevicePropertyPreferredChannelLayout selector returns a single
layout not an array.
2) The check for AudioChannelLayout allocation size was wrong (didn't account
for variable sized struct).
3) Didn't query the kAudioDevicePropertyPreferredChannelsForStereo selector
since I didn't know about it's existence.
All of these are fixed.
Might help with #1367
|
| |
|
| |
|
|
|
| |
Should help remote debugging #1367 with --msg-level=ao=debug
|
|
|
|
|
|
|
|
| |
AudioChannelLayout uses a trailing variable sized array so we need to
query CoreAudio for the size of the struct it is going to need (or the
conversion of that particular layout would fail).
Fixes #1366
|
|
|
|
|
|
| |
Needed after af3bbb800d since now we use channel mapping all the time.
Fixes #1357
|
| |
|
|
|
|
| |
for #1279 and #1249
|
| |
|
|
|
|
| |
For #1279
|
|
|
|
| |
This is a fix attempt for #1279 and #1249.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This could trigger an assertion when using ao_alsa or ao_coreaudio. The
code was simply assuming the number of channel maps was bounded
statically (which was true at first in both AOs).
Fix by using dynamic memory allocation. It needs to be explicitly
enabled by the AOs by setting a temp context, because otherwise the
memory couldn't be freed. (Or at least this seems to be the most elegant
solution.)
Fixes #1306.
|
| |
|
|
|
|
|
| |
The CoreAudio API is built around device IDs so we store the integer as string
and read it back.
|
|
|
|
|
|
|
|
| |
Remove the unnecessary indirection through ao fields.
Also fix the inverted result of AOCONTROL_HAS_TEMP_VOLUME. Hopefully the
change is equivalent. But actually, it looks like the old code did it
wrong.
|
|
|
|
|
| |
Commit a6a4cd2c88 added reporting of playout latency, this commit also adds
support for reporting hardware and constant audio unit latency.
|
|
|
|
|
|
|
|
|
|
| |
Previous code was completly wrong. This still doesn't report the device
latency, but we report the buffer latency (as before the AO refactoring) and
the AudioUnit's latency (this is a new 'feature').
Apparently we can also report the device actual latency and we should also
calculate the actual sample rate of the audio device instead of using the
nominal sample rate, but I'll leave this for a later commit.
|
|
|
|
|
| |
Channel mapping functions are only used in the AUHAL based coreaudio, so move
them there.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The mplayer1/2/mpv CoreAudio audio output historically contained both usage
of AUHAL APIs (these go through the CoreAudio audio server) and the Device
based APIs (used only for output of compressed formats in exclusive mode).
The latter is a very unwieldy and low level API and pretty much forces us to
write a lot of code for little workr. Also with the widespread of HDMI, the
actual need for outputting compressed audio directly to the device is getting
lower (it was very useful with S/PDIF for bandwidth constraints not allowing
a number if channels transmitted in LPCM).
Considering how invasive it is (uses hog/exclusive mode), the new AO
(`ao_coreaudio_device`) is not going to be autoprobed but the user will have
to select it.
|
|
|
|
|
| |
This code doesn't actually makes much of a difference, and the AudioUnit
mostly wants layout tags anyway.
|
|
|
|
|
|
| |
The code was falling back to the full waveext chmap_sel when less than 2
channels were detected. This new code is slightly more correct since it only
fills the chmap_sel with the stereo or mono chmap in the fallback case.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
CoreAudio supports 3 kinds of layouts: bitmap based, tag based, and speaker
description based (using either channel labels or positional data).
Previously we tried to convert everything to bitmap based channel layouts,
but it turns out description based ones are the most generic and there are
built-in CoreAudio APIs to perform the conversion in this direction.
Moreover description based layouts support waveext extensions (like SDL and
SDR), and are easier to map to mp_chmaps.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, this was always conflated with uninit. This was ugly, and
also many AOs emulated this manually (or just ignored it). Make draining
an explicit operation, so AOs which support it can provide it, and for
all others generic code will emulate it.
For ao_wasapi, we keep it simple and basically disable the internal
draining implementation (maybe it should be restored later).
Tested on Linux only.
|
|
|
|
|
|
| |
We want to move the AO to its own thread. There's no technical reason
for making the ao struct opaque to do this. But it helps us sleep at
night, because we can control access to shared state better.
|
|
|
|
| |
Same for companion functions.
|
| |
|
|
|
|
|
|
|
|
|
| |
Since m_option.h and options.h are extremely often included, a lot of
files have to be changed.
Moving path.c/h to options/ is a bit questionable, but since this is
mainly about access to config files (which are also handled in
options/), it's probably ok.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This comes with two internal AO API changes:
1. ao_driver.play now can take non-interleaved audio. For this purpose,
the data pointer is changed to void **data, where data[0] corresponds to
the pointer in the old API. Also, the len argument as well as the return
value are now in samples, not bytes. "Sample" in this context means the
unit of the smallest possible audio frame, i.e. sample_size * channels.
2. ao_driver.get_space now returns samples instead of bytes. (Similar to
the play function.)
Change all AOs to use the new API.
The AO API as exposed to the rest of the player still uses the old API.
It's emulated in ao.c. This is purely to split the commits changing all
AOs and the commits adding actual support for outputting N-I audio.
|
|
|
|
|
|
|
|
|
|
| |
No AO can handle these, so it would be a problem if they get added
later, and non-interleaved formats get accepted erroneously. Let them
gracefully fall back to other formats.
Most AOs actually would fall back, but to an unrelated formats. This is
covered by this commit too, and if possible they should pick the
interleaved variant if a non-interleaved format is requested.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Output silence to the output buffer during underruns. This removes small
occasional glitches that happen before the AUHAL is actually paused from the
`audio_pause` call.
Fixes #269
|
|
|
|
|
| |
The previous code fetched the device name regardless of log level and then
only printed it if log level was verbose.
|
|
|
|
| |
Followup commit. Fixes all the files references.
|
| |
|
|
|
|
|
|
| |
Using the default output audio unit should provide a much better user
exeperience since it changes automatically the output device based on which
becomes the default one.
|
|
|
|
|
|
| |
This was removed in d427b4fd. I now found a sample that causes underruns when
moving to a chapter and apparently this is also a problem when taking
screenshots.
|
|
|
|
| |
Same as with VOs in the previous commit.
|