On Jan 7, 2008 1:48 PM, Ritesh Kumar <<a href="mailto:ritesh@cs.unc.edu">ritesh@cs.unc.edu</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Jan 7, 2008 11:59 AM, Erik Slagter <<a href="mailto:erik@slagter.name" target="_blank">erik@slagter.name</a>> wrote:<br></div><div class="gmail_quote"><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>> I was wondering if anybody was experiencing random cracks and pops (loud<br>> ones actually :( ) while using pulseaudio with intelHDA? I have the<br>> following configuration for my inbuilt intelHDA card and will be
<br>> thankful if somebody helped me out here. I haven't observed cracks and<br>> pops on my other card (Griffin iMic). I am using pulseaudio 0.9.8 which<br>> is able to acquire realtime scheduling priority and a nice level of -11.
<br><br></div>If you have true realtime scheduling, you don't need "nice" levels. If a<br>process in the realtime queue is ready to run, it will run, even if<br>there are dozens of processes in the "normal" queue ready to run and
<br>even if they are all nice'd -19 (the maximum).<br></blockquote></div><div><br>Hmmm... I am sure you are right. Will probably switch off renicing then.<br><br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Besides that, a properly designed sound system (software and hardware)<br>doesn't need a high priority to work smoothly.<br></blockquote></div><div><br>You mean even at low latencies?... quite a few people had me convinced otherwise. I was under the impression that realtime sound processing was important for directly interfacing musical instruments with a computer... may be not for day to day audio needs I guess.
However, I do recall using ecasound with my guitar... I never prioritized ecasound (with rtlowlatency buffering running directly over alsa hw) though and characterized the cracks and pops I heard then to the same.<br><br>
</div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>So you have another problem here, actually. How is sound reproduction
<br>using purely alsa (without pulse)?
<br></blockquote></div><div><br>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.
<br>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.<br><br></div></div></blockquote></div><br>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.
<br>I also removed fifo scheduling... (back to the default pulse 0.9.8 setup; nicing only)... it didn't seem to have an effect.<br><br>This brings up two questions:<br>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.
<br>2) Why did intel mandate 192kHz audio sampling in intel HDA? Are there any applications for such high sampling rates?<br><br>_r<br><br>