| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Until recently, the channel layout code happened to catch this, but now
an explicit check is needed. Otherwise, it'd try to pad the missing
channels with NA in the channel map fallback code.
|
|
|
|
| |
"Let's apply cosmetic last minute changes without testing them."
|
|
|
|
|
|
|
|
|
| |
If the device returns an unexpected number of channels instead of the
requested count on init, don't immediately error out. Instead, look if
there's a channel map with the given number of channels.
If there isn't, still error out, because we don't want to guess the
channel layout.
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
|
| |
This field is basically deprecated or for convenience only, and
this code doesn't need it.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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.
|
|
|
|
| |
Didn't use the properties it was supposed to use.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Should be almost equivalent, unless there are streams on which this call
does not work for unknown reasons.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
ao_get_delay() returns double, but the get_delay callback still
returned float.
|
|
This is so that the source file name matches the AO name
|