On Sat, 12 May 2012 15:33:02 +0200 Kurt Roeckx 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
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:"
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
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 c
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
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 th
6 matches
Mail list logo
