Michael Schwendt írta:
On Mon, 23 Jun 2008 16:37:27 -0700, Nifty Hat Mitch wrote:
>> yep. Still about triple speed.
>> Remember the vinyl records? Sounds like a 33 being played at 78. (If I
>> remember the numbers)
> Curious, is cpuspeed active?
> Since cpuspeed (see also powernow) can tinker with the processor's clock speed it
is 'possible' but unlikely
> that the audio code woke up with the CPU running at a low power slow speed and made
timing decisions that mismatch the
> CPU running at full speed.
Unlikely IMO. The audio chip would still process sample data at the
frequency it is set up by the driver to play with. On the contrary, if
there's a bug in the kernel driver or an incompatibility in alsa lib, the
result could be that 44.1 kHz sample data are played at 96 kHz, for
I was reading this thread and I wanted to say I have a similar problem
with a twist.
I am running F9/x86-64 on my main machine, it doesn't have problems with
I am also running a 32-bit LTSP5 thin client, everything is set up
the Fedora k12linux/ltsp docs. The client machine is a Compaq Deskpro EN
with PIII/866 CPU. And everything I tried on the thin client (software
on the 64-bit machine actually, sound is transferred to the client's
daemon) is played quicker. Youtube videos keep the video and sound in sync,
so the video as a whole is played faster. Some other software that prefers
syncing audio to the video speed produce dropouts in the sound.
My son especially notices it in ScummVM...
Watching time go on the thin client console (Ctrl-Alt-F2) didn't show
anything suspicious. One second seems to be really one second and
installing ntpdate/ntpd into the thin client didn't change the faster sound.