summaryrefslogtreecommitdiffstats
path: root/audio/out
Commit message (Collapse)AuthorAgeFilesLines
* ao: disambiguate default device list entrieswm42015-11-271-2/+6
| | | | | | | | | | | If there were many AO drivers without device selection, this added a "Default" entry for each AO. These entries were not distinguishable, as the device list feature is meant not to require to display the "raw" device name in GUIs. Disambiguate them by adding the driver name. If the AO is the first, the name will remain just "Default". (The condition checks "num > 1", because the very first entry is the dummy for AO autoselection.)
* ao_alsa: filter audio device listwm42015-11-241-1/+15
| | | | | | | | Remove known useless device entries from the --audio-device list (and corresponding property). Do this because the list is supposed to be a high level list of devices the user can select. ALSA does not provide such a list (in an useable manner), and ao_alsa.c is still in the best position to improve the situation somewhat.
* ao_alsa: list bidirectional devices toowm42015-11-241-1/+1
| | | | | | | | | The ALSA doxygen says: IOID - input / output identification ("Input" or "Output"), NULL means both This bug was blatantly introduced with commit cf94fce4.
* ao_wasapi: get rid of Vistablob hackKevin Mitchell2015-11-244-51/+6
| | | | | This was required to work around XP linking issues and is no longer required.
* ao_wasapi: only report per-app volume in shared modeKevin Mitchell2015-11-191-1/+2
| | | | | otherwise we were incorrectly adjusting the hardware master volume in exclusive mode with softvol=auto
* ao_wasapi: work around DTS passthrough failurewm42015-11-191-1/+18
| | | | | | | | | | Apparently, some audio drivers do not support the DTS subtype, but passthrough works anyway if the AC3 subtype is set. Just retry with AC3 if the proper format doesn't work. The audio device which exposed this behavior reported itself as "M601d-A3/A3R (Intel(R) Display Audio)". xbmc/kodi even always passes DTS as AC3.
* ao_openal: fix sign of speaker angle in commentKevin Mitchell2015-11-181-1/+1
|
* ao_openal: fix virtual speaker positioningJustas LaviĊĦius2015-11-181-10/+10
| | | | | | Place speakers in standard positions equidistant from the listener. use standard coordinate system
* ao_openal: accommodate more sample formatsKevin Mitchell2015-11-171-7/+44
| | | | | | Try and and choose the closest sample format to the one requested. fixes #2494
* ao_openal: move uninit before initKevin Mitchell2015-11-171-12/+12
| | | | the next commit will use uninit within init
* ao_jack: remove "alsa" std-channel-layout choicewm42015-11-071-5/+1
| | | | | Same deal as with previous commit. "waveext" is less arbitrary and at least supports 3/7 channels.
* ao_alsa: remove the last bits of legacy channel map fallbackwm42015-11-071-3/+1
| | | | | | | | Essentially we'd use something random, just because it's part of the srt of traditionally used ALSA channel mappings. But each driver can do its own things. This doesn't let me sleep at night, so remove it.
* ao_alsa: fix 7.1 over HDMIwm42015-11-041-0/+26
| | | | | | | | | | | | | | | | | We need to effectively swap the last channel pair. See commit 4e358a96 and 5a18c5ea for details. Doing this seems rather strange, as 7.1 just extends 5.1 with 2 new speakers, and 5.1 doesn't need this change. Going by the HDMI standard and the Intel HDA sources (cited in the referenced commits), it also looks like 7.1 should simply append two channels to 5.1 as well. But swapping them is apparently correct. This is also what XBMC does. (I didn't find any other applications doing 7.1 PCM using the ALSA channel map API. VLC seems to ignore the 7.1 case.) Testing reveals that at least the end result is correct. "Normal" ALSA 7.1 is unaffected by this, as it reports a different (and saner) channel layout.
* ao_alsa: map mp_chmaps back to ALSA in a different waywm42015-11-041-39/+54
| | | | | | | | | | | | | | | | Instead of constructing an ALSA channel map from mpv ones from scratch, try to find the original ALSA channel map again. Th result is that we need to convert channel maps only in one direction. If we need to map a mp_chmap to ALSA, we fetch the device's channel map list, convert each entry to mp_chmap, and find the first one which fits. This seems helpful for the following commit. For now, this only gets rid of mapping back the trivial MONO mapping, which alone would still be acceptable, but with other channel layout mogrifications it gets messy fast. While we need to do something awkward to keep our channel map reordering for VAR chmaps (which basically gives nicer output and possibly slightly better performance), this is still the better solution.
* ao_alsa: print more chmap info at debug verbositywm42015-11-041-9/+11
|
* ao_alsa: minor cleanupswm42015-11-031-34/+18
|
* ao_alsa: simplify dmix non-NA hackwm42015-11-031-58/+43
| | | | | There's really no need to do this deep in the chmap sslection code. This will setup the device further than before, but that doesn't matter.
* ao_alsa: move channel map setting code out of main init functionwm42015-11-031-104/+125
| | | | This grew way too large.
* ao_alsa: make failure of buffer parameter setting non-fatalwm42015-11-031-4/+12
| | | | | | | | | | | | | | | | | | | | These calls actually can leave the ALSA configuration space empty (how very useful), which is why snd_pcm_hw_params() can fail. An earlier change intended to make this non-fatal, but it didn't work for this reason. Backup the old parameters, so we can retry with the non-empty configuration space. (It has to be non-empty, because the previous setters didn't fail.) Note that the buffer settings are not very important to us. They're a leftover from MPlayer, which needed to write enough data to the audio device to not underrun while decoding and displaying a video frame. In mpv, most of these things happen asynchronously, _and_ there is a dedicated thread just for feeding the audio device, so we should be pretty imune even against extreme buffer settings. But I suppose it's still useful to prevent PulseAudio from making the buffer too large, so still keep this code.
* ao_alsa: disable resampling first thingwm42015-11-031-7/+7
| | | | | | Again, this could have bad access, is unlikely, and has no bad consequences. It's noteworthy that vlc and the ALSA PCM example both do this first, even if they set the sample rate later.
* ao_alsa: set access type before formatwm42015-11-031-11/+13
| | | | | | | | I'm worried that not restricting the access type before restricting the format will cause problems. While it's unlikely, it might prevent failures in some corner cases. Also, since we by default always use interleaved access (buggy ALSA plugins), this will have no effects at all.
* ao_alsa: handle channel count mismatch safeguard after chmap negotiationwm42015-11-031-12/+12
| | | | | | | | If the API doesn't list padded channel maps, but the final device channel map is padded, and if unpadded output is not possible (unlike in the somewhat similar dmix case), then we shouldn't apply the channel count mismatch fallback in the beginning. Do it after channel map negotiation instead.
* ao_alsa: apply non-NA fallback only if input is stereowm42015-11-031-0/+1
| | | | | | Doesn't matter much; effectively this prevents just log spam in some cases where the map is legitimately padded. Normally this is really only needed for the dmix ALSA case. (See git blame for details.)
* ao_alsa: treat SND_CHMAP_UNKNOWN as NA channel toowm42015-11-031-0/+1
| | | | | | Apparently required by nVidia HDMI. It should not be, and NA would definitely be more correct here, so this could be considered a driver bug. Maybe.
* ao_alsa: remove log message on pausingwm42015-11-031-1/+2
| | | | This was annoying.
* 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
|