summaryrefslogtreecommitdiffstats
path: root/audio/out/ao_alsa.c
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | | | | | | | | | | | | | | | | | | | | | | 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_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.
* 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.)
* audio: allow more than 20 channel map entrieswm42014-12-011-1/+1
| | | | | | | | | | | | | This could trigger an assertion when using ao_alsa or ao_coreaudio. The code was simply assuming the number of channel maps was bounded statically (which was true at first in both AOs). Fix by using dynamic memory allocation. It needs to be explicitly enabled by the AOs by setting a temp context, because otherwise the memory couldn't be freed. (Or at least this seems to be the most elegant solution.) Fixes #1306.
* ao_alsa: fix channel map in pre-channel map API casewm42014-11-251-0/+1
| | | | Forgotten in commit 5d5f5b09.
* ao_alsa: always enable "plug" plugin for non-default devicewm42014-11-251-3/+2
| | | | | | | | | | | | | | This seems safer: otherwise, opening the AO could randomly fail if the audio formats happens to be not float. Unfortunately, this only works if the user does not select a device. Since ALSA devices are arbitrary strings, including plugins with complex parameters, it's not trivial or maybe even impossible to edit the string in a way the "plug" plugin is added. With --audio-device, it would be safe for users to select either "default" or one of the "plughw" devices. Everything else seems questionable.
* ao_alsa: select and set channel maps via channel map APIwm42014-11-251-28/+125
| | | | | | | | | | | | | | | | Use the ALSA channel map API for querying and selecting supported channel maps. Since we (probably?) want to be compatible with ALSA versions before the change, we still try to select the device name by channel map, and open that device. There's no way to negotiate a channel map before opening, so we're stuck with this approach. Fortunately, it seems these devices allow selecting and setting any other supported channel layout, so maybe this is not an issue at all. In particular, this avoids selecting the default (dmix) device, which can only do stereo. Most code is based on Martin Herkt <lachs0r@srsfckn.biz>'s alsa_ng branch, with heavy modifications.
* ao_alsa: minor fixeswm42014-11-251-4/+6
| | | | | | | | | | | | | Don't crash if no fallback channel layout could be found (caller can't handle NULL return from select_chmap()). Apparently this could never actually happen, though. Don't treat snd_pcm_hw_params_set_periods_near() failure as fatal error. Same deal as with snd_pcm_hw_params_set_buffer_time_near(). Actually free channel maps returned by snd_pcm_get_chmap(). Adjust some messages.
* ao_alsa: cleanupswm42014-11-251-97/+57
| | | | | | | | | No functional changes. ALSA_PCM_NEW_HW_PARAMS_API was a pre-ALSA 1.0.0 thing and does nothing with modern ALSA. It stopped being necessary about 10 years ago. 3 functions are moved to avoid forward references.
* audio: make mp_chmap_to_str() return a stack-allocated stringwm42014-11-241-6/+2
| | | | Simplifies memory management.
* ao_alsa: try to use the channel map reported by ALSAwm42014-11-241-0/+64
| | | | | | | | If ALSA reports a channel map, and it looks like it makes sense (i.e. could be converted to mpv channel map, and the channel count matches), then use that instead of the channel map we are assuming. This is based on code written by lachs0r (alsa_ng branch).
* ao_alsa: check for EAGAIN toowm42014-11-171-1/+1
| | | | | | | Simply retry on EAGAIN. I've seen this in several other projects; it might be just cargo-culting though.
* audio/out: consistently use double return type for get_delaywm42014-11-091-5/+5
| | | | | ao_get_delay() returns double, but the get_delay callback still returned float.
* ao_alsa: don't make snd_pcm_hw_params_set_buffer_time_near() error fatalwm42014-10-311-1/+7
| | | | | | | | | | | | | Apparently this can "sometimes" return an error. In my opinion, this should never return an error: neither the semantics of the function, nor the ALSA documentation or ALSA sample code seem to indicate that a failure is to be expected. I'm not perfectly sure about this though (I blame ALSA being a weird, big, underdocumented API). Since it causes problems for some users, and since there is really no reason why we should abort on such an error, turn it into a warning. Fixes #1231.
* ao_alsa: move parameter append code to a functionwm42014-10-231-16/+27
| | | | | Why not. (I thought I needed this, but my other experiments failed. So this is merely a minor cleanup.)
* audio: change internal device listing APIwm42014-10-101-2/+2
| | | | | 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.
* ao_alsa: implement device listing & selectionwm42014-10-091-0/+27
| | | | | | | Unfortunately, ALSA is particularly bad with this, because mpv has to add all sorts of magic crap to the device name to make things work. The device selection overrides this, so explicitly selecting devices will most likely break your audio. This has yet to be solved.
* audio: cleanup spdif format definitionswm42014-09-231-11/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, there was AF_FORMAT_AC3 (the original spdif format, used for AC3 and DTS core), and AF_FORMAT_IEC61937 (used for AC3, DTS and DTS-HD), which was handled as some sort of superset for AF_FORMAT_AC3. There also was AF_FORMAT_MPEG2, which used IEC61937-framing, but still was handled as something "separate". Technically, all of them are pretty similar, but may use different bitrates. Since digital passthrough pretends to be PCM (just with special headers that wrap digital packets), this is easily detectable by the higher samplerate or higher number of channels, so I don't know why you'd need a separate "class" of sample formats (AF_FORMAT_AC3 vs. AF_FORMAT_IEC61937) to distinguish them. Actually, this whole thing is just a mess. Simplify this by handling all these formats the same way. AF_FORMAT_IS_IEC61937() now returns 1 for all spdif formats (even MP3). All AOs just accept all spdif formats now - whether that works or not is not really clear (seems inconsistent due to earlier attempts to make DTS-HD work). But on the other hand, enabling spdif requires manual user interaction, so it doesn't matter much if initialization fails in slightly less graceful ways if it can't work at all. At a later point, we will support passthrough with ao_pulse. It seems the PulseAudio API wants to know the codec type (or maybe not - feeding it DTS while telling it it's AC3 works), add separate formats for each codecs. While this reminds of the earlier chaos, it's stricter, and most code just uses AF_FORMAT_IS_IEC61937(). Also, modify AF_FORMAT_TYPE_MASK (renamed from AF_FORMAT_POINT_MASK) to include special formats, so that it always describes the fundamental sample format type. This also ensures valid AF formats are never 0 (this was probably broken in one of the earlier commits from today).
* audio: drop swapped-endian audio formatswm42014-09-231-18/+14
| | | | | | | | | | | | | | | | | | | | Until now, the audio chain could handle both little endian and big endian formats. This actually doesn't make much sense, since the audio API and the HW will most likely prefer native formats. Or at the very least, it should be trivial for audio drivers to do the byte swapping themselves. From now on, the audio chain contains native-endian formats only. All AOs and some filters are adjusted. af_convertsignendian.c is now wrongly named, but the filter name is adjusted. In some cases, the audio infrastructure was reused on the demuxer side, but that is relatively easy to rectify. This is a quite intrusive and radical change. It's possible that it will break some things (especially if they're obscure or not Linux), so watch out for regressions. It's probably still better to do it the bulldozer way, since slow transition and researching foreign platforms would take a lot of time and effort.
* audio: remove swapped-endian spdif formatswm42014-09-231-6/+4
| | | | | | | | | | | | | | | | | | | | | | IEC 61937 frames should always be little endian (little endian 16 bit words). I don't see any apparent need why the audio chain should handle swapped-endian formats. It could be that some audio outputs might want them (especially on big endian architectures). On the other hand, it's not clear how that works on these architectures, and it's not even known whether the current code works on big endian at all. If something should break, and it should turn out that swapped-endian spdif is needed on any platform/AO, swapping still could be done in-place within the affected AO, and there's no need for the additional complexity in the rest of the player. Note that af_lavcac3enc outputs big endian spdif frames for unknown reasons. Normally, the resulting data is just pulled through an auto- inserted conversion filter and turned into little endian. Maybe this was done as a trick so that the code didn't have to byte-swap the actual audio frame. In any case, just make it output little endian frames. All of this is untested, because I have no receiver hardware.
* audio/out: always round get_space on period sizewm42014-09-061-1/+1
| | | | | | | | | | | Round get_space() results in the same way play() rounds the input size. Some audio APIs do this for various reasons. This affects only "push" based AOs. Some of these need no change, because they either do it already right (like ao_openal), or they seem not to have any such requirements (like ao_pulse). Needed for the following commit.
* ao_alsa: disable use of non-interleaved formats by defaultwm42014-07-301-0/+6
| | | | | | | | Some ALSA plugins take non-interleaved audio, but treat it as interleaved, which results in various funny bugs. Users keep hitting this issue, and it just doesn't seem worth the trouble. CC: @mpv-player/stable
* Audit and replace all ctype.h useswm42014-07-011-1/+0
| | | | | | | | | | | | | | | | Something like "char *s = ...; isdigit(s[0]);" triggers undefined behavior, because char can be signed, and thus s[0] can be a negative value. The is*() functions require unsigned char _or_ EOF. EOF is a special value outside of unsigned char range, thus the argument to the is*() functions can't be a char. This undefined behavior can actually trigger crashes if the implementation of these functions e.g. uses lookup tables, which are then indexed with out-of-range values. Replace all <ctype.h> uses with our own custom mp_is*() functions added with misc/ctype.h. As a bonus, these functions are locale-independent. (Although currently, we _require_ C locale for other reasons.)
* Add more constwm42014-06-111-1/+1
| | | | | | | While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
*