| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
With all the reordering etc. that can go on in this filter, it's useful
to see what upmix/downmix it's actually performing.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
And use it for the mono case. This is slightly more formal and will make
it easier to add more such cases.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
Audio formats used a semi-clever schema to encode the properties of the
PCM encoding as bitfields into the format integer value.
The af_fmt_change_bits() implementation becomes a bit weird, but it's
an improvement to the rest of the code.
(I've always disliked it, so why not get rid of it.)
|
| |
|
|
|
| |
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.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The speaker replacement nonsense sometimes made blatantly incorrect
decisions. In this case, it prefered a 7.1(rear) upmix over outputting
5.1(side) as 5.1, which makes no sense at all. This happened because 5.1
and 7.1(rear) appeared equivalent to the final selection, as both of
them lose the sl-sr channels. The old code was too stupid to select the
one with the lower number of channels as well.
Redo this. There's really no reason why there should be a separate final
decision, so move the speaker replacement logic into the
mp_chmap_is_better() function.
Improve some other details. For example, we never should compare the
plain number of channels for deciding upmix/downmix, because due to NA
channels this is essentially meaningless. Remove the NA channels when
doing this comparison. Also, explicitly handle exact matches.
Conceptually this is not necessary, but it avoids that we have to
needlessly shuffle audio data around.
|
| | |
|
| |
|
|
|
| |
And also simplify it (it certainly had the most awkward API you could
think of for such a simple function).
|
| | |
|
| |
|
|
|
|
|
|
| |
This avoids keeping "bad" state from previous reconfig calls, such as
the internal_sample_format option (which is set only on the first
reconfig call).
There's no advantage to keeping the resample contexts around anyway.
|
| |
|
|
|
| |
mp_format is not a libavresample input format here, and the comment was
more confusing than it helped.
|
| |
|
|
|
|
| |
Basically, af_fix_format_conversion() behaves stupid you insert a
conversion filter that won't work, and adding back the conversion test
function is the simplest fix to it.
|
| |
|
|
| |
libswresample verbosely complains.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
MPlayer traditionally had completely separate sh_ structs for
audio/video/subs, without a good way to share fields. This meant that
fields shared across all these headers had to be duplicated. This commit
deduplicates essentially the last remaining duplicated fields.
|
| |
|
|
|
| |
Why not. "format" sounds too misleading for the actual importance and
meaning of this field.
|
| |
|
|
| |
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.
|
| |
|
|
| |
The 24 bit conversion code needs the relevant preprocessor symbols.
|
| |
|
|
|
|
| |
This attempted to find a minimal filter graph for a format conversion
involving multiple conversion filters. With the last 2 commits it
becomes dead code - remove it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now af_lavrresample can output 24 bit samples directly, by doing the
conversion "inline". Luckily, S32->S24 can be done in-place, so this
isn't too much work. But the output conversion logic (which seems to be
adding up) gets slightly more complicated again.
Normally this is done by af_convert24. But having multiple conversion
filters complicates some aspects of the filter chain. S24 output is the
only thing the code for multiple conversion filters is still needed for,
and getting rid of that is preferable.
|
| |
|
|
|
|
| |
If the code path for additional output conversion is active,
reorder_planes() is always called, even if the reorder_out array wasn't
filled. This is obviously wrong - always fill this array.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Shit.
|
| |
|
|
|
|
| |
The filter can buffer singificant amounts of audio.
(The proper fix is making the filter chain PTS-aware.)
|
| |
|
|
|
| |
Even if we flush the current filter, we have to read the remaining
output from the frame we previously fed to the filter.
|
| |
|
|
| |
Its last use was removed in 433402b5.
|
| |
|
|
|
| |
Going by the existing names, these should make sense. HDMI knows about
these layouts, but does not name them.
|
| |
|
|
|
|
|
| |
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.
|
wm4
Marcin Kurczewski