summaryrefslogtreecommitdiffstats
path: root/audio/out/ao_alsa.c
Commit message (Collapse)AuthorAgeFilesLines
* audio/out: deprecate device sub-optionswm42016-09-051-1/+1
| | | | | We have --audio-device, which can force the device. Also add something describing to this extent to the manpage.
* options: add a mechanism to make sub-option replacement slightly easierwm42016-09-051-1/+2
| | | | | | | | 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-021-31/+51
| | | | | | Same deal as with vo_opengl. Also edit the outdated information about multichannel output a little.
* 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.
* 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.
* audio: use --audio-channels=auto behavior, except on ALSAwm42016-08-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | 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.
* 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 no ALSA bug tracker (the ALSA website has had a dead link to a deleted bug tracker fo years). There's not much we can do other than piling up ridiculous hacks. At least I think that at this point invalid API usage by mpv can be excluded as a cause. ALSA might be the worst audio API ever.
* ao_alsa: log final hwparams toowm42016-05-031-1/+2
| | | | snd_pcm_hw_params() updates them.
* ao_alsa: log hwparams while restricting themwm42016-04-281-0/+43
| | | | | | They can sometimes fail, so I want logging to determine what's going on. Most of them are at debug log-level, except the final hwparams.
* ao_alsa: filter audio device listwm42015-11-241-1/+15
| | | | | | | | Remove known useless device entries from the --audio-device list (and corresponding property). Do this because the list is supposed to be a high level list of devices the user can select. ALSA does not provide such a list (in an useable manner), and ao_alsa.c is still in the best position to improve the situation somewhat.
* ao_alsa: list bidirectional devices toowm42015-11-241-1/+1
| | | | | | | | | The ALSA doxygen says: IOID - input / output identification ("Input" or "Output"), NULL means both This bug was blatantly introduced with commit cf94fce4.
* ao_alsa: remove the last bits of legacy channel map fallbackwm42015-11-071-3/+1
| | | | | | | | Essentially we'd use something random, just because it's part of the srt of traditionally used ALSA channel mappings. But each driver can do its own things. This doesn't let me sleep at night, so remove it.
* ao_alsa: fix 7.1 over HDMIwm42015-11-041-0/+26
| | | | | | | | | | | | | | | | | We need to effectively swap the last channel pair. See commit 4e358a96 and 5a18c5ea for details. Doing this seems rather strange, as 7.1 just extends 5.1 with 2 new speakers, and 5.1 doesn't need this change. Going by the HDMI standard and the Intel HDA sources (cited in the referenced commits), it also looks like 7.1 should simply append two channels to 5.1 as well. But swapping them is apparently correct. This is also what XBMC does. (I didn't find any other applications doing 7.1 PCM using the ALSA channel map API. VLC seems to ignore the 7.1 case.) Testing reveals that at least the end result is correct. "Normal" ALSA 7.1 is unaffected by this, as it reports a different (and saner) channel layout.
* ao_alsa: map mp_chmaps back to ALSA in a different waywm42015-11-041-39/+54
| | | | | | | | | | | | | | | | Instead of constructing an ALSA channel map from mpv ones from scratch, try to find the original ALSA channel map again. Th result is that we need to convert channel maps only in one direction. If we need to map a mp_chmap to ALSA, we fetch the device's channel map list, convert each entry to mp_chmap, and find the first one which fits. This seems helpful for the following commit. For now, this only gets rid of mapping back the trivial MONO mapping, which alone would still be acceptable, but with other channel layout mogrifications it gets messy fast. While we need to do something awkward to keep our channel map reordering for VAR chmaps (which basically gives nicer output and possibly slightly better performance), this is still the better solution.
* ao_alsa: print more chmap info at debug verbositywm42015-11-041-9/+11
|
* ao_alsa: minor cleanupswm42015-11-031-34/+18
|
* ao_alsa: simplify dmix non-NA hackwm42015-11-031-58/+43
| | | | | There's really no need to do this deep in the chmap sslection code. This will setup the device further than before, but that doesn't matter.
* ao_alsa: move channel map setting code out of main init functionwm42015-11-031-104/+125
| | | | This grew way too large.
* ao_alsa: make failure of buffer parameter setting non-fatalwm42015-11-031-4/+12
| | | | | | | | | | | | | | | | | | | | These calls actually can leave the ALSA configuration space empty (how very useful), which is why snd_pcm_hw_params() can fail. An earlier change intended to make this non-fatal, but it didn't work for this reason. Backup the old parameters, so we can retry with the non-empty configuration space. (It has to be non-empty, because the previous setters didn't fail.) Note that the buffer settings are not very important to us. They're a leftover from MPlayer, which needed to write enough data to the audio device to not underrun while decoding and displaying a video frame. In mpv, most of these things happen asynchronously, _and_ there is a dedicated thread just for feeding the audio device, so we should be pretty imune even against extreme buffer settings. But I suppose it's still useful to prevent PulseAudio from making the buffer too large, so still keep this code.
* ao_alsa: disable resampling first thingwm42015-11-031-7/+7
| | | | | | Again, this could have bad access, is unlikely, and has no bad consequences. It's noteworthy that vlc and the ALSA PCM example both do this first, even if they set the sample rate later.
* ao_alsa: set access type before formatwm42015-11-031-11/+13
| | | | | | | | I'm worried that not restricting the access type before restricting the format will cause problems. While it's unlikely, it might prevent failures in some corner cases. Also, since we by default always use interleaved access (buggy ALSA plugins), this will have no effects at all.
* ao_alsa: handle channel count mismatch safeguard after chmap negotiationwm42015-11-031-12/+12
| | | | | | | | If the API doesn't list padded channel maps, but the final device channel map is padded, and if unpadded output is not possible (unlike in the somewhat similar dmix case), then we shouldn't apply the channel count mismatch fallback in the beginning. Do it after channel map negotiation instead.
* ao_alsa: apply non-NA fallback only if input is stereowm42015-11-031-0/+1
| | | | | | Doesn't matter much; effectively this prevents just log spam in some cases where the map is legitimately padded. Normally this is really only needed for the dmix ALSA case. (See git blame for details.)
* ao_alsa: treat SND_CHMAP_UNKNOWN as NA channel toowm42015-11-031-0/+1
| | | | | | Apparently required by nVidia HDMI. It should not be, and NA would definitely be more correct here, so this could be considered a driver bug. Maybe.
* ao_alsa: remove log message on pausingwm42015-11-031-1/+2
| | | | This was annoying.
* audio: always log channel maps before determining final mapwm42015-10-261-3/+3
| | | | | Until now, this was done only in debug verbosity, while some AOs logged equivalent information in verbose mode. Clean this up.
* ao_alsa: log format probing in verbose modewm42015-10-251-2/+1
| | | | | And also remove a redundant log message. (We can tell from the following probe or error message whether or not the format test is successful.)
* ao_alsa: add debug messages for format searchKevin Mitchell2015-10-061-0/+2
|
* ao_alsa: fix failure to find any sampleformatKevin Mitchell2015-10-061-4/+7
| | | | | Set format to invalid after each failed test. This way the final check for valid format will actually fail if no formats work.
* ao_alsa: improve handling of device disconnectionwm42015-09-281-3/+20
| | | | | | | This can happen with USB audio. There was already code for this, but something in mpv and ALSA changed - and now the old code is not necessarily triggered anymore. It probably depends on the exact situation.
* ao_alsa: use sample format determination codeKevin Mitchell2015-09-101-12/+10
|
* ao_alsa: add double to sample format listKevin Mitchell2015-09-101-0/+1
|
* ao_alsa: put spdif formats into find_alsa_formatKevin Mitchell2015-09-101-9/+9
|
* ao_alsa: fix minor memory leakwm42015-08-251-8/+11
| | | | | | | So snd_device_name_get_hint() return values do in fact have to be freed. Also, change listing semantics slightly: if io==NULL, skip the entry, instead of assuming it's an output device.
* audio: fix format function consistency issueswm42015-06-261-9/+9
| | | | | | | | | | | Replace all the check macros with function calls. Give them all the same case and naming schema. Drop af_fmt2bits(). Only af_fmt2bps() survives as af_fmt_to_bytes(). Introduce af_fmt_is_pcm(), and use it in situations that used !AF_FORMAT_IS_SPECIAL. Nobody really knew what a "special" format was. It simply meant "not PCM".
* 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.
* audio: remove S8, U16, U24, U32 formatswm42015-06-161-5/+0
| | | | | | | | | | | | | 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.
* 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.
* 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_alsa: refine channel count mismatch error messagewm42015-06-091-2/+2
| | | | I suspect we need to hand this more gracefully in some cases.
* 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.
* ao_alsa: hack against potential spdif failurewm42015-06-041-3/+16
|
* 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.
* ao_alsa: log requested numbers of channels if ALSA rejects themwm42015-05-081-2/+3
|
* audio: define only a single NA speaker IDwm42015-05-071-7/+2
| | | | | Remove the requirement from mp_chmap that speaker entries must be unique. Use this to get rid of all the redundant NA speaker IDs.
* ao_alsa: use new padding channels supportwm42015-05-061-21/+26
| | | | | | | | | | | | Sometimes, ALSA will return channel layouts with padded channels (NA speakers). Use them instead of failing. This still includes the old "braindeath" code to retry with a layout without NA channels. This might be helpful for performance, and also the padded channel layout string looks confusing. To be fair, I have not encountered a case yet which would really need this, and for which the old "braindeath" code did not fix it.
* ao_alsa: move ALSA -> mp channel map to a functionwm42015-05-061-11/+18
| | | | | One side effect is that the warning about too many channels goes away, and is replaced with printing the ALSA channel map as "unknown".
* ao_alsa: fallback to stereo channel layout if everything else failswm42015-04-141-1/+4
| | | | | | mp_chmap_from_channels_alsa() doesn't always succeed - there are a bunch of channel counts for which no defined ALSA layout exists. Fallback to stereo in this case. (Normally, this code path shouldn't happen at all.)
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* ao_alsa: change log outputwm42015-04-071-12/+15
| | | | | | | | Silence the usually user-visible warning about unsupported channel maps. This might be an ALSA bug, but ALSA will never fix this behavior anyway. (Or maybe it's a feature.) Log some other information that might be useful.
* audio: make all format query shortcuts macrosKevin Mitchell2015-04-031-3/+3
| | | | | af_fmt_is_float and af_fmt_is_planar were previously inconsistent with AF_FORAMT_IS_SPECIAL/AF_FORMAT_IS_IEC61937
* ao_alsa: add an option to ignore ALSA channel map negotiationwm42015-03-281-2/+6
| | | | This was requested, more or less.
* 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_alsa: fix a small memory leakwm42015-01-141-0/+2
|
* 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_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_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_alsa: remove old multichannel methodwm42014-12-151-49/+3
| | | | | | | | | | | |