| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This is just a refactor, which makes it use the previously introduced
function, and allows us to make af_format_conversion_score() private.
(We drop 2 unlikely warning messages too... who cares.)
|
|
|
|
|
|
|
| |
So snd_device_name_get_hint() return values do in fact have to be freed.
Also, change listing semantics slightly: if io==NULL, skip the entry,
instead of assuming it's an output device.
|
|
|
|
| |
It was never used, but is a leftover from old times.
|
|
|
|
|
|
|
|
|
|
|
| |
Revert "win32: more wchar_t -> WCHAR replacements"
Revert "win32: replace wchar_t with WCHAR"
Doing a "partial" port of this makes no sense anymore from my
perspective. Revert the changes, as they're confusing without
context, maintenance, and progress. These changes were a bit
premature anyway, and might actually cause other issues
(locale neutrality etc. as it was pointed out).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was essentially missing from commit 0b52ac8a.
Since L"..." string literals have the type wchar_t[], we can't use them
for UTF-16 strings. Use C11 u"..." string literals instead. These have
the type char16_t[], but we simply assume char16_t is the same
underlying type as WCHAR. In practice, they're both unsigned short.
For this reason use -std=c11 on Windows. Since Windows is a "special"
environment (we require either MinGW or Cygwin), we don't need to worry
too much about compiler compatibility.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WCHAR is more portable. While at least MinGW, Cygwin, and MSVC actually
use 16 bit wchar_t, Midipix will have 32 bit wchar_t. In that context,
using WCHAR instead is more portable.
This affects only non-MinGW parts, so not all uses of wchar_t need to
be changed. For example, terminal-win.c won't be used on Midipix at
all. (Most of io.c won't either, so the search & replace here is more
than necessary, but also not harmful.)
(Midipix is not useable yet, so this is just preparation.)
|
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
|
| |
Makes it work with (apparently) crappy drivers, which refuse to set the
physical format in some cases.
|
| |
|
|
|
|
| |
Only causes problems.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, this was for AC3 only. For PCM, we used AudioUnit in
ao_coreaudio, and the only reason ao_coreaudio_exclusive exists
is that there is no other way to passthrough AC3.
PCM support is actually rather simple. The most complicated
issue is that modern OS X versions actually do not support
copying through the data; instead everything must go through
float. So we have to deal with virtual and physical format
being different, which causes some complications.
This possibly also doesn't support some other things correctly.
For one, if the device allows non-interleaved output only, we
will probably fail. (I couldn't test it, so I don't even know
what is required. Supporting it would probably be rather
simple, and we already do it with AudioUnit.)
|
|
|
|
|
| |
Currently this is equivalent. On the other hand, all audio code should
reject formats that is not in a category known to it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Mapping of spdif formats was imperfect. Since the first format on the
list is somehow AAC, it was returned first, which is confusing, because
CoreAudio calls all spdif formats AC3. Since the spdif formats have some
rather arbitrary, reverse mapping the formats didn"t actually work
either. Fix by explicitly ignoring these when spdif is used.
Also, don't forget to set the samplerate in ca_asbd_to_mpformat(), or it
will work only in some cases.
|
|
|
|
|
| |
This field is basically deprecated or for convenience only, and
this code doesn't need 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.
|
|
|
|
|
|
|
| |
We can be pretty sure that AudioUnit will remix for us.
Before this commit, we usually upmixed to stereo, because the
stereo and multichannel layouts were the only whitelisted ones.
|
| |
|
|
|
|
| |
This probably fixes the regression introduced with commit 6147bcce.
|
|
|
|
|
|
|
|
|
|
|
| |
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".
|
|
|
|
| |
Having a big switch() is simpler.
|
|
|
|
|
| |
This is actually the last line of code outside of format.c/h which still
tries to fiddle with the format bitfields.
|
|
|
|
|
|
| |
So whoever (nobody?) would want to deal with this broken and obscure AO
for an obscure audio API could add support for some more channel
layouts.
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Originally, this was written for comparing the sample format only, but
ca_change_physical_format_sync() actually expects that the full format
is compared. (For all other uses it doesn't matter.)
|
|
|
|
|
| |
This gets you the "logical" channel layout, instead of the exact thing
we're sending to the AO. (Tired of the cryptic shit ALSA gives me.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So apparently, this essentially happens when the kernel driver doesn't
implement write accesses in the channel map control. Which doesn't
necessarily mean that the channel map is unsupported, or that there is a
bug - it's just lazyness and a consequence of the terrible ALSA kernel
API for the channel mapping stuff.
In these cases, the channel count implicitly selects the channel map,
and snd_pcm_set_chmap() always fails with ENXIO.
I'm actually not sure what happens if dmix is on top of e.g. HDMI, which
actually lets you change the channel mapping.
I'm also not sure why commit d20e24e5d1614354e9c8195ed0b11fe089c489e4
(alsa-lib git repository) does not take care of this.
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
| |
On init error, the mp_msg macros are actually called. They could cause
a crash because state->log was NULL.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They are useless. Not only are they actually rarely in use; but
libavcodec doesn't even output them, as libavcodec has no such sample
formats for decoded audio.
Even if it should happen that we actually still need them (e.g. if doing
direct hardware output), there are better solutions. Swapping the sign
is a fast and lossless operation and can be done inplace, so AO actually
needing it could do this directly.
If you wonder why we keep U8 instead of S8: because libavcodec does it.
|
|
|
|
|
|
|
| |
Channel maps reported by the device as SND_CHMAP_TYPE_VAR can be freely
reordered. We don't use this much (out of laziness), but in this case
it's a simple way to reduce necessary reordering (which would be an
extra libavresample invocation), and to make debug output more readable.
|
|
|
|
|
| |
SDR/SDL is what lavc outputs for 7.1(rear), while RRC/RLC is what ALSA
uses for some 7.1 layouts, so this makes sense to me.
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you try to play surround with dmix, it will advertise surround and
lets you set more than 2 channels, but will report a stereo channel map,
with the extra channels identified as NA. We could handle this now, but
we don't want to (because it's excessively stupid).
Do it only if the channel map is not what we requested, instead of just
acting if it contains NA entries at all. This avoids that we hurt
ourselves in the unlikely but possible case we actually have to use
channel maps with NA entries.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the audio API takes a while for starting the audio callback, the
current heuristic can be off. In particular, with very short files, it
can happen that the audio callback is not called before playback is
stopped, so no audio is output at all.
Change draining so that it essentially waits for the ringbuffer to
empty. The assumption is that once the audio API has read the data
via the callback, it will always output it, even if the audio API
is stopped right after the callback has returned.
|
|
|
|
|
|
|
|
| |
If a frame could only be partially filled with real audio data, the
silence wasn't written at the correct offset. It could have happened
that the remainder of the frame contained garbage.
(This didn't happen in the more common case of playing dummy silence.)
|
|
|
|
| |
I suspect we need to hand this more gracefully in some cases.
|
|
|
|
|
| |
Seems like a good idea to avoid accidentally playing noise by writing
spdif data to pure PCM devices.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Listening to kAudioDevicePropertyDeviceHasChanged does not send any
property change notifications when the device dies. Makes no sense,
but I suppose in CoreAudio logic a dead/removed device can't send
any notifications.
This caused the player to essentially pause playback if the audio
device was removed during playback.
Fix by listening to the kAudioHardwarePropertyDevices property too,
which will actually be sent in this specific case. Then, if
querying the already dead device fails, we know we have to reload.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In short, instead of letting the coreaudio property listener set atomic
flags (which are then polled), make the property listeners actually
active.
The format change listener used during audio output now simply calls
ao_request_reload() on its own. All code involved is thread-safe, so
there's no need to do it during this audio callback (we assumed the
callback was never run concurrently with itself).
The listener installed temporarily during ca_change_format() is changed
to post a semaphore. Get rid of the weird retry logic and replace it
with a flat loop + timeout. It appears the maximum wait time could be
2500ms; reduce the total timeout to 500ms instead.
|
| |
|
|
|
|
|
| |
The ALSA API is inconsistent and doesn't report support. Just requesting
1 channel actually works. Whatever.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
|