aboutsummaryrefslogtreecommitdiffhomepage
path: root/audio/out/ao_alsa.c
Commit message (Collapse)AuthorAge
* ao_alsa: filter audio device listGravatar wm42015-11-24
| | | | | | | | 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 tooGravatar wm42015-11-24
| | | | | | | | | 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 fallbackGravatar wm42015-11-07
| | | | | | | | 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 HDMIGravatar wm42015-11-04
| | | | | | | | | | | | | | | | | 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 wayGravatar wm42015-11-04
| | | | | | | | | | | | | | | | 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 verbosityGravatar wm42015-11-04
|
* ao_alsa: minor cleanupsGravatar wm42015-11-03
|
* ao_alsa: simplify dmix non-NA hackGravatar wm42015-11-03
| | | | | 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 functionGravatar wm42015-11-03
| | | | This grew way too large.
* ao_alsa: make failure of buffer parameter setting non-fatalGravatar wm42015-11-03
| | | | | | | | | | | | | | | | | | | | 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 thingGravatar wm42015-11-03
| | | | | | 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 formatGravatar wm42015-11-03
| | | | | | | | 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 negotiationGravatar wm42015-11-03
| | | | | | | | 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 stereoGravatar wm42015-11-03
| | | | | | 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 tooGravatar wm42015-11-03
| | | | | | 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 pausingGravatar wm42015-11-03
| | | | This was annoying.
* audio: always log channel maps before determining final mapGravatar wm42015-10-26
| | | | | 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 modeGravatar wm42015-10-25
| | | | | 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 searchGravatar Kevin Mitchell2015-10-06
|
* ao_alsa: fix failure to find any sampleformatGravatar Kevin Mitchell2015-10-06
| | | | | 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 disconnectionGravatar wm42015-09-28
| | | | | | | 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 codeGravatar Kevin Mitchell2015-09-10
|
* ao_alsa: add double to sample format listGravatar Kevin Mitchell2015-09-10
|
* ao_alsa: put spdif formats into find_alsa_formatGravatar Kevin Mitchell2015-09-10
|
* ao_alsa: fix minor memory leakGravatar wm42015-08-25
| | | | | | | 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 issuesGravatar wm42015-06-26
| | | | | | | | | | | 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 messageGravatar wm42015-06-21
| | | | | | | | | | | | | | | | | 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 formatsGravatar wm42015-06-16
| | | | | | | | | | | | | 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 layoutsGravatar wm42015-06-12
| | | | | | | 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 HDMIGravatar wm42015-06-12
| | | | | 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 heuristicGravatar wm42015-06-11
| | | | | | | | | | | | 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 messageGravatar wm42015-06-09
| | | | I suspect we need to hand this more gracefully in some cases.
* ao_alsa: refuse to use spdif if AES flags can't be setGravatar wm42015-06-04
| | | | | Seems like a good idea to avoid accidentally playing noise by writing spdif data to pure PCM devices.
* ao_alsa: hack against potential spdif failureGravatar wm42015-06-04
|
* ao_alsa: hack back mono outputGravatar wm42015-05-25
| | | | | 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 themGravatar wm42015-05-08
|
* audio: define only a single NA speaker IDGravatar wm42015-05-07
| | | | | 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 supportGravatar wm42015-05-06
| | | | | | | | | | | | 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 functionGravatar wm42015-05-06
| | | | | 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 failsGravatar wm42015-04-14
| | | | | | 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 headersGravatar Marcin Kurczewski2015-04-13
| | | | Signed-off-by: wm4 <wm4@nowhere>
* ao_alsa: change log outputGravatar wm42015-04-07
| | | | | | | | 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 macrosGravatar Kevin Mitchell2015-04-03
| | | | | 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 negotiationGravatar wm42015-03-28
| | | | This was requested, more or less.
* ao_alsa: reinitialize if device got brokenGravatar wm42015-01-21
| | | | | | | | | 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 leakGravatar wm42015-01-14
|
* ao_alsa: fix dtshd passthroughGravatar wm42015-01-09
| | | | | | | 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 failsGravatar wm42014-12-29
| | | | | | | | | | 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 commitGravatar wm42014-12-23
| | | | The resume code was accidentally fully removed from this code path.
* ao_alsa: fix resuming from suspend modeGravatar wm42014-12-23
| | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-06 12:16:27 +0000