summaryrefslogtreecommitdiffstats
path: root/audio
Commit message (Collapse)AuthorAgeFilesLines
* 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-254-10/+30
| | | | | 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.)
* audio: fix channel map fallback selection (again)wm42015-06-251-36/+61
| | | | | | | | | | | | | | | | | | | | The speaker replacement nonsense sometimes made blatantly incorrect decisions. In this case, it prefered a 7.1(rear) upmix over outputting 5.1(side) as 5.1, which makes no sense at all. This happened because 5.1 and 7.1(rear) appeared equivalent to the final selection, as both of them lose the sl-sr channels. The old code was too stupid to select the one with the lower number of channels as well. Redo this. There's really no reason why there should be a separate final decision, so move the speaker replacement logic into the mp_chmap_is_better() function. Improve some other details. For example, we never should compare the plain number of channels for deciding upmix/downmix, because due to NA channels this is essentially meaningless. Remove the NA channels when doing this comparison. Also, explicitly handle exact matches. Conceptually this is not necessary, but it avoids that we have to needlessly shuffle audio data around.
* ao: standardize channel layout name in debug output furtherwm42015-06-251-0/+2
|
* af: move af_from_dB() function to af_volume.cwm42015-06-233-22/+11
| | | | | And also simplify it (it certainly had the most awkward API you could think of for such a simple function).
* af_volume: add a replaygain fallback optionwm42015-06-231-0/+5
|
* af_lavrresample: free and reallocate resample context on reconfigwm42015-06-221-30/+35
| | | | | | | | This avoids keeping "bad" state from previous reconfig calls, such as the internal_sample_format option (which is set only on the first reconfig call). There's no advantage to keeping the resample contexts around anyway.
* af_lavrresample: fix commentwm42015-06-221-4/+4
| | | | | mp_format is not a libavresample input format here, and the comment was more confusing than it helped.
* af: restore detaching of PCM filters when using spdifwm42015-06-223-1/+14
| | | | | | Basically, af_fix_format_conversion() behaves stupid you insert a conversion filter that won't work, and adding back the conversion test function is the simplest fix to it.
* af_lavrresample: don't flush in uninitialized statewm42015-06-221-1/+2
| | | | libswresample verbosely complains.
* 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.
* demux: merge extradata fieldswm42015-06-211-5/+1
| | | | | | | MPlayer traditionally had completely separate sh_ structs for audio/video/subs, without a good way to share fields. This meant that fields shared across all these headers had to be duplicated. This commit deduplicates essentially the last remaining duplicated fields.
* demux: rename sh_stream.format to sh_stream.codec_tagwm42015-06-211-1/+1
| | | | | Why not. "format" sounds too misleading for the actual importance and meaning of this field.
* Various spelling fixesMarcin Kurczewski2015-06-188-13/+13
| | | | 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.
* af_lavrresample: include osdep/endian.hwm42015-06-171-0/+1
| | | | The 24 bit conversion code needs the relevant preprocessor symbols.
* af: remove conversion filter searchwm42015-06-163-94/+4
| | | | | | This attempted to find a minimal filter graph for a format conversion involving multiple conversion filters. With the last 2 commits it becomes dead code - remove it.
* af_convert24: remove this filterwm42015-06-162-123/+0
|
* af_lavrresample: integrate 24 bit (3 bytes per sample) outputwm42015-06-161-9/+48
| | | | | | | | | | | | Now af_lavrresample can output 24 bit samples directly, by doing the conversion "inline". Luckily, S32->S24 can be done in-place, so this isn't too much work. But the output conversion logic (which seems to be adding up) gets slightly more complicated again. Normally this is done by af_convert24. But having multiple conversion filters complicates some aspects of the filter chain. S24 output is the only thing the code for multiple conversion filters is still needed for, and getting rid of that is preferable.
* af_lavrresample: always fill reorderwm42015-06-161-1/+1
| | | | | | If the code path for additional output conversion is active, reorder_planes() is always called, even if the reorder_out array wasn't filled. This is obviously wrong - always fill this array.
* audio: remove S8, U16, U24, U32 formatswm42015-06-1612-197/+26
| | | | | | | | | | | | | 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.
* audio: fix crash on uninitwm42015-06-151-1/+1
| | | | Shit.
* af_lavcac3enc: fix A/V syncwm42015-06-151-3/+17
| | | | | | The filter can buffer singificant amounts of audio. (The proper fix is making the filter chain PTS-aware.)
* af: fix an aspect of filter chain flushingwm42015-06-151-0/+11
| | | | | Even if we flush the current filter, we have to read the remaining output from the frame we previously fed to the filter.
* audio: remove unused readonly fieldwm42015-06-152-3/+1
| | | | Its last use was removed in 433402b5.
* chmap: make up some channel layout nameswm42015-06-121-0/+3
| | | | | Going by the existing names, these should make sense. HDMI knows about these layouts, but does not name them.
* 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.
* chmap_sel: improve speaker replacement handlingwm42015-06-121-17/+33
| | | | | This didn't really work since the last time the channel map fallback code was touched. In some cases, quite bad results were selected.
* chmap_sel: do naive speaker replacements lastwm42015-06-121-3/+4
| | | | | This prevents that the potentially better pick by mp_chmap_sel_fallback() is overridden.
* audio: fill NA channels with silencewm42015-06-121-11/+29
| | | | | | | | | | | | | | | Until now, we didn't do this, because it required some effort, and didn't seem to be necessary. It probably still isn't, but it sounds like a good idea not to output arbitrary data on these channels. The situation is complicated by the fact that just adding new channels to a planar frame would require messing with buffers. So we would have to allocate new buffers and add them to the frame. We could have to maintain an extra buffer pool for this. Avoid this by being "clever", and just allocate a frame with enough channels in the first place. libav/swresample won't know about these channels and won't write to them, but we can grab them in reorder_planes() and use them for the NA channels.
* audio: use unknown channel layouts if there is no standard layoutwm42015-06-121-5/+5
| | | | | | | | | This is just a conceptual issue, since for now every channel count has an associated standard layout. But should the max. channel count ever be bumped, some things would stop function if mp_chmap_from_channels() refused to work for any channel count within the allowed range.
* audio: fix messed up channel reorderingwm42015-06-121-2/+2
| | | | Quite a blunder, really.
* audio: deal with AVFrame-style buffer assignmentswm42015-06-122-4/+17
| | | | | | | | | | | | | | | | In the AVFrame-style system (which we inreasingly map our internal data stuctures on), buffers and plane pointers don't necessarily have a 1:1 correspondence. For example, a single buffer could cover 2 or more planes, all while other planes are covered by a second buffer, and so on. They don't need to be ordered in the same way. Change mp_audio_get_allocated_size() to retrieve the maximum size all planes provide. This also considers the case of planes not pointing to buffer start. Change mp_audio_realloc() to reset all planes, even if corresponding buffers are not reallocated. (The caller has to be careful anyway if it wants to be sure the contents are preserved on realloc calls.)
* 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-091-1/+1
| | | | | | | | If a frame could only be partially filled with real audio data, the silence wasn't written at the correct offset. It could have happened that the remainder of the frame contained garbage. (This didn't happen in the more common case of playing dummy silence.)
* ao_alsa: refine channel count mismatch error messagewm42015-06-091-2/+2
| | | | I suspect we need to hand this more gracefully in some cases.
* audio: add --audio-spdif as new method for enabling passthroughwm42015-06-052-8/+21
| | | | | | | | | | | | | This provides a new method for enabling spdif passthrough. The old method via --ad (--ad=spdif:ac3 etc.) is deprecated. The deprecated method will probably stop working at some point. This also supports PCM fallback. One caveat is that it will lose at least 1 audio packet in doing so. (I don't care enough to prevent this.) (This is named after the old S/PDIF connector, because it uses the same underlying technology as far as the higher level protoco is concerned. Also, the user should be renamed that passthrough is backwards.)
* ad_spdif: use a pseudo codec entry to select DTS-HD instead of an optionwm42015-06-051-1/+10
| | | | | | | | | This deprecates the --ad-spdif-dtshd option, and replaces it with a pseudo decoder. This means ad_spdif will report two decoders, "dts" and "dts-hd", of which the second simply enables what the option did. The --ad-spdif-dtshd option will actually be deprecated in the next commit.
* ao_alsa: refuse to use spdif if AES flags can't be setwm42015-06-041-6/+6
| | | | | Seems like a good idea to avoid accidentally playing noise by writing spdif data to pure PCM devices.
* af_lavrresample: slightly better computation of total delaywm42015-06-041-6/+9
| | | | | | | On libavresample, don't ignore the buffered output data. On libswresample, don't round the total buffer size to the input samplerate.
* af_lavrresample: use a new libswresample function if availablewm42015-06-041-0/+4
| | | | | It was recently added to libswresample, and it does exactly what we need.
* af_lavrresample: change output samples calculationwm42015-06-041-2/+2
| | | | | | This is better, because now we call swr_get_delay() with the output samplerate, instead of with the input samplerate and then multiplying it with the ratio and rounding it up.
* ao_alsa: hack against potential spdif failurewm42015-06-041-3/+16
|
* af_lavrresample: use native libavresample function for output sizewm42015-06-021-7/+6
| | | | This also drops the unused get_drain_samples() function.
* ao_coreaudio_exclusive: move generic functions to utilswm42015-06-023-207/+209
|
* ao_coreaudio_exclusive: react to device removalwm42015-06-021-12/+27
| | | | | | | | | | | | | | Listening to kAudioDevicePropertyDeviceHasChanged does not send any property change notifications when the device dies. Makes no sense, but I suppose in CoreAudio logic a dead/removed device can't send any notifications. This caused the player to essentially pause playback if the audio device was removed during playback. Fix by listening to the kAudioHardwarePropertyDevices property too, which will actually be sent in this specific case. Then, if querying the already dead device fails, we know we have to reload.
* ao_coreaudio_exclusive: make property listeners event-basedwm42015-06-021-105/+82
| | | | | | | | | | | | | | | | In short, instead of letting the coreaudio property listener set atomic flags (which are then polled), make the property listeners actually active. The format change listener used during audio output now simply calls ao_request_reload() on its own. All code involved is thread-safe, so there's no need to do it during this audio callback (we assumed the callback was never run concurrently with itself). The listener installed temporarily during ca_change_format() is changed to post a semaphore. Get rid of the weird retry logic and replace it with a flat loop + timeout. It appears the maximum wait time could be 2500ms; reduce the total timeout to 500ms instead.
* ao: allow ao_uninit(NULL)wm42015-06-021-1/+2
|
* af_lavrresample: fix and simplify flushing on playback speed changewm42015-06-021-23/+1
| | | | | | | | | | | This manually retrieved the remaining audio from the resampler. It subtly missed a conversion which could leave to an unsubtle crash. This could happen if reorder_planes() was supposed to insert NA channels, and the resampler/actual output format were different. Simplify it by reusing the normal drain path. One oddness is that the filter will add an output frame outside of normal filtering, but that should be fine.
* ao_alsa: hack back mono outputwm42015-05-251-1/+6
| | | | | The ALSA API is inconsistent and doesn't report support. Just requesting 1 channel actually works. Whatever.
* audio: make softvol scale cubicwm42015-05-221-2/+5
| | | | | | | | This brings the volume control closer to what is percepted as linear volume change. Adjust the --softvol-max default to roughly the old maximum (roughly doubles the gain).
* audio: change range of volume option/propertywm42015-05-222-16/+15
| | | | | | | | | Now --volume takes an absolute volume, meaning it doesn't depend on --softvol-max. 0 is still silence, and 100 now always means unchanged volume. The OSD and the "volume" property are changed accordingly. Also raise the minimum value of --softvol-max. A value below 100 makes no sense and breaks the OSD.
* chmap: use av_popcount64()wm42015-05-211-9/+3
| | | | Saves us some code, and also happens to fix #1968.
* ad_spdif: use DTS-HD passthrough only if the audio is really DTS-HDwm42015-05-191-4/+54
| | | | | | | | | | | | | | | | | | | | | | | Apparently some A/V receivers do not behave well if "normal" DTS is passed through using the high bitrate spdif format normally used for DTS-HD (other receivers are fine with it). Parse the first packet passed to ad_spdif by decoding it with libavcodec in order to get the profile. Ignore the --ad-spdif-dtshd if it's not DTS-HD. (If the codec profile changes midstream, the user is out of luck. But this is probably an insignificant corner case.) I thought about parsing the bitstream, but let's not. While it probably wouldn't be that much effort, we are trying to keep it down on codec details here - otherwise we could just do our own spdif framing instead of using libavformat's spdif pseudo-muxer. Another possibility, using the codec parameters signalled by libavformat, is disregarded. Our builtin Matroska decoder doesn't do this, and also we do not want on the demuxer having to decode some packets in order to retrieve codec params (as libavformat does). Fixes #1949.
* ad_spdif: set output format lazilywm42015-05-191-15/+27
| | | | | Preparation for the following commit, which looks at the packet data before deciding what to output.
* threads: use utility+POSIX functions instead of weird wrapperswm42015-05-111-3/+6
| | | | | | | There is not much of a reason to have these wrappers around. Use POSIX standard functions directly, and use a separate utility function to take care of the timespec calculations. (Course POSIX for using this weird format for time values.)
* ao: make better use of atomicswm42015-05-112-14/+11
| | | | | The main reason for this was compatibility; but some associated problems have been solved in the previous commit.
* audio: simplify furtherwm42015-05-082-16/+8
| | | | | | Drop mp_chmap_diff() (which is unused too now), and implement mp_chmap_diffn() in a slightly simpler way. (Too bad there is no standard function for counting set bits.)
* audio: remove mp_chmap_contains()wm42015-05-082-12/+0
| | | |