Bug#663239: mplayer opens audio device in 48000 Hz for 44100 source material
On Sat, 12 May 2012 15:33:02 +0200 Kurt Roeckx k...@roeckx.be wrote: On Sat, May 12, 2012 at 04:09:38PM +0300, Uoti Urpala wrote: I know all this. That doesn't mean things can't be improved. Well, it certainly sounded like you didn't know all this; if you did, I can't see why you wrote The problem now is that mplayer does this in libao2/ao_alsa.c: in the original message, or reported this against mplayer2 at all (in addition to libasound2). What could be improved in mplayer2? I guess I got confused about the comment in the source file indicating that with a newer alsa version this shouldn't be needed anymore. But my understanding now is that dmix will always resample to what is in the config file (48000), and that by default I would get a worse resample algorithm unless I set up alsa to use a different one. Is this bug still valid for you? Elimar -- Do you smell something burning or is it me? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663239: mplayer opens audio device in 48000 Hz for 44100 source material
On Sun, Apr 15, 2012 at 07:17:34PM +0300, Uoti Urpala wrote: This is expected behavior with ALSA dmix. It has a fixed hardware output frequency, in your case 48000 Hz. As far as I know this is just a default and has nothing at all to do with what the hardware supports, it's just a value in a config file. Anything played through dmix will be resampled to 48000 Hz. mplayer2 could feed data to ALSA at 44100 Hz if it left ALSA resampling enabled, but the only difference that would make is that the resampling would happen on the ALSA side rather than on the mplayer2 side. I know, and as far as I understand the default resampling of dmix is worse quality than what mplayer uses. And I don't really care where the resampling happens, but it really should only be done when the hardware doesn't support the sample rate. There's no way hardware would support everything in the 4000-4294967295 range. That range only tells which rates ALSA is willing to resample to 48000 Hz. The values reported for the hw device, 44100 48000 96000 192000, are the ones your hardware can actually play without resampling. If you select the hw device then you should be able to play these rates without resampling (note that in contrast to dmix, using the hw device directly reserves the device and no other audio source can play at the same time). I know all this. That doesn't mean things can't be improved. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663239: mplayer opens audio device in 48000 Hz for 44100 source material
On Sat, 2012-05-12 at 12:52 +0200, Kurt Roeckx wrote: On Sun, Apr 15, 2012 at 07:17:34PM +0300, Uoti Urpala wrote: This is expected behavior with ALSA dmix. It has a fixed hardware output frequency, in your case 48000 Hz. As far as I know this is just a default and has nothing at all to do with what the hardware supports, it's just a value in a config file. I meant it's fixed for each dmix instance; when ALSA dmix is using a hardware frequency of 48000 Hz, everything will be resampled to that. You can configure dmix to use a different frequency, but it won't adapt based on source audio. I know all this. That doesn't mean things can't be improved. Well, it certainly sounded like you didn't know all this; if you did, I can't see why you wrote The problem now is that mplayer does this in libao2/ao_alsa.c: in the original message, or reported this against mplayer2 at all (in addition to libasound2). What could be improved in mplayer2? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663239: mplayer opens audio device in 48000 Hz for 44100 source material
On Sat, May 12, 2012 at 04:09:38PM +0300, Uoti Urpala wrote: I know all this. That doesn't mean things can't be improved. Well, it certainly sounded like you didn't know all this; if you did, I can't see why you wrote The problem now is that mplayer does this in libao2/ao_alsa.c: in the original message, or reported this against mplayer2 at all (in addition to libasound2). What could be improved in mplayer2? I guess I got confused about the comment in the source file indicating that with a newer alsa version this shouldn't be needed anymore. But my understanding now is that dmix will always resample to what is in the config file (48000), and that by default I would get a worse resample algorithm unless I set up alsa to use a different one. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663239: mplayer opens audio device in 48000 Hz for 44100 source material
As far as I can see there is no bug. This is expected behavior with ALSA dmix. It has a fixed hardware output frequency, in your case 48000 Hz. Anything played through dmix will be resampled to 48000 Hz. mplayer2 could feed data to ALSA at 44100 Hz if it left ALSA resampling enabled, but the only difference that would make is that the resampling would happen on the ALSA side rather than on the mplayer2 side. There's no way hardware would support everything in the 4000-4294967295 range. That range only tells which rates ALSA is willing to resample to 48000 Hz. The values reported for the hw device, 44100 48000 96000 192000, are the ones your hardware can actually play without resampling. If you select the hw device then you should be able to play these rates without resampling (note that in contrast to dmix, using the hw device directly reserves the device and no other audio source can play at the same time). The only thing here that could potentially be improved would be to allow dmix to change the hardware playback rate depending on input streams, so it could switch the hardware rate to 44100 Hz if that's the rate of the only stream being played. But this would be nontrivial - what happens if another stream is opened at a different frequency, etc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663239: mplayer opens audio device in 48000 Hz for 44100 source material
Package: mplayer2, libasound2
Hi,
When I'm playing music with mplayer2, when the music is with a
samplerate of 44100, mplayer opens the device in 48000 mode.
Which means that mplayer needs to resample from 44100 to 48000,
while there is no need for this, and only wastes cpu time, and
distorts the sound. As far as I can see it defaults to an
accurate resample algorithm, but it's using multiple times the
amount of CPU it should be using.
I have those devices:
$ aplay -L
null
Discard all samples (playback) or generate zero samples (capture)
pulse
PulseAudio Sound Server
default:CARD=PCH
HDA Intel PCH, ALC892 Analog
Default Audio Device
sysdefault:CARD=PCH
HDA Intel PCH, ALC892 Analog
Default Audio Device
front:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Analog
Front speakers
surround40:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Analog
4.0 Surround output to Front and Rear speakers
surround41:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Analog
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Analog
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Analog
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Analog
7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=PCH,DEV=0
HDA Intel PCH, ALC892 Digital
IEC958 (S/PDIF) Digital Audio Output
hdmi:CARD=PCH,DEV=0
HDA Intel PCH, HDMI 0
HDMI Audio Output
hdmi:CARD=PCH,DEV=1
HDA Intel PCH, HDMI 1
HDMI Audio Output
Looking at the samplerates those support, I get:
default / sysdefault: 4000-4294967295
hw:0 44100 48000 96000 192000
front: 44100 48000 96000 192000
surround*: 44100 48000 96000 192000
iec958: 32000 44100 48000 88200 96000 192000
hdmi: 32000 44100 48000 88200 96000 176400 192000
So there really is no reason I shouldn't be able to play at 44100.
The problem now is that mplayer does this in libao2/ao_alsa.c:
/* workaround for buggy rate plugin (should be fixed in ALSA 1.0.11)
prefer our own resampler, since that allows users to choose the
resampler,
even per file if desired */
#if SND_LIB_VERSION = 0x010009
if ((err = snd_pcm_hw_params_set_rate_resample(alsa_handler,
alsa_hwparams,
0)) 0)
{
mp_tmsg(MSGT_AO,MSGL_ERR,[AO_ALSA] Unable to disable resampling:
%s\n,
snd_strerror(err));
return 0;
}
#endif
The results in default's rate to be changed from 4000-4294967295 to 48000.
That is
defaults.pcm.dmix.rate 48000 in the config file as far as I know.
The next thing mplayer does is requesting the samplerate using
snd_pcm_hw_params_set_rate_near(), asking for 44100, but getting
48000 instead.
Using an other device than default/sysdefault does get me the
44100.
Kurt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
