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 > example. > 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 sound. I am also running a 32-bit LTSP5 thin client, everything is set up according to 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 running on the 64-bit machine actually, sound is transferred to the client's pulseaudio 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. Best regards, Zoltán Böszörményi -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
