On Sat, 12.01.08 13:49, Ritesh Kumar (ritesh at cs.unc.edu) wrote: > > I had no such cracks and pops earlier with alsa+dmix running at 192Khz. I > > had even added the speex resampler to alsa+dmix and faced no problems. The > > CPU usage for the audio application used to go up quite a bit (14%) due to > > the resampling but that's expected. However I did notice a good amount of > > latency then with games which I played through alsa-oss. I won't say padsp > > is perfect but it is surely much better latency wise. > > Please note that the applications I am using send sound to pulseaudio > > using either gst-pulse or alsa-pulse... and I saw cracks and pops with both. > > > > > I am running pulseaudio without any cracks and pops now. The difference is > that now the intel HDA sink runs at 48kHz instead of 192kHz. However, the > cracks and pops come back after a suspend-to-ram. > I also removed fifo scheduling... (back to the default pulse 0.9.8 setup; > nicing only)... it didn't seem to have an effect. > This brings up two questions: > 1) Can suspend-to-ram cause timing problems in pulseaudio? If not then the > kernel's USB audio driver seems to be doing something fishy here. Generally PA should survive STR. But many drivers don't. As usual with STR, YMMV. > 2) Why did intel mandate 192kHz audio sampling in intel HDA? Are there any > applications for such high sampling rates? They didn't mandate 192 kHz. HDA leaves a lot of room for specific implementations. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4
