summaryrefslogtreecommitdiffstats
path: root/audio
Commit message (Collapse)AuthorAgeFilesLines
* 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-4/+2
| | | | Makes a fairly common occurence with wakeup_pipes easier to handle.
* audio: use idiotic FFmpeg ABI rules for public-except-not-public fieldswm42016-07-241-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FFmpeg API is incredibly weird and inconsistent about this. This is also a FFmpeg-only issue and nothing like this is in Libav - which doesn't really show FFmpeg in a very positive light. (To make it even worse: this is a full-blown Libav API incompatibility, even though this crap was added for Libav ABI-compatibility. It's absurd.) Quoting the FFmpeg header for the AVFrame.channels field: /** * number of audio channels, only used for audio. * Code outside libavutil should access this field using: * av_frame_get_channels(frame) * - encoding: unused * - decoding: Read by user. */ int channels; It says "should" not must, and it doesn't even mention av_frame_set_channels(). It's also in the section for public fields (not below a marker that indicates private fields in a public struct, like it's done e.g. in AVCodecContext). But not using the accessor will cause silent failures on ABI changes. The failure that happened due to this code didn't even make it apparent what was wrong. So just use the idiotic accessor. Also harmonize the FFmpeg-cursing in the code. (It's fully justified.) Fixes #3295. Note that mpv will still check the exact library version numbers, and reject mismatches - to protect itself from such issues in the future.
* af_lavcac3enc: use common code for AVFrame setupwm42016-07-243-16/+22
|
* audio: refactor mixer code and delete mixer.cwm42016-07-172-190/+0
| | | | | | | | | | | | | | | | | mixer.c didn't really deserve to be separate anymore, as half of its contents were unnecessary glue code after recent changes. It also created a weird split between audio.c and af.c due to the fact that mixer.c could insert audio filters. With the code being in audio.c directly, together with other code that unserts filters during runtime, it will be possible to cleanup this code a bit and make it work like the video filter code. As part of this change, make the balance code work like the volume code, and add an option to back the current balance value. Also, since the balance semantics are unexpected for most users (panning between the audio channels, instead of just changing the relative volume), and there are some other volumes, formally deprecate both the old property and the new option.
* audio: fix crashes due to broken uninit checkwm42016-07-151-5/+0
| | | | | | Since mixer->ao is always NULL now (it was really just forgotten to be removed), the uninit call never actually cleared the af field, leaving a dangling pointer that could be accessed by volume control.
* af: avoid rebuilding filter chain in another minor casewm42016-07-151-0/+3
| | | | | No need to create additional noise of we can trivially see that rebuiding the chain won't change anything.
* ao_pulse: fix some volume control rounding issueswm42016-07-141-2/+3
| | | | | Volume could get easily "stuck" or making too huge steps when doing things like "add ao-volume 1".
* ao_creoaudio: print OSStatus as decimal signed integer toowm42016-07-131-1/+1
| | | | | OSStatus is quite inconsistent. Sometimes it's a FourCC, sometimes it reads as decimal signed number.
* ao_coreaudio: use correct free function on errorswm42016-07-131-1/+1
|
* audio: fix code for adjusting conversion filterswm42016-07-111-4/+5
| | | | | | | | | | | | | | | This code was supposed to adjust existing conversion filters (to make them output a different format). But the code was just broken, apparently a refactoring accident. It accessed af instead of af->prev. The bug tended to add new conversion filters, even if an existing one could have been used. (Can be tested by inserting a dummy lavrresample filter followed by a format filter which forces conversion.) In addition, it's probably better to return the actual error code if reinitializing the filter fails. It would then respect an AF_FALSE return value, which means format negotiation failed, instead of a generic error.
* af_volume: don't let softvol overwrite af_volume volumedb sub-optionwm42016-07-111-2/+2
| | | | | | | | | | af_volume has a volumedb sub-option, which allows the user to set an explicit volume. Until recently, the player read back this value and used it as initial softvol volume. But now it just overwrites it. Instead of overwriting it, multiply the different gain values. Above all, this will do the right thing if only softvol is used, or if the user only adds the af_volume filter manually.
* audio: add heuristic to move auto-downmixing before other filterswm42016-07-101-7/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally, you want downmixing to happen first thing in the filter chain. This is reflected in codec downmixing, which feeds the filter chain downmixed audio in the first place. Doing this has the advantage of needing less data to process. But the main motivation is that if there is a drc filter in the chain, you want to process it the downmixed audio. Add an idiotic heuristic to achieve this. It tries to detect whether the audio was indeed automatically downmixed (or upmixed). To detect what the output format is going to be, it builds the filter chain normally, and then retries with the heuristic applied (and for extra paranoia, retries without the heuristic again if it fails to successfully rebuild the filter chain for unknown reasons). This is simple and will work in almost all cases. Doing it in a more complete way is rather hard, because filters are so generic. For example, we know absolutely nothing about the behavior of af_lavfi, which creates an opaque filter graph with libavfilter. We don't know why a filter would e.g. change the channel layout on its output. (Our heuristic bails out in this case.) We're also slave to the lowest common denominator of how our format negotiation works, and how libavfilter's works. In theory, we could make this mechanism explicit by introducing a special dummy filter. The filter chain would then try to convert between input and output formats at the dummy filter, which would give the user more control over how downmix happens. On the other hand, the user could just insert explicit conversion filters instead, so this would probably have questionable value.
* audio: add auto-inserted flag to filter list loggingwm42016-07-101-0/+2
| | | | Like the video filter chain.
* audio: cleanup audio filter format negotiationwm42016-07-103-149/+62
| | | | | | | | | | | | | | | | | | The algorithm and functionality is the same, but the code becomes much simpler and easier to follow. The assumption that there is only 1 conversion filter (lavrresample) helps with the simplification, but the main change is to use the same code for format/channels/rate. Get rid of the different AF_CONTROL_SET_* controls, and change the af->data parameters directly. (af->data is badly named, but essentially is a placeholder for the output format.) Also, instead of trying to use the af_reinit() loop to init inserted conversion filters or filters with changed output formats, do it inline, and move the common code to a filter_reinit() function. This gets rid of the awful retry variable. In general, this should not change any runtime behavior.
* audio: insert audio-inserted filters at end of chainwm42016-07-091-34/+1
| | | | | | This happens to be better for the af_volume filter (for softvol), and saves some code too. It's "better" because you want to affect the final filtered audio, such as after a manually inserted drc filter.
* audio: don't crash when changing volume if no audio is initializedwm42016-07-091-0/+3
| | | | Oversight.
* audio: drop --softvol=no and --softvol=autowm42016-07-092-275/+14
| | | | | | | | | | | | | | Drop the code for switching the volume options and properties between af_volume and AO volume controls. interface-changes.rst mentions the changes in detail. Do this because this was exceedingly complex and had other problems as well. It was also very hard to test. It's just not worth the trouble. Some leftovers like AOCONTROL_HAS_PER_APP_VOLUME will be removed at a later point. Fixes #3322.
* ao_coreaudio: error out when selecting invalid devicewm42016-07-081-0/+7
| | | | | | | | | | | | | | | | When selecting a device that simply doesn't exist with --audio-device, AudioUnit will still initialize and start playback without complaining. But it will never call the audio render callback, which leads to audio playback simply not progressing. I couldn't find a way to get AudioUnit to report an error at all, so here's a crappy hack that takes care of this in most cases. We assume that all devices have a kAudioDevicePropertyDeviceIsAlive property. Invalid devices will error when querying the property (with 'obj!' as status code). This is not the correct fix, because we try to double-guess AudioUnit's behavior by accessing a lower label API. Suggestions welcome.
* vf, af: print filter labels in verbose modewm42016-07-061-0/+2
|
* ad_lavc: work around braindead ffmpeg behaviorwm42016-07-011-0/+6
| | | | | | | | | | | | | | | | | | | | | The libavcodec wmapro decoder will skip some bytes at the start of the first packet and return each time. It will not return any audio data in this state. Our own code as well as libavcodec's new API handling (avcodec_send_packet() etc.) discard the PTS on the first return, which means the PTS is never known for the first packet. This results in a "Failed audio resync." message. Fixy it by remember the PTS in next_pts. This field is used only if the decoder outputs no PTS, and is updated after each frame - and thus should be safe to set. (Possibly this should be fixed in libavcodec new API handling by not setting the PTS to NOPTS as long as no real data has been output. It could even interpolate the PTS if the timebase is known.) Fixes the failure message seen in #3297.
* ao_oss: do not add an entry to audio-device-list if device file missingwm42016-06-291-0/+7
| | | | | This effectively makes it go away on Linux (unless you have OSS emulation loaded).
* audio: don't add default entry to audio-device-list if AO support listingwm42016-06-291-3/+2
| | | | | | | In such cases there isn't really a reason to do so, and using such an entry would probably fail anyway. Also convenient for the following commit.
* audio: add a helper for getting frame end PTSwm42016-06-272-2/+11
| | | | Although I don't see any use for it yet, why not.
* dec_audio: fix segment boudnary switchingwm42016-06-271-3/+6
| | | | | | | | | | | | | Some bugs in this code are exposed by e.g. playing lossless audio files with --ad-lavc-threads=16. (libavcodec doesn't really support threaded audio decoding, except for lossless files.) In these cases, a major amount of audio can be buffered, which makes incorrect handling of this buffering obvious. For one, draining the decoder can take a while, so if there's a new segment, we shouldn't read audio. The segment end check was completely wrong, and used the start value.
* ao_lavc, vo_lavc: Migrate to new encoding API.Rudolf Polzer2016-06-271-76/+121
| | | | | Also marked some places for possible later refactoring, as they became quite similar in this commit.
* Fix misspellingsstepshal2016-06-263-3/+3
|
* af_lavcac3enc: use av_err2str() call (fixes Libav build)wm42016-06-231-2/+1
| | | | | I added this call because I thought it'd be nice, but Libav doesn't have this function (macro, actually).
* af_lavcac3enc: make encoder configurablewm42016-06-231-2/+5
|
* af_lavcac3enc: implement flushing on seekwm42016-06-231-0/+7
| | | | | There's a lot of data that could have been buffered, and which has to be discarded.
* af_lavcac3enc: port to new encode APIwm42016-06-231-9/+57
|
* af_lavcac3enc: automatically configure most encoder parameterswm42016-06-231-29/+57
| | | | | | | | | | | Instead of hardcoding what the libavcodec ac3 encoder expects, configure it based on the AVCodec fields. Unfortunately, it doesn't export the list of sample rates, so that is done manually. This commit actually fixes the rate always to 48Khz. I don't even know whether the other rates worked. (Possibly did, but they'd still change the spdif parameters, and would work differently from ad_spdif.c.)
* af_lavcac3enc: drop log message prefixeswm42016-06-231-9/+7
| | | | MPlayer leftover. They're already added by the logging code.
* af_lavcac3enc: fix custom bitrateswm42016-06-231-2/+3
| | | | | | Probably has been broken for ages. (Not sure why anyone would use this feature, though.)
* ad_lavc: resume from mid-stream EOF conditions with new decode APIwm42016-06-221-0/+7
| | | | | | | | | | | | | | | | Workaround for an awful corner-case. The new decode API "locks" the decoder into the EOF state once a drain packet has been sent. The problem starts with a file containing a 0-sized packet, which is interpreted as drain packet. This should probably be changed in libavcodec (not treating 0-sized packets as drain packets with the new API) or in libavformat (discard 0-sized packets as invalid), but efforts to do so have been fruitless. Note that vd_lavc.c already does something similar, but originally for other reasons. Fixes #3106.
* audio: apply an upper bound timeout when drainingwm42016-06-121-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | This helps with shitty APIs and even shittier drivers (I'm looking at you, ALSA). Sometimes they won't send proper wakeups. This can be fine during playback, when for example playing video, because mpv still will wakeup the AO outside of its own wakeup mechanisms when sending new data to it. But when draining, it entirely relies on the driver's wakeup mechanism. So when the driver wakeup mechanism didn't work, it could hard freeze while waiting for the audio thread to play the rest of the data. Avoid this by waiting for an upper bound. We set this upper bound at the total mpv audio buffer size plus 1 second. We don't use the get_delay value, because the audio API could return crap for it, and we're being paranoid here. I couldn't confirm whether this works correctly, because my driver issue fixed itself. (In the case that happened to me, the driver somehow stopped getting interrupts. aplay froze instead of playing audio, and playing audio-only files resulted in a chop party. Video worked, for reasons mentioned above, but drainign froze hard. The driver problem was solved when closing all audio output streams in the system. Might have been a dmix related problem too.)
* audio: do not wake up core during EOFwm42016-06-121-3/+4
| | | | | | | | | | | | | When we're draining, don't wakeup the core on every buffer fill, since unlike during normal playback, we won't actually get more data. The wakeup here conceptually works like wakeups with condition variables, so redundant wakeups do not hurt, so this is just a minor change and nothing of consequence. (Final EOF also requires waking up the core, but there is separate code to send this notification.) Also dump the p->still_playing field in trace logging.
* build: silence -Wunused-resultNiklas Haas2016-06-072-3/+3
| | | | | | | | For clang, it's enough to just put (void) around usages we are intentionally ignoring the result of. Since GCC does not seem to want to respect this decision, we are forced to disable the warning globally.
* ao_wasapi: initialize COM in main thread with MTAKevin Mitchell2016-06-051-2/+2
| | | | | | Since the main thread is shared by other things in the player, using STA (single threaded aparement) may have caused problems. Instead initialize in MTA (multithreaded apartment).
* ao_opensles: remove 32bit audioJosh de Kock2016-05-221-1/+0
| | | | It's unsupported by android, and can cause problems when trying to play 32bit audio. Removing 32bit fixes it by forcing 16 bit or 8 bit audio.
* ao_alsa: add more shitty workaroundswm42016-05-061-9/+25
| | | | | | | | | | | | | | | This reportedly makes it work on ODROID-C2. The idea for this hack is taken from kodi; they unconditionally set some or all of those flags. I don't trust ALSA enough to hope that setting these flags couldn't break something else, so we try without them first. It's not clear whether this is a driver bug or a bug in the ALSA libs. There is