| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
All VOs use proper option parsing now, and compatibility hacks are not
needed.
|
|
|
|
| |
Finally not used by anything anymore. Farewell.
|
|
|
|
|
| |
The big endian case was not covered. Doesn't make much difference since mpv
runs on Macs with x86 only, but for the sake of correctness.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This is not done automatically by CoreAudio. I am told that it would a PITA
to have to switch back the format manually on the device (especially if the
same device is used for lpcm output).
|
|
|
|
|
|
| |
b2f9e0610 introduced this functionality with code that was quite 'monolithic'.
Split the functionality over several functions and ose the new macros to get
array properties.
|
|
|
|
|
|
|
|
| |
Introduce some macros to deal with properties. These allow to work around the
limitation of CoreAudio's API being `void **` based. The macros allow to keep
their client's code DRY, by not asking size and other details which can be
derived by the macro itself. I have no idea why Apple didn't design their API
like this in the first place.
|
| |
|
|
|
|
|
|
|
|
|
| |
* ao_coreaudio_utils: contains several utility function
* ao_coreaudio_properties: contains functions to set and get audio object
properties.
Conflicts:
audio/out/ao_coreaudio.c
|
|
|
|
|
| |
Previous code needlessly stored the input asbd before actually testing it's
support against the hardware.
|
| |
|
|
|
|
| |
this is a wip
|
|
|
|
|
|
| |
The condition was checked wrongly on asbd which is the input format
description. This lead to the condition always being true, thus selecting lpcm
streams for digital input.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
kHALOutputParam_Volume is the linear gain so it should be at maximum 1 to
keep the audio quality good. No idea why it was more than that.
|
|
|
|
| |
Also extract this functionality inside a function in coreaudio_common
|
| |
|
|
|
|
|
| |
Luckily they all were inside for loops so the functionality does not actually
change.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The initialization is split more clearly between compressed and lpcm case.
For the compressed case, format selection is simplified a lot and negotiation
removed. The way it was written it just passed back to the core the original
requested format, not what was found available on hardware.
Since this is most likely useless for the compressed case, I didn't bother
with this. In the future I'd like to split this AO in two one that only uses
the AUHAL and the other with direct access to the hardware so that even
passthrough of lcpm can be possible. This would decrease the latency,
audiophiles would like that.
|
| |
|
|
|
|
|
|
|
| |
Split out some utility functions that use the CoreAudio API but are not related
the main task of the AOs (which is to move data correctly to the ringbuffer).
These are mainly need for the verbosity of the CoreAudio API and are just
obscuring the 'real' code.
|
|
|
|
| |
property_address -> p_addr
|
|
|
|
| |
WIP
|
|
|
|
|
| |
Change the ca_msg macro to pass along MSGT_AO automatically. Also use it for
every output for consistency.
|
|
|
|
|
| |
It was reported that it also works by not setting the read size in the
AudioBuffer (now idea how, but I will discover it later).
|
| |
|
|
|
|
|
|
|
| |
Read only the requested amount by the AUHAL (instead of all the buffered data).
No idea what the deal is with pausing the audio units if there is no audio to
play, maybe to avoid underruns of some sort. Anyway from my tests this
condition never occurred so I'm removing it all.
|
|
|
|
| |
Also get rid of the useless comment.
|
|
|
|
|
|
|
| |
Commit 9a83d03 accidentally removed this. (Overlooked "static"?)
The handling of this rather sucks. Maybe a better solution will be
possible once we clean up the mp_msg code.
|
|
|
|
|
|
| |
This also affects --audiofile. The previous behavior wasn't really
useful. There are even separate switches for that: --audio-demuxer and
--sub-demuxer.
|
| |
|
|
|
|
|
| |
This makes it actually possible to use the filter with more complicated
filter graphs (such as graphs containing the "," character).
|