summaryrefslogtreecommitdiffstats
path: root/audio/out/ao_alsa.c
Commit message (Collapse)AuthorAgeFilesLines
* audio: define only a single NA speaker IDwm42015-05-091-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. (cherry picked from commit b91b4944bd7ddf6fef4c4254d457117017292c0a)
* ao_alsa: log requested numbers of channels if ALSA rejects themwm42015-05-091-2/+3
| | | | (cherry picked from commit ad9bce2a5ca62f6a64f65fe79ae170edc0e05da4)
* ao_alsa: use new padding channels supportwm42015-05-071-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. (cherry picked from commit 85fc6b2a0569b24c5652f600d90d7a131b61eb07)
* ao_alsa: move ALSA -> mp channel map to a functionwm42015-05-071-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". (cherry picked from commit d577872a28c9729e987566530905bde238af8109)
* 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.
* ao_alsa: make device the first sub optionwm42014-05-311-1/+1
| | | | This is more convenient.
* ao_alsa: reduce spurious wakeupswm42014-05-301-8/+14
| | | | | | Apparently this can happen. So actually only return from waiting if ALSA excplicitly signals that new output is available, or if we are woken up externally.
* ao_alsa: use poll() to wait for devicewm42014-05-301-0/+30
| | | | | This means the audio feed thread is woken up exactly at the time new data is needed, instead of using a time-based heuristic.
* af_lavrresample: remove avresample_set_channel_mapping() fallbackswm42014-03-161-1/+0
| | | | | | | This function is now always available. Also remove includes of reorder_ch.h from some AOs (these are just old relicts).
* ao_alsa: reduce default buffer sizewm42014-03-101-1/+1
| | | | | | | | | | In general, we don't need to have a large hw audio buffer size anymore, because we can quickly fill it from the soft buffer. Note that this probably doesn't change much anyway. On my system (dmix enabled), the buffer size is only 170ms, and ALSA won't give more. Even when using a hardware device the buffer size seems to be limited to 341ms.
* ao_alsa: fix return value for volume operations with spdifwm42014-03-101-1/+1
| | | | | | | | | | | This AO pretended to support volume operations when in spdif passthrough mode, but actually did nothing. This is wrong: at least the GET operations must write their argument. Signal that volume is unsupported instead. This was probably a hack to prevent insertion of volume filters or so, but it didn't work anyway, while recovering after failed volume filter insertion does work, so this is not needed at all.
* ao_alsa: remove unneeded initializationswm42014-03-091-6/+0
| | | | priv is 0-initialized, can_pause is always overwritten later.
* ao_alsa: check ALSA PCM state before pause and resumefoo862014-03-091-5/+9
| | | | | | | | | | It is possible to have ao->reset() called between ao->pause() and ao->resume() when seeking during the pause. If the underlying PCM supports pausing, resuming an already reset PCM will produce an error. Avoid that by explicitly checking PCM state before calling snd_pcm_pause(). Signed-off-by: wm4 <wm4@nowhere>
* audio/out: make draining a separate operationwm42014-03-091-6/+10
| | | |