summaryrefslogtreecommitdiffstats
path: root/audio/out
Commit message (Collapse)AuthorAgeFilesLines
* ao_coreaudio_exclusive: check for maximum channel countwm42015-10-261-0/+6
| | | | | | 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.
* ao_coreaudio_exclusive: fallback to stereo on unknown channel layoutswm42015-10-261-1/+10
| | | | | | | | | | | This is intended for the case when CoreAudio returns only unknown channel layouts, or no channel layout matches the number of channels the CoreAudio device forces. Assume that outputting stereo or mono to the first channels is safe, and that it's better than outputting nothing. It's notable that XBMC/kodi falls back to a static channel layout in this case. For some messed up reason, the layout it uses happens to match with the channel order in ALSA's/mpv's "7.1(alsa)" layout.
* ao_coreaudio_chmap: minor refactorwm42015-10-261-26/+22
| | | | | | Share some code between ca_init_chmap() and ca_get_active_chmap(), which also makes it look slightly nicer. No functional changes, other than the additional log message.
* ao_coreaudio_chmap: allow stereo as fallback; avoid mono fallbackwm42015-10-261-2/+5
| | | | | | | | | | | | | | | | If no channel layouts were determined (which can actually happen with some "strange" devices), the selection code was falling back to mono, because mono is always added as a fallback. This doesn't seem quite right. Allow a fallback to stereo too, if no channel layout could be retrieved at all. So we always assume that mono and stereo work, if no other layouts are available. (I still don't know what the CoreAudio stereo layout is supposed to do. It could be used to swap left and right channels. It could also be used to pad/move the channels, but I have never seen that. And it can be set to non-stereo channels, which breaks mpv. Whatever.)
* ao_coreaudio: fix another minor memory leakwm42015-10-261-1/+2
| | | | How stupid, even the cleanup gotos were already there.
* audio: use AVFrames with more than 8 channels correctlywm42015-10-261-0/+3
| | | | | | | Requires messy dealing with the extended_ fields. Don't bother with af_lavfi and ao_lavc for now. There are probably no valid use-cases for these.
* audio: always log channel maps before determining final mapwm42015-10-263-17/+8
| | | | | Until now, this was done only in debug verbosity, while some AOs logged equivalent information in verbose mode. Clean this up.
* ao_coreaudio: fix potential UB in error caseswm42015-10-261-3/+2
| | | | | | | | | mNumberChannelDescriptions being 0 is pretty much an error, but if it can happen, then the code checking the chmap below will trigger UB, as chmap is not initialized at all. Also, simplify the code a little: we never change the number of channels, so this is just fine.
* ao_coreaudio_chmap: add more loggingwm42015-10-261-8/+10
|
* ao_alsa: log format probing in verbose modewm42015-10-251-2/+1
| | | | | And also remove a redundant log message. (We can tell from the following probe or error message whether or not the format test is successful.)
* ao_coreaudio_exclusive: fix buildwm42015-10-211-2/+2
| | | | "Let's apply cosmetic last minute changes without testing them."
* ao_coreaudio: do not accept unknown channel layoutswm42015-10-211-1/+1
| | | | | | | | | | | | | | | Coreaudio gives us a channel map with all entries set to kAudioChannelLabel_Unknown. This is translated to a mpv channel map with all channels set to NA, which has special meaning: it's an "unknown" channel map, which acts as wildcard and can be converted from/to any channel layout. Not really what we want. I've got this with USB audio, playing stereo. The multichannel layout consisted of 2 unknown channels, while the stereo channel map was stereo (as expected). Note that channel maps with _some_ NA entries are not affected by this, and must still work.
* ao_coreaudio_exclusive: deal with devices return different channel countwm42015-10-213-1/+33
| | | | | | | | | 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: avoid unnecessary format changeswm42015-10-211-0/+6
| | | | | Not particularly important; just being nice and potentially avoiding problems caused by format setting.
* ao_coreaudio: log current format before setting new formatwm42015-10-211-0/+2
|
* ao_coreaudio: fix some minor memory leakswm42015-10-211-0/+6
|
* ao_coreaudio: raise timeout for change-physical-formatwm42015-10-201-1/+1
| | | | | | | | | | Reportedly fixes operation with "USB connected Parasound ZDAC v.2". (OSX and USB audio sure is not nice at all.) This might be perceived as hang by some users, so it's quite possible that this will have to be adjusted again somehow. Fixes #2409.
* ao_alsa: add debug messages for format searchKevin Mitchell2015-10-061-0/+2
|
* ao_alsa: fix failure to find any sampleformatKevin Mitchell2015-10-061-4/+7
| | | | | Set format to invalid after each failed test. This way the final check for valid format will actually fail if no formats work.
* audio: add option for falling back to ao_nullwm42015-10-052-0/+7
| | | | | | | | | The manpage entry explains this. (Maybe this option could be always enabled and removed. I don't quite remember what valid use-cases there are for just disabling audio entirely, other than that this is also needed for audio decoder init failure.)
* ao: rework audio output driver probingwm42015-10-051-38/+42
| | | | | | | | | | | | | | | Make the code a bit more uniform. Always build a "dummy" audio output list before probing, which means that opening preferred devices and pure auto-probing is done with the same code. We can drop the second ao_init() call. This also makes the next commit easier, which wants to selectively fallback to ao_null. This could have been implemented by passing a different requested audio output list (instead of reading it from MPOptions), but I think it's better if this rather special feature is handled internally in the AO code. This also makes sure the AO code can handle its own options (such as the audio output list) in a self-contained way.
* ao_alsa: improve handling of device disconnectionwm42015-09-281-3/+20
| | | | | | | This can happen with USB audio. There was already code for this, but something in mpv and ALSA changed - and now the old code is not necessarily triggered anymore. It probably depends on the exact situation.
* ao_coreaudio_utils: fix error handling in device listing codewm42015-09-281-3/+10
| | | | | | | | This could sometimes cause crashes in hotplug events. (Apparently in cases when CoreAudio changes its state asynchronously, or such.) CA_GET_STR() does not set the string if there was an error, so errors have to be strictly checked before using it.
* ao_lavc: minor simplificationwm42015-09-111-2/+2
|
* ao_alsa: use sample format determination codeKevin Mitchell2015-09-101-12/+10
|
* ao_alsa: add double to sample format listKevin Mitchell2015-09-101-0/+1
|
* ao_alsa: put spdif formats into find_alsa_formatKevin Mitchell2015-09-101-9/+9
|
* ao_oss: use new sample format determination codewm42015-09-101-1/+2
|
* ao_lavc: use new sample format determination codewm42015-09-101-20/+15
| | | | | | | 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.)
* ao_alsa: fix minor memory leakwm42015-08-251-8/+11
| | | | | | | 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.
* audio: remove unused legacy libavutil headerwm42015-08-071-1/+0
| | | | It was never used, but is a leftover from old times.
* win32: revert wchar_t changeswm42015-08-014-14/+13
| | | | | | | | | | | 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).
* win32: more wchar_t -> WCHAR replacementswm42015-07-303-9/+9
| | | | | | | | | | | | | 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.
* win32: replace wchar_t with WCHARwm42015-07-293-4/+5
| | | | | | | | | | | | | 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: fix device latency, share the codewm42015-07-064-23/+25
| | | | | | | | | 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.)
* ao_coreaudio_exclusive: continue even if setting physical format failswm42015-07-062-2/+4
| | | | | Makes it work with (apparently) crappy drivers, which refuse to set the physical format in some cases.
* ao_coreaudio_exclusive: fix some verbose outputwm42015-07-041-2/+2
|
* ao: don't pass along AO arguments when redirectingwm42015-07-031-1/+1
| | | | Only causes problems.
* ao_coreaudio: add exclusive suboptionwm42015-07-031-2/+4
|
* ao_coreaudio_exclusive: support PCMwm42015-07-031-15/+35
| | | | | | | | | | | | | | | | | | 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.)
* ao_coraudio: reject all non-PCM formatswm42015-07-031-1/+1
| | | | | Currently this is equivalent. On the other hand, all audio code should reject formats that is not in a category known to it.
* ao_coreaudio_utils: reduce spamwm42015-07-031-1/+0
|
* ao_coreaudio_utils: fix format back-mappingwm42015-07-031-5/+7
| | | | | | | | | | | 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.
* ao_coreaudio_exclusive: do not set ao->bpswm42015-07-031-3/+0
| | | | | This field is basically deprecated or for convenience only, and this code doesn't need it.
* ao_coreaudio_exclusive: dump all latency info in verbose modewm42015-07-031-1/+4
|
* ao_coreaudio_exclusive: factor format selectionwm42015-07-031-35/+44
|
* ao_coreaudio_exclusive: separate out stream selectionwm42015-07-031-61/+76
|
* ao_coreaudio: restore physical format if it can't be set exactlywm42015-06-302-2/+14
| | | | | | | | 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.
* ao_coreaudio: support native mono outputwm42015-06-291-0/+2
| | | | | | | 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.
* ao_coreaudio: log hotplug events explicitlywm42015-06-291-3/+6
|
* ao_wasapi: fix regressionwm42015-06-271-1/+1
| | | | This probably fixes the regression introduced with commit 6147bcce.
* audio: fix format function consistency issueswm42015-06-2612-43/+45
| | | | | | | | | | | 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".
* audio: replace format name tablewm42015-06-261-4/+3
| | | | Having a big switch() is simpler.
* ao_coreaudio_utils: use a macrowm42015-06-261-1/+1
| | | | | This is actually the last line of code outside of format.c/h which still tries to fiddle with the format bitfields.
* ao_sndio: fix commentwm42015-06-261-2/+1
| | | | | | 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.
* ao_coreaudio: support non-interleaved outputwm42015-06-262-5/+12
| | | | | This saves us the trouble of interleaving the audio data for no reason.
* ao_coreaudio: explicitly skip input streamswm42015-06-262-4/+22
| | | | | | | 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.
* ao_coreaudio_utils: compare full AudioStreamBasicDescriptionwm42015-06-251-1/+3
| | | | | | 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.)
* audio: output human-readable channel layouts toowm42015-06-251-8/+2
| | | | | 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.)
* ao: standardize channel layout name in debug output furtherwm42015-06-251-0/+2
|
* ao_alsa: fix a log messagewm42015-06-211-4/+5
| | | | | | | | | | | | | | | | | 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.
* Various spelling fixesMarcin Kurczewski2015-06-181-3/+3
| | | | Signed-off-by: wm4 <wm4@nowhere>
* ao_wasapi: fix crash on hotplug init errorwm42015-06-171-0/+1
| | | | | On init error, the mp_msg macros are actually called. They could cause a crash because state->log was NULL.
* audio: remove S8, U16, U24, U32 formatswm42015-06-166-57/+9
| | | | | | | | | | | | | 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.
* ao_alsa: if possible, reorder device maps to std layoutswm42015-06-121-0/+2
| | | | | | | 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.
* ao_alsa: make it accept 7.1 over HDMIwm42015-06-121-0/+2
| | | | | 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.
* ao_alsa: change ALSA braindeath heuristicwm42015-06-111-3/+4
| | | | | | | | | | | | 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.
* ao_coreaudio: change physical stream format synchronouslywm42015-06-092-5/+2
|
* audio/out/pull: avoid dropping some audio when drainingwm42015-06-091-9/+18
| | | | | | | | | | | | 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.
* audio/out/pull: correctly pad partial frames with silencewm42015-06-09