summaryrefslogtreecommitdiffstats
path: root/audio/out
Commit message (Collapse)AuthorAgeFilesLines
* ao: slightly extend debug messageswm42015-03-161-1/+4
| | | | | This function already got uglified with debug printing; might as well go all the way.
* ao: align audio buffer sizewm42015-03-131-0/+3
| | | | Might or might not matter.
* ao_coreaudio_exclusive: port to pull API, fix latency calculationswm42015-03-101-78/+37
| | | | | | | | | | | | | | Instead of maintaining a private ring buffer, use the generic support for audio APIs with pull callbacks (internally called AO pull API). This also fixes latency calculations: instead of just returning the ringbuffer status, the audio playback state is calculated better and includes interpolation. The main reason this wasn't done earlier was mid-stream format switching. The pull API can now handle it (in a way) by destroying and recreating the AO. This is a bit brutal, but quite simple. It's untested in this new AO, though. Some details might not be right, like how ot restores the old format when reloading.
* ao_coreaudio: move some helpers to utilswm42015-03-103-16/+20
| | | | Needed by ao_coreaudio_exclusive.c in the next commit.
* ao_coreaudio_exclusive: rip out pseudo volume controlwm42015-03-101-40/+1
| | | | | | | | | | | | | | | | | This could mute a digital passthrough stream by writing zeros. All other volume values did nothing. The comment about MPlayer dying hasn't been true in mpv for quite a while. It's even possible that it's fixed in upstream MPlayer. mpv will print a scary error message when trying to change volume with spdif, and continue normally. If we really want to mute by writing zeros, we should do it in a separate filter. But I'm not overly fascinated by this approach; is it even guaranteed receivers will not be confused by a stream of zeros? The main reason to remove this is that it's in the way of further cleanups.
* ao/wasapi: move resume to audio threadKevin Mitchell2015-02-233-24/+38
| | | | | | | | | | | | | | This echanges the two events hForceFeed/hFeedDone for hResume. This like the last commit makes things more deterministic. Importantly, the forcefeed is only done if there is not already a full buffer yet to be played by the device. This should fix some of the problems with exclusive mode. This commit also removes the necessity to have a proxy to the AudioClient object in the main thread. fixes #1529
* ao_wasapi: move reset into audio threadKevin Mitchell2015-02-232-9/+37
| | | | | | | | | This makes things a bit more deterministic. It ensures that the audio thread isn't doing anything between IAudioClient_Stop(), IAudioClient_Reset() and setting the sample_count to 0. Buffer overfilling on resume is still a problem in exclusive mode (see next commit).
* ao: fix null dereferenceStefano Pigozzi2015-02-141-0/+2
|
* ao_coreaudio: add support for hotplug notificationsStefano Pigozzi2015-02-143-23/+96
| | | | | | | | | | 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.
* ao_pulse: listen for hotplug eventswm42015-02-121-7/+41
| | | | | | | | | | | | | | | This requires jumping through multiple hoops on fire. Since the PulseAudio API is virtually undocumented, I'm not sure if this is correct either. We only react to sink events, and only to the NEW/REMOVE events. CHANGE events are ignored, because PulseAudio fires them far too often - even if the system is completely idle! If pa_sink_info.name can change, we're in trouble. pa_sink_info.description is not so important, but it'd also be a bit un-nice if it can change, and we don't update it. The weird way how the actual AO and the hotplug context share the same struct (ao) comes in handy here, although context_success_cb() still had to be duplicated from success_cb() - the unused argument has a different type.
* audio: add device change notification for hotpluggingwm42015-02-123-25/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* ao: set correct client name when listing deviceswm42015-02-121-4/+3
| | | | | | | | | | This is a small oversight. The client name (as set on command line options or, more importantly, the client API) was not set when listing devices e.g. via the "audio-device-list" property. Might or might not fix #1578. Also adjust the log level for an unrelated message.
* ao_coreaudio: fix small memory leakStefano Pigozzi2015-02-031-0/+4
|
* ao_coreaudio: use device UID instead of ID for selectionStefano Pigozzi2015-02-034-19/+46
| | | | | | | | | | Previously we let the user use the audio device ID, but this is not persistent and can change when plugging in new devices. That of course made it quite worthless for storing it as a user setting for GUIs, or for user scripts. In theory getting the kAudioDevicePropertyDeviceUID can fail but it doesn't on any of my devices, so I'm leaving the error reporting quite high and see if someone complains.
* command: add property returning detected audio deviceStefano Pigozzi2015-02-034-0/+11
| | | | | This can be useful to adjust some other audio related properties at runtime depending on the audio device being used.
* ao_null: add emulation for certain broken behaviorwm42015-01-301-1/+12
| | | | | I'm not sure how common this behavior possibly is; well whatever. This option will allow reproducing such behavior, and help debugging it.
* ao_pulse: plug a memory leakBen Boeckel2015-01-251-0/+3
|
* ao_wasapi: fix try_format logic in shared modeJames Ross-Gowan2015-01-231-2/+1
| | | | | | | | | | | | | | | | | The MSDN documentation for IsFormatSupported says a return code of AUDCLNT_E_UNSUPPORTED_FORMAT means the function "succeeded but the specified format is not supported in exclusive mode." This seems to imply that the format is supported in shared mode, and that's what the old code assumed, however try_format would incorrectly return success with some drivers. The remarks section of the documentation contradicts that assumption. It says that in shared mode, if the audio engine does not support the caller-specified format or any similar format, ppClosestMatch is set to NULL and the function returns AUDCLNT_E_UNSUPPORTED_FORMAT. This is the same as in exclusive mode, so treat AUDCLNT_E_UNSUPPORTED_FORMAT the same regardless of opt_exclusive. In shared mode, the format selection code will fall back to the mix format, which should always be supported.
* ao_alsa: reinitialize if device got brokenwm42015-01-211-0/+3
| | | | | | | | | Apparently, physically disconnecting the audio device (consider USB audio) breaks the ALSA device handle forever. It will signal ENODEV. Fortunately, it's easy for us to handle this, and we can just use existing mechanisms that will make the playback core close and reopen the AO. Whether the immediate reopening will actually succeeds really is ALSA's problem, though.
* ao_coreaudio: reset possibly random errno valuewm42015-01-201-1/+2
| | | | | | | | | | In general, you need to check errno when using strtol(), but as far as I know, strtol() won't reset errno on success. This has to be done manually. The code could have failed sporadically if strtol() succeeded, and errno was already set to one of the checked values. (This strtol() still isn't fully error checked, but I don't know if it's intentional, e.g. for parsing a numeric prefix only.)
* ao: never autoselect ao_nullwm42015-01-201-1/+2
| | | | | | | | | Before this commit, ao_null was used as last fallback. This doesn't make too much sense. Why would you decode audio just to discard it? Let audio initialization fail instead. This also handles the weird but possible corner-case that ao_null might fail initializing, in which case e.g. ao_pcm could be autoselected. (This happened once, and had to be fixed manually.)
* ao: refactor --audio-device selection codewm42015-01-201-85/+73
| | | | | | | | | | | | | | This removes the slightly duplicated code for picking the required AO driver if --audio-device forces one. Now --audio-device reuses the same code as --ao for this. As a consequence, ao_alloc_pb() and ao_create() can be merged into ao_init(). Although the ao_init() argument list, which is already pretty big, grows by one, it's better than having all these similar sounding functions around. Actually, I just wanted to do the change the following commit will do, but I found this code was more of a mess than it had to be.
* ao_alsa: fix a small memory leakwm42015-01-141-0/+2
|
* ao_pcm: add append modewm42015-01-141-1/+3
| | | | | Pretty useful for debugging, although a bit useless or possibly misleading too (see comments in the manpage).
* ao_pulse: exit AO if stream failswm42015-01-111-1/+5
| | | | | | This can for example reproduced by killing the pulseaudio server. If this happens, just try to reload the AO, instead of breaking everything forever.
* ao_alsa: fix dtshd passthroughwm42015-01-091-2/+6
| | | | | | | We must not try to remap channels with this. Whethever ALSA gives us, and whatever we do with it, the result will probably be nonsense. Untested, as I don't have the required hardware.
* ao: remove coreaudio_exclusive from autoprobing listwm42015-01-071-2/+2
| | | | Apparently this was a mistake.
* ao_pulse: disable latency calculation hacks by defaultwm42015-01-071-1/+0
| | | | | | | | | | | | | | This used to be required to workaround PulseAudio bugs. Even later, when the bugs were (partially?) fixed in PulseAudio, I had the feeling the hacks gave better behavior. On the other hand, I couldn't actually reproduce any bad behavior without the hacks lately. On top of this, it seems our hacks sometimes perform much worse than PulseAudio's native implementation (see #1430). So disable the hacks by default, but still leave the code and the option in case it still helps somewhere. Also, being able to blame PulseAudio's code by using its native API is much easier than trying to debug our own (mplayer2-derived) hacks.
* win32: request UTF-16 API variants, Vista+ APIs, and COM C macroswm42015-01-075-13/+1
| | | | | Put the Vista+ (_WIN32_WINNT) and the COM C (COBJMACROS) defines into the build system, instead of defining them over and over in the code.
* ao/wasapi: style/code formatting tweaksKevin Mitchell2015-01-023-64/+63
|
* ao/wasapi: improve exclusive mode format searchKevin Mitchell2015-01-021-46/+36
| | | | fixes #1376
* ao/wasapi: revamp set_waveformatexKevin Mitchell2015-01-021-27/+43
| | | | | | | | * 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_errKevin Mitchell2015-01-021-0/+1
| | | | someone on irc reported seeing this error
* ao_portaudio: remove this audio outputwm42014-12-292-280/+0
| | | | | 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 failswm42014-12-291-1/+2
| | | | | | | | | | 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 mapsStefano Pigozzi2014-12-291-0/+6
| | | | This could be helpful with bug reports.
* ao_coreaudio: remove useless guardStefano Pigozzi2014-12-271-6/+0
| | | | useless after 069016fd6c
* ao_coreaudio: fix some naming conventionsStefano Pigozzi2014-12-271-5/+5
|
* ao_coreaudio: fix channel mappingStefano Pigozzi2014-12-271-19/+70
| | | | | | | | | | | | | | | 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 typoStefano Pigozzi2014-12-271-1/+1
|
* ao_coreaudio: move some code to make output readableStefano Pigozzi2014-12-271-1/+1
|
* ao_coreaudio: add more layout debug outputsStefano Pigozzi2014-12-271-19/+25
| | | Should help remote debugging #1367 with --msg-level=ao=debug
* ao_coreaudio: fix AudioChannelLayout allocationsStefano Pigozzi2014-12-261-34/+46
| | | | | | | | 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 commitwm42014-12-231-0/+2
| | | | The resume code was accidentally fully removed from this code path.
* ao_alsa: fix resuming from suspend modewm42014-12-231-4/+12
| | | | | | | | | | | 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 mapwm42014-12-201-0/+5
| | | | | | | 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 codewm42014-12-201-6/+0
| | | | | | | | 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.
* ao_coreaudio: fix mono/stereo channel mappingStefano Pigozzi2014-12-161-9/+7
| | | | | | Needed after af3bbb800d since now we use channel mapping all the time. Fixes #1357
* ao_coreaudio: add missing goto for error pathStefano Pigozzi2014-12-161-0/+1
|
* ao/wasapi: use IsEqualGUID and IsEqualPropertyKeyKevin Mitchell2014-12-163-30/+9
| | | | before we were reinventing this wheel
* ao_alsa: remove old multichannel methodwm42014-12-151-49/+3
| | | | | | | | | | | | | | | | | | | | | | | | | 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 behaviorwm42014-12-151-3/+42
| | | | | | | | | | | | | | | | | | | | | 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 channelmapKevin Mitchell2014-12-151-1/+10
| | | | hopefully this fixes #1350
* ao_alsa: minor simplificationwm42014-12-051-5/+1
| | | | | | | | 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 playbackwm42014-12-051-0/+3
| | | | | | 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 descriptionsStefano Pigozzi2014-12-051-0/+6
| | | | for #1279 and #1249
* coreaudio: add missing \n in log lineStefano Pigozzi2014-12-051-1/+1
|
* coreaudio: don't print layout a second timeStefano Pigozzi2014-12-051-1/+1
| | | | For #1279
* ao_alsa: simplify, remove no-block suboptionwm42014-12-051-17/+8
| | | | | | | | | | | 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 busywm42014-12-041-1/+6
| | | | | | | | | | | | | 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 channelsStefano Pigozzi2014-12-041-0/+7
| | | | This is a fix attempt for #1279 and #1249.
* coreaudio: fix more layout printsStefano Pigozzi2014-12-041-2/+2
|
*