Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#1635 closed defect (wontfix)

ALSA audio output still disables external resampling

Reported by: andreryan908@… Owned by: reimar
Priority: normal Component: ao
Version: HEAD Severity: normal
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:

Description

The ALSA output plugin (mplayer/trunk/libao2/ao_alsa.c) contains the following code fragment (Around line 550):

/* workaround for buggy rate plugin (should be fixed in ALSA 1.0.11)

prefer our own resampler */

#if SND_LIB_VERSION >= 0x010009

if ((err = snd_pcm_hw_params_set_rate_resample(alsa_handler, alsa_hwparams,

0)) < 0)

{

mp_msg(MSGT_AO,MSGL_ERR,MSGTR_AO_ALSA_UnableToDisableResampling,

snd_strerror(err));

return 0;

}

#endif

This code disables the external resampler for all ALSA versions newer than 1.0.9. Assuming the comment is correct, I recommend changing the #if to:
#if SND_LIB_VERSION >= 0x010009 && SND_LIB_VERSION < 0x010011

(I'm using ALSA Library 1.0.20 which doesn't seem to have any issues with the automatic resampling)

Change History (3)

comment:1 Changed 7 years ago by reimar

  • Resolution set to wontfix
  • Status changed from new to closed

I don't see any advantages in using the ALSA resample, but some disadvantages, like limited (if any) choice of resamplers in ALSA, and certainly not configurable per-file as MPlayer would allow.
I changed the comment though to reflect this.
Also, your suggestion doesn't cover the case when alsa header and library versions mismatch (e.g. compiled on a different system).

comment:2 Changed 7 years ago by andreryan908@…

(In reply to comment #1)

I don't see any advantages in using the ALSA resample, but some disadvantages,
like limited (if any) choice of resamplers in ALSA, and certainly not
configurable per-file as MPlayer would allow.

I fail to understand why you can't still change this since it isn't actually going to prevent someone from adding "-af resample" or "-srate" to their commandline options or mplayer.conf if they want it with the added bonus that they aren't forced to use it if they don't want to. Disabling the 'rate' plugin won't usually allow you to force the output sample rate through ALSA if it won't give the one you want through _set_rate_near either since you are probably talking to DMIX rather than real hardware and that thing demands everything be in a single specific sample rate anyway (and if it is real hardware, there typically shouldn't even be a rate plugin present to disable).

As to why this is a problem, no offence to the maintainer, but the default resampler is pretty bad and I can't understand the settings on -af lavcresample. ALSA offers 3 different plugins (linear, libavcodec and libsamplerate) which have multiple modes; libsamplerate's SINC_FASTEST has no noticeable distortion compared to mplayer's default resampler configuration and doesn't require a thorough understanding of signal processing to configure. It also has the benefit that everything, except mplayer, uses it automatically without needing to be specifically configured.

Also, your suggestion doesn't cover the case when alsa header and library
versions mismatch (e.g. compiled on a different system).

Well, you could handle that pretty easily by doing the test at runtime instead, couldn't you?

static int alsa_runtime_version()
{
#if SND_LIB_VERSION >= 0x010005

int a, b, c;
sscanf(snd_asoundlib_version(), "%d.%d.%d", &a, &b, &c);
return (a << 16) + (b << 8) + c;

#else

return SND_LIB_VERSION;

#endif
}

static int init(...)
{

...

#if SND_LIB_VERSION >= 0x010009

if (alsa_runtime_version() < 0x01000B) {

/* resample disable */

}

#endif

...

}

comment:3 Changed 7 years ago by reimar

Let's try to go through this step by step.
First, the point of disabling ALSA resampling is exactly to make it resample as little as possible - in the case if DMIX it might still do it at some point, but it still should be one point less.
Specifying -srate to get the same effect seems not to work really well to me, because
a) You need to find out which sample rate ALSA wants
b) The correct value can change, e.g. with different hardware or with dmix possibly just because a different set of applications are using ALSA right then

Next, lavcresample is the default if you choose high-quality audio (-af-adv force=1), the man page claims this is the default but I think due to a bug it is not. Should the default lavcresample not be enough, adding higher-quality defaults via this configuration option would be possible (and already now -af-adv force=5 should give better clipping protection for example).
However using lavcresample with the default settings is just a matter of doing "-af lavcresample".
Either way, if the documentation is unclear to you, please help us fix it instead of just avoiding the feature.
Also, e.g. on my system (Ubuntu 9.10) there is no alsa configuration file, not even an example one and the only documentation that some searching found me http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html does not even say what the possible values are, so I claim that if you can figure that out but not how to use lavcresample you are in a vast, vast minority.

Note: See TracTickets for help on using tickets.