summaryrefslogtreecommitdiffstats
path: root/audio
Commit message (Collapse)AuthorAgeFilesLines
* ao_alsa: explicitly add default device manuallywm42016-11-141-1/+4
| | | | | | | | | | | | | | The "default" entry (which is and always was mpv/mplayer's default) does not have a description set in the ALSA API. (While "sysdefault" strangely has.) Instead of an empty description, this should show something nice, so reuse the ao.c code for naming default devices (see previous commit). It's still a bit ugly that audio-device-list will have a default entry for "Autoselect device" and "Default (alsa)", but then again we probably want to allow the user to force ALSA (i.e. prevent fallbacks to other AOs) just because ALSA is so flaky and makes this a legitimate feature.
* audio: make empty device ID mean default devicewm42016-11-141-7/+14
| | | | | | | | | This will make it easier for AOs to add explicit default device entries. (See next commit.) Hopefully this change doesn't lead accidentally to bogus "Default" entries to appear, but then it can only happen if the device ID is empty, which would mean the underlying audio API returned bogus entries.
* audio: avoid returning audio-device-list entries without descriptionwm42016-11-141-0/+2
| | | | | | Use the device name as fallback. This is ugly, but still better than skipping the description entirely. This can be an issue on ALSA, where the API can return entries without proper description.
* dec_video, dec_audio: avoid full reinit on switches to the same segmentwm42016-11-091-6/+9
| | | | | | Same deal as with the previous commit. (Unfortunately, this code is still duplicated.)
* ao_alsa: fill unused ALSA channels with silencewm42016-11-081-0/+5
| | | | | | | | | | This happens when ALSA gives us more channels than we asked for, for whatever reasons. It looks like this wasn't handled correctly. The mpv and ALSA channel counts could mismatch, which would lead to UB. I couldn't actually trigger this case, though. I'm fairly sure that drivers or plugins exist that do it anyway. (Inofficial ALSA motto: if it can be broken, then why not break it?)
* ao_alsa: strictly disable chmap use for mono/stereowm42016-11-081-12/+21
| | | | | | | | | | If the input is already mono or stereo, or if channel map selection results in mono or stereo, then disable further use of the champ ALSA API (or rather, stop trusting its results). Then we behave like a simple application that only wants to output mono or stereo. See #3045 and #2905. I couldn't actually test these cases, but this commit is supposed to fix them.
* ao_alsa: _really_ disable chmap API use in cases where we shouldwm42016-11-081-3/+7
| | | | | | | | | | | set_chmap() skipped _setting_ the ALSA chmap if chmap use was requested to be disabled by setting dev_chmap.num=0 by the caller, but it still queried the current ALSA channel map. We don't trust it that much, so disable that as well. But we still query and log it, because that could be helpful for debugging. Otherwise we could skip the entire set_chmap() call in these cases.
* ao_alsa: slightly better debug loggingwm42016-11-081-6/+12
| | | | | | | Try to make it more compact, and also always list the reordered layout, but only if it's actually different. Should be the same functionally.
* audio/out: add AudioUnit output driver for iOSAman Gupta2016-11-016-5/+227
|
* ad_lavc, vd_lavc: fix a recent libavcodec deprecation warningwm42016-10-171-1/+2
| | | | | | | | | | | | | | Both AVFrame.pts and AVFrame.pkt_pts have existed for a long time. Until now, decoders always returned the pts via the pkt_pts field, while the pts field was used for encoding and libavfilter only. Recently, pkt_pts was deprecated, and pts was switched to always carry the pts. This means we have to be careful not to accidentally use the wrong field, depending on the libavcodec version. We have to explicitly check the version numbers. Of course the version numbers are completely idiotic, because idiotically the pkg-config and library names are the same for FFmpeg and Libav, so we have to deal with this explicitly as well.
* ao_alsa: try to fallback to "hdmi" before "iec958" for spdifwm42016-10-071-5/+10
| | | | | | | | | | | | | If the "default" device refuses to be opened as spdif device (i.e. it errors due to the AES0 etc. parameters), we were falling back to the iec958 device. This is needed on some systems for smooth operation with PCM vs. spdif. Now change it to try "hdmi" before "iec958", which supposedly helps in other situations. Better suggestions welcome. Apparently kodi does this too, although I didn't check directly.
* audio/out: prevent underruns with spdif under certain conditionswm42016-10-041-0/+2
| | | | | | | | | | | | | | | | | The player tries to avoid splitting frames with spdif (sample alignment stuff). This can in certain corner cases with certain drivers lead to the situation that ao_get_space() returns a number higher than 0 and lower than the audio frame size. The playloop will round this down to 0 bytes and do nothing, leading to a missed wakeup. This can lead to underruns or playback completely getting stuck. It can be reproduced by playing AC3 passthrough with no video and: --ao=null --ao-null-buffer=0.256 --ao-null-outburst=6100 This commit attempts to fix it by allowing the playloop to write some additional data (to get a complete frame), that will be buffered within the AO ringbuffer even if the audio device doesn't want it.
* audio: dump timestamp differencewm42016-10-021-1/+5
| | | | | Can help to analyze timestamp jitter or seeing completely bogus timestamps.
* win32: build with -DINITGUIDJames Ross-Gowan2016-09-282-2/+0
| | | | | | | | | | | | We always want to use __declspec(selectany) to declare GUIDs, but manually including <initguid.h> in every file that used GUIDs was error-prone. Since all <initguid.h> does is define INITGUID and include <guiddef.h>, we can remove all references to <initguid.h> and just compile with -DINITGUID to get the same effect. Also, this partially reverts 622bcb0 by re-adding libuuid.a to the build, since apparently some GUIDs (such as GUID_NULL) are not declared in the source file, even when INITGUID is set.
* ao_openal: enable building on OSXJosh de Kock2016-09-211-0/+14
| | | | Signed-off-by: Josh de Kock <josh@itanimul.li>
* af_pan: fix typoHector Martin2016-09-191-2/+3
| | | | | | | | | This was in the parser code all along. As far as I can tell, *cp was intended. There is no need to check cp for NULL (nor does it make any sense to do so every time around the loop) for AF_CONTROL_COMMAND. However, s->matrixstr can be NULL, so checking for that separately is in order.
* af_rubberband: default to channels=togetherHector Martin2016-09-191-0/+1
| | | | | | | | For stereo and typical L/R-first channel arrangements, this avoids undesirable phasing artifacts, especially obvious when speed is changed and then reset. Without this, there is a very audible change in the stereo field even when librubberband is no longer actually making any speed changes.
* af_rubberband: add af-command and option to change the pitchHector Martin2016-09-191-0/+25
| | | | | This allows both fixed and dynamic control over the audio pitch using librubberband, which was previously not exposed to the user.
* af_pan: add af-command support to change the matrixHector Martin2016-09-191-19/+31
| | | | | This allows for seamless changes in the downmixing matrix without having to reinitialize the filter chain.
* af_pan: coding style fixesHector Martin2016-09-191-103/+104
|
* options: simplify M_OPT_EXITwm42016-09-171-1/+1
| | | | | | | | | | | | | There were multiple values under M_OPT_EXIT (M_OPT_EXIT-n for n>=0). Somehow M_OPT_EXIT-n either meant error code n (with n==0 no error?), or the number of option valus consumed (0 or 1). The latter is MPlayer legacy, which left it to the option type parsers to determine whether an option took a value or not. All of this was changed in mpv, by requiring the user to use explicit syntax ("--opt=val" instead of "-opt val"). In any case, the n value wasn't even used (anymore), so rip this all out. Now M_OPT_EXIT-1 doesn't mean anything, and could be used by a new error code.
* player, ao, vo: don't call mp_input_wakeup() directlywm42016-09-165-23/+35
| | | | | | | | | | | | | Currently, calling mp_input_wakeup() will wake up the core thread (also called the playloop). This seems odd, but currently the core indeed calls mp_input_wait() when it has nothing more to do. It's done this way because MPlayer used input_ctx as central "mainloop". This is probably going to change. Remove direct calls to this function, and replace it with mp_wakeup_core() calls. ao and vo are changed to use opaque callbacks and not use input_ctx for this purpose. Other code already uses opaque callbacks, or has legitimate reasons to use input_ctx directly (such as sending actual user input).
* ao_rsound: fix compilationwm42016-09-071-1/+1
| | | | Probably fixes #3501.
* ao_pcm: remove some useless messageswm42016-09-071-2/+0
| | | | | | The first one is printed even if the user disabled video (or there's no video), so just remove it. The second one uses deprecated sub-option syntax, so remove that as well.
* osdep: rename atomics.h to atomic.hwm42016-09-075-5/+5
| | | | | The standard header is stdatomic.h, so the extra "s" freaks me out every time I look at it.
* audio/out: deprecate "exclusive" sub-optionswm42016-09-053-2/+10
| | | | | | | And introduce a global option which does this. Or more precisely, this deprecates the global wasapi and coreaudio options, and adds a new one that merges their functionality. (Due to the way the sub-option deprecation mechanism works, this is simpler.)
* audio/out: deprecate device sub-optionswm42016-09-058-8/+15
| | | | | We have --audio-device, which can force the device. Also add something describing to this extent to the manpage.
* options: deprecate suboptions for the remaining AO/VOswm42016-09-0511-0/+11
|
* options: add automagic hack for handling sub-option deprecationswm42016-09-052-0/+2
| | | | | | | | | | | | | | | | | I decided that it's too much work to convert all the VO/AOs to the new option system manually at once. So here's a shitty hack instead, which achieves almost the same thing. (The only user-visible difference is that e.g. --vo=name:help will list the sub-options normally, instead of showing them as deprecation placeholders. Also, the sub-option parser will verify each option normally, instead of deferring to the global option parser.) Another advantage is that once we drop the deprecated options, converting the remaining things will be easier, because we obviously don't need to add the compatibility hacks. Using this mechanism is separate in the next commit to keep the diff noise down.
* ao_jack: move to global optionswm42016-09-051-22/+42
|
* options: add a mechanism to make sub-option replacement slightly easierwm42016-09-053-1/+4
| | | | | | | | Instead of requiring each VO or AO to manually add members to MPOpts and the global option table, make it possible to register them automatically via vo_driver/ao_driver.global_opts members. This avoids modifying options.c/options.h every time, including having to duplicate the exact ifdeffery used to enable a driver.
* ao_alsa: change sub-options to global optionswm42016-09-023-31/+53
| | | | | | Same deal as with vo_opengl. Also edit the outdated information about multichannel output a little.
* m_config: add helper function for initializing af/ao/vf/vo suboptionswm42016-09-022-8/+8
| | | | | | | | Normally I'd prefer a bunch of smaller functions with fewer parameters over a single function with a lot of parameters. But future changes will require messing with the parameters in a slightly more complex way, so a combined function will be needed anyway. The now-unused "global" parameter is required for later as well.
* vo, ao: disable positional parameter suboptionswm42016-09-011-0/+1
| | | | | | | | | | | | | | | | Positional parameters cause problems because they can be ambiguous with flag options. If a flag option is removed or turned into a non-flag option, it'll usually be interpreted as value for the first sub-option (as positional parameter), resulting in very confusing error messages. This changes it into a simple "option not found" error. I don't expect that anyone really used positional parameters with --vo or --ao. Although the docs for --ao=pulse seem to encourage positional parameters for the host/sink options, which means it could possibly annoy some PulseAudio users. --vf and --af are still mostly used with positional parameters, so this must be a configurable option in the option parser.
* vd_lavc, ad_lavc: set pkt_timebase, not time_basewm42016-08-291-1/+4
| | | | | | | | | These are different AVCodecContext fields. pkt_timebase is the correct one for identifying the unit of packet/frame timestamps when decoding, while time_base is for encoding. Some decoders also overwrite the time_base field with some unrelated codec metadata. pkt_timebase does not exist in Libav, so an #if is required.
* ad_lavc: actually tell decoder about the timebasewm42016-08-231-0/+1
| | | | Essentially forgotten in commit 05e4df3f.
* ao_alsa: log if retrieving supported channel maps failswm42016-08-221-1/+3
| | | | It's a sign that the driver doesn't implement the channel map API.
* af_lavrresample: better swr reinitializationPaul B Mahol2016-08-201-4/+5
|
* af_lavrresample: fix error if resampler could not be recreatedwm42016-08-191-4/+5
| | | | | | | | There are situations where the resampler is destroyed and recreated during playback. If recreating the resampler unexpectedly fails, the filter function is supposed to return an error. This wasn't done correctly, because get_out_samples() accessed the resampler before the check. Move the check up to fix this.
* video/audio: always provide "proper" timestamps to libavcodecwm42016-08-191-1/+1
| | | | | | | | | | | | | | | | | | | Instead of passing through double float timestamps opaquely, pass real timestamps. Do so by always setting a valid timebase on the AVCodecContext for audio and video decoding. Specifically try not to round timestamps to a too coarse timebase, which could round off small adjustments to timestamps (such as for start time rebasing or demux_timeline). If the timebase is considered too coarse, make it finer. This gets rid of the need to do this specifically for some hardware decoding wrapper. The old method of passing through double timestamps was also a bit questionable. While libavcodec is not supposed to interpret timestamps at all if no timebase is provided, it was needlessly tricky. Also, it actually does compare them with AV_NOPTS_VALUE. This change will probably also reduce confusion in the future.
* audio: improve aspects of EOF handlingwm42016-08-182-0/+7
| | | | | | | | | | | The code actually kept going out of EOF mode into resync mode back into EOF mode when the playloop had to wait after an audio EOF caused by the endpts. This would break seamless looping (as added by the next commit). Apply endpts earlier, to ensure the filter_audio() function always returns AD_EOF in this case. The idiotic ao_buffer makes this an amazing pain in the ass.
* af_lavrresample: work around libswresample misbehaviorwm42016-08-161-10/+10
| | | | | | | | | | | | | | | | | | The touched code is for seek resets and such - we simply want to reset the entire resample state. But I noticed after a seek a tiny bit of audio is missing (mpv's audio sync code inserted silence to compensate). It turns out swr_drop_output() either does not reset some internal state as we expect, or it's designed to drop not only buffered samples, but also future samples. On the other hand, libavresample's avresample_read(), does not have this problem. (It is also pretty explicit in what it does - return/skip buffered data, nothing else.) Is the libswresample behavior a bug? Or a feature? Does nobody even know? Who cares - use the hammer to unfuck the situation. Destroy and deallocate the libswresample context and recreate it. On every seek.
* audio: log replaygain values in af_volume instead demuxerwm42016-08-131-6/+10
| | | | | | | The demuxer layer usually doesn't log per-stream information, and even the replaygain information was logged only if it came from tags. So log it in af_volume instead.
* audio/filter: remove delay audio filterPaul B Mahol2016-08-122-196/+0
| | | | Similar filter is available in libavfilter.
* ao_alsa: make pause state more robust, reduce minor code duplicationwm42016-08-091-22/+25
| | | | | | | | | With the previous commit, ao_alsa.c now has 3 possible ways to pause playback. Actually all 3 of them need get_delay() to fake its return value, so don't duplicate that code. Also much of the code looks a bit questionable when considering inconsistent pause/resume calls from outside, so ignore redundant calls.
* ao_alsa: handle --audio-stream-silencewm42016-08-091-9/+51
| | | | | | | | | | | | | | | | | push.c does not handle this automatically, and AOs using push.c have to handle it themselves. Also, ALSA is low-level enough that it needs explicit support in user code. At least I haven't found any option that does this. We still can get away relatively cheaply by abusing underflow-handling for this. ao_alsa.c already configures ALSA to handle underflows by playing silence. So we purposely induce an underflow when opening the device, as well as when pausing or resetting the device. This introduces minor misbehavior: it doesn't account for the additional delay the initial silence adds, unless the device has fully played the fragment of silence when the player starts sending data to it. But nobody cares.
* player: add --audio-stream-silencewm42016-08-094-2/+11
| | | | | Completely insane that this has to be done. Crap for compensating HDMI crap.
* ao_coreaudio: actually use stop callbackwm42016-08-092-2/+2
| | | | | | The .pause callback is never used for pull.c-based AOs. This means this always streamed silence instead of deactivating audio.
* af_lavcac3enc: allow passing options to libavcodecwm42016-08-091-0/+7
|
* ao_wasapi: in exclusive mode do not output multichannel by defaultwm42016-08-051-1/+1
| | | | | | | | Exactly the same situation as with ao_alsa in commit 0b144eac (except that we can detect the situation better under wasapi). Essentially, wasapi will allow us to output any sample format, and not just the one configured by the user in the audio system settings.
* ao_null: use channel list option type for channel-layouts suboptionwm42016-08-051-11/+5
|
* audio: use --audio-channels=auto behavior, except on ALSAwm42016-08-049-18/+68
| | | | | | | | | | | | | | | | | | | | | | | This commit adds an --audio-channel=auto-safe mode, and makes it the default. This mode behaves like "auto" with most AOs, except with ao_alsa. The intention is to allow multichannel output by default on sane APIs. ALSA is not sane as in it's so low level that it will e.g. configure any layout over HDMI, even if the connected A/V receiver does not support it. The HDMI fuckup is of course not ALSA's fault, but other audio APIs normally isolate applications from dealing with this and require the user to globally configure the correct output layout. This will help with other AOs too. ao_lavc (encoding) is changed to the new semantics as well, because it used to force stereo (perhaps because encoding mode is supposed to produce safe files for crap devices?). Exclusive mode output on Windows might need to be adjusted accordingly, as it grants the same kind of low level access as ALSA (requires more research). In addition to the things mentioned above, the --audio-channels option is extended to accept a set of channel layouts. This is supposed to be the correct way to configure mpv ALSA multichannel output. You need to put a list of channel layouts that your A/V receiver supports.
* player: remove special-case for DL/DR speakerswm42016-08-042-41/+0
| | | | | | Pointless anyway. With superficial checking I couldn't find any decoder which actually outputs this, and AO chmap negotiation would properly ignore them anyway in most cases.
* af_lavcac3enc: skip output if there was no input framewm42016-08-021-0/+3
| | | | Unrealistic corner case: drainning was initiated right after a seek.
* af_lavcac3enc: fix buffering timestamps calculationswm42016-08-011-3/+9
| | | | In theory, an encoder could buffer some data.
* af_lavcac3enc: fix memory leakwm42016-08-011-1/+1
| | | | A major one. Oops.
* af_lavcac3enc: fix a debug messagewm42016-07-311-1/+1
|
* af_lavcac3enc: error out properly if encoding failswm42016-07-311-0/+4
|
* af_lavcac3enc: fix aspects of AVFrame handlingwm42016-07-311-0/+3
| | | | | | | | | | We send a refcounted frame to the encoder, but then disrespect refcounting rules and write to the frame data without making sure the buffer is really writeable. In theory this can lead to reallocation on every frame is the encoder really keeps a reference. If we really cared, we could fix this by providing a buffer pool. But then again, we don't care.
* audio: make mp_audio_realloc[_min] ensure frame is writeablewm42016-07-311-1/+10
| | | | | | | | This is logical: the function makes sense only in situations where you are going to write to the audio data. To make it worse, av_buffer_realloc() also handles this situation, but only if the buffer size changes (simply because it can't realloc memory in use), so we have to explicitly force reallocation by unreffing the buffers first.
* osdep/io: introduce mp_flush_wakeup_pipe()Rostislav Pehlivanov2016-07-301