summaryrefslogtreecommitdiffstats
path: root/audio/out/ao.h
Commit message (Collapse)AuthorAgeFilesLines
* encode: get rid of the output packet queuewm42018-05-031-0/+3
| | | | | | | | | | | | Until recently, ao_lavc and vo_lavc started encoding whenever the core happened to send them data. Since audio and video are not initialized at the same time, and the muxer was not necessarily opened when the first encoder started to produce data, the resulting packets were put into a queue. As soon as the muxer was opened, the queue was flushed. Change this to make the core wait with sending data until all encoders are initialized. This has the advantage that we don't need to queue up the packets.
* audio: add audio softvol processing to AOwm42017-11-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This does what af_volume used to do. Since we couldn't relicense it, just rewrite it. Since we don't have a new filter mechanism yet, and the libavfilter is too inconvenient, do applying the volume gain in ao.c directly. This is done before handling the audio data to the driver. Since push.c runs a separate thread, and pull.c is called asynchronously from the audio driver's thread, the volume value needs to be synchronized. There's no existing central mutex, so do some shit with atomics. Since there's no atomic_float type predefined (which is at least needed when using the legacy wrapper), do some nonsense about reinterpret casting the float value to an int for the purpose of atomic access. Not sure if using memcpy() is undefined behavior, but for now I don't care. The advantage of not using a filter is lower complexity (no filter auto insertion), and lower latency (gain processing is done after our internal audio buffer of at least 200ms). Disavdantages include inability to use native volume control _before_ other filters with custom filter chains, and the need to add new processing for each new sample type. Since this doesn't reuse any of the old GPL code, nor does indirectly rely on it, volume and replaygain handling now works in LGPL mode. How to process the gain is inspired by libavfilter's af_volume (LGPL). In particular, we use exactly the same rounding, and we quantize processing for integer sample types by 256 steps. Some of libavfilter's copyright may or may not apply, but I think not, and it's the same license anyway.
* command: drop "audio-out-detected-device" propertywm42017-10-091-1/+0
| | | | | | Coreaudio stopped setting it a few releases ago (66a958bb4fa). There is not much of a user- or API-visible change, so remove it without deprecation.
* audio: introduce a new type to hold audio frameswm42017-08-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is pretty pointless, but I believe it allows us to claim that the new code is not affected by the copyright of the old code. This is needed, because the original mp_audio struct was written by someone who has disagreed with LGPL relicensing (it was called af_data at the time, and was defined in af.h). The "GPL'ed" struct contents that surive are pretty trivial: just the data pointer, and some metadata like the format, samplerate, etc. - but at least in this case, any new code would be extremely similar anyway, and I'm not really sure whether it's OK to claim different copyright. So what we do is we just use AVFrame (which of course is LGPL with 100% certainty), and add some accessors around it to adapt it to mpv conventions. Also, this gets rid of some annoying conventions of mp_audio, like the struct fields that require using an accessor to write to them anyway. For the most part, this change is only dumb replacements of mp_audio related functions and fields. One minor actual change is that you can't allocate the new type on the stack anymore. Some code still uses mp_audio. All audio filter code will be deleted, so it makes no sense to convert this code. (Audio filters which are LGPL and which we keep will have to be ported to a new filter infrastructure anyway.) player/audio.c uses it because it interacts with the old filter code. push.c has some complex use of mp_audio and mp_audio_buffer, but this and pull.c will most likely be rewritten to do something else.
* audio/out: change license of some core files to LGPLwm42017-05-201-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | All contributors of the current code have agreed. ao.c requires a "driver" entry for each audio output - we assume that if someone who didn't agree to LGPL added a line, it's fine for ao.c to be LGPL anyway. If the affected audio output is not disabled at compilation time, the resulting binary will be GPL anyway, and ootherwise the code is not included. The audio output code itself was inspired or partially copied from libao in 7a2eec4b59f4 (thus why MPlayer's audio code is named libao2). Just to be sure we got permission from Aaron Holtzman, Jack Moffitt, and Stan Seibert, who according to libao's SVN history and README are the initial author. (Something similar was done for libvo, although the commit relicensing it forgot to mention it.) 242aa6ebd40: anders mostly disagreed with the LGPL relicensing, but we got permission for this particular commit. 0ef8e555735: nick could not be reached, but the include statement was removed again anyway. 879e05a7c17: iive agreed to LGPL v3+ only, but this line of code was removed anyway, so ao_null.c can be LGPL v2.1+. 9dd8f241ac2: patch author could not be reached, but the corresponding code (old slave mode interface) was completely removed later.
* player, ao, vo: don't call mp_input_wakeup() directlywm42016-09-161-2/+3
| | | | | | | | | | | | | 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).
* audio/out: deprecate "exclusive" sub-optionswm42016-09-051-0/+2
| | | | | | | 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.)
* player: add --audio-stream-silencewm42016-08-091-0/+2
| | | | | Completely insane that this has to be done. Crap for compensating HDMI crap.
* audio: use --audio-channels=auto behavior, except on ALSAwm42016-08-041-1/+9
| | | | | | | | | | | | | | | | | | | | | | | 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.
* audio: add option for falling back to ao_nullwm42015-10-051-0/+1
| | | | | | | | | 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.)
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* ao_coreaudio: add support for hotplug notificationsStefano Pigozzi2015-02-141-1/+1
| | | | | | | | | | This commit adds notifications for hot plugging of devices. It also extends the old behaviour of the `audio-out-detected-device` property which is now backed by the hotplugging code. This allows clients to be notified when the actual audio output device changes. Maybe hotplugging should be supported for ao_coreaudio_exclusive too, but it's device selection code is a bit fragile.
* audio: add device change notification for hotpluggingwm42015-02-121-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Not very important for the command line player; but GUI applications will want to know about this. This only adds the internal API; support for specific audio outputs comes later. This reuses the ao struct as context for the hotplug event listener, similar to how the "old" device listing API did. This is probably a bit unclean and confusing. One argument got reusing it is that otherwise rewriting parts of ao_pulse would be required (because the PulseAudio API requires so damn much boilerplate). Another is that --ao-defaults is applied to the hotplug dummy ao struct, which automatically applies such defaults even to the hotplug context. Notification works through the property observation mechanism in the client API. The notification chain is a bit complicated: the AO notifies the player, which in turn notifies the clients, which in turn will actually retrieve the device list. (It still has the advantage that it's slightly cleaner, since the AO stuff doesn't need to know about client API issues.) The weird handling of atomic flags in ao.c is because we still don't require real atomics from the compiler. Otherwise we'd just use atomic bitwise operations.
* command: add property returning detected audio deviceStefano Pigozzi2015-02-031-0/+1
| | | | | This can be useful to adjust some other audio related properties at runtime depending on the audio device being used.
* audio/out: make ao_request_reload() idempotentwm42014-11-091-0/+6
| | | | | | | | | | This is what you would expect. Before this commit, each ao_request_reload() call would just queue a reload command, and then recreate the AO for the number of times the function was called. Instead of sending a command, introduce some sort of event retrieval mechanism. At least for the reload case, use atomics, because we're too lazy to setup an extra mutex.
* audio: change internal device listing APIwm42014-10-101-4/+4
| | | | | Now we run ao_driver->list_devs on a dummy AO instance, which will probably confuse everyone. This is done for the sake of PulseAudio.
* audio: add device selection & listing with --audio-devicewm42014-10-091-0/+13
| | | | | | | Not sure how good of an idea this is. This commit doesn't add support for this to any AO yet; the AO implementations will follow later.
* audio/out: remove old thingswm42014-09-061-1/+3
| | | | | | | | Remove the unnecessary indirection through ao fields. Also fix the inverted result of AOCONTROL_HAS_TEMP_VOLUME. Hopefully the change is equivalent. But actually, it looks like the old code did it wrong.
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-291-1/+1
| | | | | | | | | bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
* player: unrangle one aspect of audio EOF handlingwm42014-04-171-5/+1
| | | | | | | | | | | | | | | | | | For some reason, the buffered_audio variable was used to "cache" the ao_get_delay() result. But I can't really see any reason why this should be done, and it just seems to complicate everything. One reason might be that the value should be checked only if the AO buffers have been recently filled (as otherwise the delay could go low and trigger an accidental EOF condition), but this didn't work anyway, since buffered_audio is set from ao_get_delay() anyway at a later point if it was unset. And in both cases, the value is used _after_ filling the audio buffers anyway. Simplify it. Also, move the audio EOF condition to a separate function. (Note that ao_eof_reached() probably could/should whether the last ao_play() call had AOPLAY_FINAL_CHUNK set to avoid accidental EOF on underflows, but for now let's keep the code equivalent.)
* audio: explicitly document audio EOF conditionwm42014-04-171-0/+5
| | | | | | This should probably be an AO function, but since the playloop still has some strange stuff (using the buffered_audio variable instead of calling ao_get_delay() directly), just leave it and make it more explicit.
* audio/out: make draining a separate operationwm42014-03-091-1/+2
| | | | | | | | | | | | Until now, this was always conflated with uninit. This was ugly, and also many AOs emulated this manually (or just ignored it). Make draining an explicit operation, so AOs which support it can provide it, and for all others generic code will emulate it. For ao_wasapi, we keep it simple and basically disable the internal draining implementation (maybe it should be restored later). Tested on Linux only.
* audio/out: make ao struct opaquewm42014-03-091-59/+10
| | | | | | We want to move the AO to its own thread. There's no technical reason for making the ao struct opaque to do this. But it helps us sleep at night, because we can control access to shared state better.
* ao: document some functionswm42014-02-281-3/+12
|
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-2/+2
|
* audio: switch output to mp_audio_bufferwm42013-11-121-3/+3
| | | | | | Replace the code that used a single buffer with mp_audio_buffer. This also enables non-interleaved output operation, although it's still disabled, and no AO supports it yet.
* audio/out: prepare for non-interleaved audiowm42013-11-121-1/+3
| | | | | | | | | | | | | | | | | | | This comes with two internal AO API changes: 1. ao_driver.play now can take non-interleaved audio. For this purpose, the data pointer is changed to void **data, where data[0] corresponds to the pointer in the old API. Also, the len argument as well as the return value are now in samples, not bytes. "Sample" in this context means the unit of the smallest possible audio frame, i.e. sample_size * channels. 2. ao_driver.get_space now returns samples instead of bytes. (Similar to the play function.) Change all AOs to use the new API. The AO API as exposed to the rest of the player still uses the old API. It's emulated in ao.c. This is purely to split the commits changing all AOs and the commits adding actual support for outputting N-I audio.
* ao: add ao_play_silence, use for ao_alsa and ao_osswm42013-11-101-0/+2
| | | | | Also add a corresponding function to audio/format.c, which fills an audio block with silence.
* player: set PulseAudio stream title to window titlewm42013-11-101-0/+2
| | | | | | | Set the PulseAudio stream title, just like the VO window title is set. Refactor update_vo_window_title() so that we can use it for AOs too. The ao_pulse.c bit is stolen from MPlayer.
* audio: don't let ao_lavc access frontend internals, change gapless audiowm42013-11-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | ao_lavc.c accesses ao->buffer, which I consider internal. The access was done in ao_lavc.c/uninit(), which tried to get the left-over audio in order to write the last (possibly partial) audio frame. The play() function didn't accept partial frames, because the AOPLAY_FINAL_CHUNK flag was not correctly set, and handling it otherwise would require an internal FIFO. Fix this by making sure that with gapless audio (used with encoding), the AOPLAY_FINAL_CHUNK is set only once, instead when each file ends. Basically, move the hack in ao_lavc's uninit to uninit_player. One thing can not be entirely correctly handled: if gapless audio is active, we don't know really whether the AO is closed because the file ended playing (i.e. we want to send the buffered remainder of the audio to the AO), or whether the user is quitting the player. (The stop_play flag is overwritten, fixing that is perhaps not worth it.) Handle this by adding additional code to drain the AO and the buffers when playback is quit (see play_current_file() change). Test case: mpv avdevice://lavfi:sine=441 avdevice://lavfi:sine=441 -length 0.2267 -gapless-audio
* audio/out: remove useless info struct and redundant fieldswm42013-10-231-12/+2
|
* ao: remove some leftoverswm42013-08-221-2/+0
|
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-2/+2
| | | | Followup commit. Fixes all the files references.
* audio/out: add support for new logging APIStefano Pigozzi2013-08-011-1/+3
|
* audio/out: remove options argument from init()wm42013-07-221-15/+1
| | | | Same as with VOs in the previous commit.
* options: use new option code for --aowm42013-07-211-5/+9
| | | | This requires completely refactoring the AO creation code too.
* audio/out: remove ao->outburst/buffersize fieldswm42013-06-161-5/+3
| | | | | | | | | | | | | | | The core didn't use these fields, and use of them was inconsistent accross AOs. Some didn't use them at all. Some only set them; the values were completely unused by the core. Some made full use of them. Remove these fields. In places where they are still needed, make them private AO state. Remove the --abs option. It set the buffer size for ao_oss and ao_dsound (being ignored by all other AOs), and was already marked as obsolete. If it turns out that it's still needed for ao_oss or ao_dsound, their default buffer sizes could be adjusted, and if even that doesn't help, AO suboptions could be added in these cases.
* audio/out: remove wrapper for old AOswm42013-06-161-10/+0
| | | | It's unused now.
* audio: add channel map selection functionwm42013-05-121-0/+6
| | | | | | | | | | | | | | | | | | | | The point is selecting a minimal fallback. The AOs will call this through the AO API, so it will be possible to add options affecting the general channel layout selection. It provides the following mechanism to AOs: - forcing the correct channel order - downmixing to stereo if no layout is available - allow 5.1 <-> 5.1(side) fallback - handling "unknown" channel layouts This is quite weak and lots of code/complexity for little gain. All AOs already made sure the channel order was correct, and the fallback is of little value, and could perhaps be done in the frontend instead, like stereo downmixing with --channels=2 is handled. But I'm not really sure how this stuff should _really_ work, and the new code will hopefully provides enough flexibility to make radical changes to channel layout negotiation easier.
* ao: remove ao_driver.is_new fieldwm42013-05-121-1/+0
| | | | Is unused, is completely pointless.
* audio/out: switch to channel mapwm42013-05-121-2/+3
| | | | | | This actually breaks audio for 5/6/8 channels. There's no reordering done yet. The actual reordering will be done inside of af_lavrresample and has to be made part of the format negotiation.
* audio: add some setters for mp_audio, and require filters to use themwm42013-05-121-1/+1
| | | | | | | | | | | | | | | | mp_audio has some redundant fields. Setters like mp_audio_set_format() initialize these properly. Also move the mp_audio struct to a the file audio.c. We can remove a mysterious line of code from af.c: in.format |= af_bits2fmt(in.bps * 8); I'm not sure if this was ever actually needed, or if it was some kind of "make it work" quick-fix that works against the way things were supposed to work. All filters etc. now set the format correctly, so if there ever was a need for this code, it's definitely gone.
* core: redo how codecs are mapped, remove codecs.confwm42013-02-101-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use codec names instead of FourCCs to identify codecs. Rewrite how codecs are selected and initialized. Now each decoder exports a list of decoders (and the codec it supports) via add_decoders(). The order matters, and the first decoder for a given decoder is preferred over the other decoders. E.g. all ad_mpg123 decoders are preferred over ad_lavc, because it comes first in the mpcodecs_ad_drivers array. Likewise, decoders within ad_lavc that are enumerated first by libavcodec (using av_codec_next()) are preferred. (This is actually critical to select h264 software decoding by default instead of vdpau. libavcodec and ffmpeg/avconv use the same method to select decoders by default, so we hope this is sane.) The codec names follow libavcodec's codec names as defined by AVCodecDescriptor.name (see libavcodec/codec_desc.c). Some decoders have names different from the canonical codec name. The AVCodecDescriptor API is relatively new, so we need a compatibility layer for older libavcodec versions for codec names that are referenced internally, and which are different from the decoder name. (Add a configure check for that, because checking versions is getting way too messy.) demux/codec_tags.c is generated from the former codecs.conf (minus "special" decoders like vdpau, and excluding the mappings that are the same as the mappings libavformat's exported RIFF tables). It contains all the mappings from FourCCs to codec name. This is needed for demux_mkv, demux_mpg, demux_avi and demux_asf. demux_lavf will set the codec as determined by libavformat, while the other demuxers have to do this on their own, using the mp_set_audio/video_codec_from_tag() functions. Note that the sh_audio/video->format members don't uniquely identify the codec anymore, and sh->codec takes over this role. Replace the --ac/--vc/--afm/--vfm with new --vd/--ad options, which provide cover the functionality of the removed switched. Note: there's no CODECS_FLAG_FLIP flag anymore. This means some obscure container/video combinations (e.g. the sample Film_200_zygo_pro.mov) are played flipped. ffplay/avplay doesn't handle this properly either, so we don't care and blame ffmeg/libav instead.
* audio/out, video/out: hide encoding VO/AOwm42013-02-061-0/+1
| | | | | | mpv -ao help and mpv -vo help shouldn't show the encoding outputs (named "lavc" on both cases). Also make it impossible to select these manually when not encoding.
* mixer: prefer AO softvol control over volume filterwm42013-02-061-2/+2
| | | | | | | | | | | | | | | This partially reverts earlier decisions, when I thought it would always be better to prefer the audio volume filter over the AO's, because the AO's relies on the underlying audio-API, which could be broken or exhibit unusual behavior (like it happened with ao_dsound). However, since the audio buffer can be quite large (500 ms), and we don't attempt to flush & refilter the audio on volume changes, always prefer AO volume control (as long as the AO mixer doesn't control the system mixer). Also document what the mixer.c related AO fields mean (hopefully not too brief).
* cleanup: remove ao.brokenptswm42012-12-121-1/+0
| | | | This field was used by ao_v4l2, and is now unused.
* Rename directories, move files (step 2 of 2)wm42012-11-121-1/+1
| | | | | | | | | | | | Finish renaming directories and moving files. Adjust all include statements to make the previous commit compile. The two commits are separate, because git is bad at tracking renames and content changes at the same time. Also take this as an opportunity to remove the separation between "common" and "mpla