aboutsummaryrefslogtreecommitdiffhomepage
path: root/audio
Commit message (Collapse)AuthorAge
* player: print used number of threads in verbose modeGravatar wm42015-01-05
| | | | Also, don't use av_log() for mpv output.
* af_volume: dump applied replaygain in verbose modeGravatar wm42015-01-04
|
* ao/wasapi: style/code formatting tweaksGravatar Kevin Mitchell2015-01-02
|
* ao/wasapi: improve exclusive mode format searchGravatar Kevin Mitchell2015-01-02
| | | | fixes #1376
* ao/wasapi: revamp set_waveformatexGravatar Kevin Mitchell2015-01-02
| | | | | | | | * bits instead of bytes * add valid_bits argument * just pass in the mp_chmap and get the number and wavext channel map from that * indicate valid bits in waveformat_to_str * make appropriate accomodations in try_format
* ao/wasapi: add CO_E_NOTINITIALIZED to explain_errGravatar Kevin Mitchell2015-01-02
| | | | someone on irc reported seeing this error
* ao_portaudio: remove this audio outputGravatar wm42014-12-29
| | | | | It's just completely useless. We have good native support for all 3 desktop platforms, and ao_sdl or ao_openal as fallbacks.
* ao_alsa: print channel map if setting it failsGravatar wm42014-12-29
| | | | | | | | | | This message is printed when the audio device advertised a channel map, but couldn't set it - which is probably a dmix bug (we'll never know, ALSA doesn't take bug reports). Print the requested map, so that the user (maybe) can make a connection when seeing the message and the actually used channel map, which might be less confusing. Or at least less useless.
* ao: add debug log with the detected channel mapsGravatar Stefano Pigozzi2014-12-29
| | | | This could be helpful with bug reports.
* chmap_sel: add multichannel fallback heuristicGravatar Stefano Pigozzi2014-12-29
| | | | | | | | | | | | Instead of just failing during channel map selection, try to select a close layout that makes most sense and upmix/downmix to that instead of failing AO initialization. The heuristic is rather simple, and uses the following steps: 1) If mono is required always prefer stereo to a multichannel upmix. 2) Search for an upmix that is an exact superset of the required channel map. 3) Search for a downmix that is the exact subset of the required channel map. 4) Search for either an upmix or downmix that is the closest (minimum difference of channels) to the required channel map.
* chmap: add a 7.1(rear) layout nameGravatar Stefano Pigozzi2014-12-29
| | | | This is common on Apple systems so it's handy to have a label for it.
* ao_coreaudio: remove useless guardGravatar Stefano Pigozzi2014-12-27
| | | | useless after 069016fd6c
* ao_coreaudio: fix some naming conventionsGravatar Stefano Pigozzi2014-12-27
|
* ao_coreaudio: fix channel mappingGravatar Stefano Pigozzi2014-12-27
| | | | | | | | | | | | | | | There where 3 major errors in the previous code: 1) The kAudioDevicePropertyPreferredChannelLayout selector returns a single layout not an array. 2) The check for AudioChannelLayout allocation size was wrong (didn't account for variable sized struct). 3) Didn't query the kAudioDevicePropertyPreferredChannelsForStereo selector since I didn't know about it's existence. All of these are fixed. Might help with #1367
* ao_coreaudio: fix typoGravatar Stefano Pigozzi2014-12-27
|
* ao_coreaudio: move some code to make output readableGravatar Stefano Pigozzi2014-12-27
|
* ao_coreaudio: add more layout debug outputsGravatar Stefano Pigozzi2014-12-27
| | | Should help remote debugging #1367 with --msg-level=ao=debug
* win32: add mmap() emulationGravatar wm42014-12-26
| | | | | | | | Makes all of overlay_add work on windows/mingw. Since we now don't explicitly check for mmap() anymore (it's always present), this also requires us to make af_export.c compile, but I haven't tested it.
* ao_coreaudio: fix AudioChannelLayout allocationsGravatar Stefano Pigozzi2014-12-26
| | | | | | | | AudioChannelLayout uses a trailing variable sized array so we need to query CoreAudio for the size of the struct it is going to need (or the conversion of that particular layout would fail). Fixes #1366
* ao_alsa: fix unpause path atfer previous commitGravatar wm42014-12-23
| | | | The resume code was accidentally fully removed from this code path.
* ao_alsa: fix resuming from suspend modeGravatar wm42014-12-23
| | | | | | | | | | | snd_pcm_prepare() was not always called, which could result in an infinite loop. Whether snd_pcm_prepare() was actually called depended on whether the device was a hw device (or other characteristics; depending on snd_pcm_hw_params_can_pause()), and required real suspend (annoying for testing), so it was somewhat tricky to reproduce without knowing these things.
* ao_alsa: fix setting mono channel mapGravatar wm42014-12-20
| | | | | | | When setting the ALSA channel map, we never actually set the map we got from ALSA directly, but convert it to mpv's, and then back to ALSA's. mpv and ALSA use different conventions for mono, and there is already an exception for ALSA->mpv, but not mpv->ALSA.
* ao_alsa: remove some dead codeGravatar wm42014-12-20
| | | | | | | | This was only added recently (c1e97161) as an attempt to minimize the bad impact of channel layout device aliases. But use of these was removed in commit 49df0132. Now this code does pretty much nothing, and shouldn't be needed anymore. It does something when using spdif, but this fallback won't work anyway.
* audio: fix previous commitGravatar wm42014-12-20
| | | | | This would have always forced mono first (if supported by the AO), instead of stereo.
* audio: fix fallback if audio API does not support monoGravatar wm42014-12-20
| | | | This makes it fallback to stereo properly.
* ao_coreaudio: fix mono/stereo channel mappingGravatar Stefano Pigozzi2014-12-16
| | | | | | Needed after af3bbb800d since now we use channel mapping all the time. Fixes #1357
* ao_coreaudio: add missing goto for error pathGravatar Stefano Pigozzi2014-12-16
|
* ao/wasapi: use IsEqualGUID and IsEqualPropertyKeyGravatar Kevin Mitchell2014-12-16
| | | | before we were reinventing this wheel
* ao_alsa: remove old multichannel methodGravatar wm42014-12-15
| | | | | | | | | | | | | | | | | | | | | | | | | The "old" method (before the ALSA channel map API) used device aliases like "surround51" to set the channel layout. The "interesting" part was that these devices usually redirect to a hardware device. This means playing stereo would lead you to the "default" device (dmix), while e.g. 5.1 to "surround51", which automatically takes care of the fact that dmix can't do 5.1. This is pretty much nonsense, though. It shouldn't depend on the damn input media file whether the player is going to use shared access (dmix) or exclusive access (direct hw device). As a consequence, by default ao_alsa will do only what dmix can do. If the user actually wants multichannel, he has to select a suitable hw device with --audio-device. From there on, the correct speaker mapping will be ensured via the channel mapping API. The change is preparation for making multichannel output the default (as far as supported by the audio output API). Of the common APIs, only ALSA messes up beyond repair, so I feel like this change is needed. On ancient alsa-lib versions, only stereo and mono can be played with this branch.
* ao_alsa: add ridiculous hack to deal with braindead ALSA behaviorGravatar wm42014-12-15
| | | | | | | | | | | | | | | | | | | | | dmix reports channel layouts it doesn't support. The rest of the technical part of the story is in the code comment. This seems to be the only reasonable way to fallback from trying to initialize certain devices (like dmix) with multichannel audio. We could probably add support for such padding channels to our audio chain or to ao_alsa itself, but this would probably be much more work than this commit. What dmix does is probably a bug. I've tried to report it to ALSA. Thay have a link on their website to a bug tracker, but it's a dead link, and has been for years. I've posted to alsa-devel, but received no reply. I'm thus assuming this absolutely retarded behavior is by design, and nothing will happen to improve upon it. I'm considering sending Lennart Poettering a "thank you" email, because with PulseAudio, multichannel audio just works (although some other things just don't work).
* ao/wasapi: set the ao with the waveformat channelmapGravatar Kevin Mitchell2014-12-15
| | | | hopefully this fixes #1350
* af_hrtf: Fix out-of-range read.Gravatar reimar2014-12-06
| | | | | | | Based on patch by Yuriy Kaminskiy [yumkam gmail]. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@37330 b3059339-0415-0410-9bf9-f77b7e298cf2 Signed-off-by: wm4 <wm4@nowhere>
* ao_alsa: minor simplificationGravatar wm42014-12-05
| | | | | | | | Whether we print it as warning or error doesn't really matter; we continue anyway. (I don't actually know what the implications of running in non-blocking mode are; for what's it worth, when I tested with explicitly changing to non-blocking, it seemed to work fine anyway, so don't change that part.)
* ao_alsa: hackfix mono playbackGravatar wm42014-12-05
| | | | | | ALSA returns "FL" as channel layout when trying to play mono. mpv and libavresample don't like this; in particular, using libavresample to convert stereo to "FL" fails.
* coreaudio: don't output too many channel descriptionsGravatar Stefano Pigozzi2014-12-05
| | | | for #1279 and #1249
* coreaudio: add missing \n in log lineGravatar Stefano Pigozzi2014-12-05
|
* coreaudio: don't print layout a second timeGravatar Stefano Pigozzi2014-12-05
| | | | For #1279
* ao_alsa: simplify, remove no-block suboptionGravatar wm42014-12-05
| | | | | | | | | | | If no-block was given, the device would be opened with SND_PCM_NOBLOCK. Also, after opening, blocking mode was unconditionally enabled anyway with snd_pcm_nonblock(). Further, if opening with SND_PCM_NOBLOCK failed, opening was retried without this flag. This doesn't make any sense to me, and I've never heard of someone using this suboption. I suspect it has to do with ancient ALSA bugs or API caveats. Remove it and simplify the code.
* ao_alsa: try to fallback to "default" device if device is busyGravatar wm42014-12-04
| | | | | | | | | | | | | ALSA is crap. It's impossible to make multichannel playback just do the right thing. dmix (the default on most distros) can do stereo only, and will refuse to play multichannel. On the other hand, if you try like mpv (and mplayer) to open a multichannel device (like "surround51" etc.), this will actually open a hardware device, which will either fail if dmix is active, or block out dmix if opening succeeds. This commit falls back to "default" (i.e. dmix) if opening a multichannel device fails, which is a tiny step towards the right behavior. (Although fixing it fully is impossible.)
* coreaudio: reject descriptions with too many channelsGravatar Stefano Pigozzi2014-12-04
| | | | This is a fix attempt for #1279 and #1249.
* coreaudio: fix more layout printsGravatar Stefano Pigozzi2014-12-04
|
* coreaudio: fix prints of uint32_t in log_layoutGravatar Stefano Pigozzi2014-12-04
|
* audio: fix one of the previous commitsGravatar wm42014-12-01
| | | | | Fixes commit 52c51149. It broke multichannel (or possibly everything) for ao_alsa, ao_oss, ao_sndio.
* ao_coreaudio: initialize fetched properties to zerosGravatar Stefano Pigozzi2014-12-01
| | | Should hopefully fix #1249 and #1279
* audio: allow more than 20 channel map entriesGravatar wm42014-12-01
| | | | | | | | | | | | | This could trigger an assertion when using ao_alsa or ao_coreaudio. The code was simply assuming the number of channel maps was bounded statically (which was true at first in both AOs). Fix by using dynamic memory allocation. It needs to be explicitly enabled by the AOs by setting a temp context, because otherwise the memory couldn't be freed. (Or at least this seems to be the most elegant solution.) Fixes #1306.
* ao/wasapi: make set_ao_format EX/EXTENSIBLE agnosticGravatar Kevin Mitchell2014-12-01
| | | | | | | | | There is no guarantee that closestMatch returned by IsFormatSupported is actually a WAVEFORMATEXTENSIBLE. http://msdn.microsoft.com/en-us/library/windows/desktop/dd370876%28v=vs.85%29.aspx We should therefore not blindly treat it as such.
* ao/wasapi: fix set_ao_formatGravatar Kevin Mitchell2014-12-01
| | | | | | | | | | | Before it used whatever was in ao->format and changed the bits even though this might have nothing to do with the actual WAVEFORMAT negotiated with WASAPI. For example, if the initial ao->format was a float and we had set the WAVEFORMAT to s24, this would create a non-existent float24 format. Worse, it might put an u16 into ao->format when WAVEFORMAT described s16. WASAPI doesn't support unsigned at all as far as I can tell.
* ao/wasapi: show actual waveformat triedGravatar Kevin Mitchell2014-12-01
| | | | also remove bogus ao_format
* ao/wasapi: don't assume 32-bits == floatGravatar Kevin Mitchell2014-12-01
| | | | | | | | | | This was based on old WAVEFORMATEX restrictions http://msdn.microsoft.com/en-us/library/windows/hardware/ff538799%28v=vs.85%29.aspx With the new WAVEFORMATEXTENSIBLE, this is no longer a problem. and we can have s32 or float32 so we need to actually check / set these correctly. fixes #1287
* ao/format: add af_fmt_is_floatGravatar Kevin Mitchell2014-12-01
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-29 10:30:10 +0000