Playing a WAV file on x86_64 I saw
aplay ~/ICMC/Goteborg_2002/100_s.wav
Playing WAVE ‘/bigdisk/jpff/ICMC/Goteborg_2002/100_s.wav’ : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
underrun!!! (at least 1240233958161.584 ms long)
underrun!!! (at least 1240233962269.669 ms long)
xenakis:~ 412>
which I think is 39 years, which I think I would have noticed
==John ff
+1
This also happens with arecord. My recording script used to lose snippets of capture now (overrun, not underrun though) and then but the loss was in the milliseconds. Now when it does happen (rarely due to fast processor) it’s 39 years like you, which of course is ridiculous. Sorry I have no explanation either, but I suspect it’s to do with timestamps, negative deltas or something like that in the sound driver packets.
I am familiar with underruns and overruns; it was the 39 years that worried me!
I guess it is an alsa problem, and may be only on 64bit. BTW I shoul have said I was using OpendSuSE 11.0
I think you have a mix of different alsa versions running. Just pick one of old_cpu’s posts, it will guide you through setting up audio
Mine are the stock packages, nothing extra added from the ALSA repository. It started happening in 11.0, that’s why I suspect some kernel interaction with ALSA.
This is what it looks like on my laptop:
glosscomputer@LapTop:~> aplay /opt/kde3/share/apps/ktuberling/sounds/nl/sigaar.wav
Playing WAVE ‘/opt/kde3/share/apps/ktuberling/sounds/nl/sigaar.wav’ : Signed 16 bit Little Endian, Rate 8000 Hz, Mono
glosscomputer@LapTop:~>
It plays all loud and clear.
losscomputer@LapTop:~> rpm -qa | grep alsa
alsa-firmware-1.0.20-6.1
alsa-tools-gui-1.0.20-7.1
alsa-devel-1.0.20-2.1
alsamodular-1.8.7-4.193
alsaplayer-0.99.80-8.3
alsa-utils-1.0.20-9.2
alsa-oss-32bit-1.0.17-2.3
alsa-tools-1.0.20-7.1
tsalsa-20080914-0.pm.1
FA_clalsadrv-1.2.2-0.pm.3
alsa-1.0.20-2.1
alsa-oss-1.0.17-2.4
alsa-plugins-1.0.20-7.3
Please read some of old_cpu’s posts about sound. It’s amazing how many people get there audio sorted once and for all through these posts.
It’s not the situation you imagine it to be. This is not your typical “my sound won’t work” or “my sound is very soft” or “my sound is distorted” situation. The sound quality is fine and has been fine for a long time. It’s just that once in a while, there will be overruns of a few milliseconds when recording. An overrun means that the CPU could not get the data out of the sound card in time before new samples arrive. The result is a loss of a few milliseconds of samples. You have to listen carefully to notice the loss. Since I was recording radio programs, I was not too fussed about it. If I was careful not to do things like start an X session, or burn a CD, I could get a recording with no overruns. And since I upgraded to a faster system, it only happens perhaps once a month. The weird thing is that before 11.0 it used to report credible overrun times like 2 milliseconds or 7 milliseconds. Now the times are totally unbelievable, 39 years, as mentioned, which probably means some bug in calculating the amount of overrun.
Incidentally I’m recording 44100 16-bit stereo samples per second (CD quality) so that means that every second, the sound card is generating 176400 bytes of data.
Overrun happens when something has distracted the CPU for too long. I could try a real-time kernel to see if this helps, but since it only happens rarely, and the loss of a few milliseconds is hardly audible, I prefer to leave well enough alone. I believe there are some execution paths in the kernel that lock out interrupts for too long, and the kernel developers have been slowly eradicating those.
So you are just barking up the wrong tree.
Barking up the wrong tree? You’re right. And I should have known. Some of my music friends use real-time kernels for exactly this reason. But this in not even about that, it’s called a bug indeed. And an ugly one. Excuses for reacting too fast.