On Jan 7, 2008 11:59 AM, Erik Slagter <<a href="mailto:erik@slagter.name" target="_blank">erik@slagter.name</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>> 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><br>Hmmm... I am sure you are right. Will probably switch off renicing then.<br><br></div><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><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><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><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><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>I have a similar problem in that a pulse stream plays for a few moments,<br>starts to hiccup and then stops altogether. It doesn't matter which
<br>program I use. Using alsa directly there is no problem. On my other<br>computer it works like expected, though. I have no need to use pulse<br>anymore (it doesn't solve my problem) so my problem is gone ;-)<br></blockquote>
<div><br>:)<br>I needed low latency mixing (primarily)... and the convenience of switching between audio sinks dynamically (secondarily). I like the idea of per application volume mixing but I would rather keep the UI component tied to the application itself than keep it separate... I am guessing pulseaudio does provide a mixer/sink manipulation API... a little gtk+ embeddable component to control these easily would provide a consistent audio control interface across many applications.
<br><br>What was problem you wanted to solve... (network audio?). May be I can help.<br><br>_r<br><br></div></div>