On 06/14/12 04:05, Clemens Ladisch wrote: > Bryan Ischo wrote: >> Hello. I have a program that uses ALSA for audio and I don't understand >> why I get lots of pops when starting playback but only on some hardware. >> >> 000675767: 960: 0: snd_pcm_writei 960 3840 >> 00 00 00 00 c0 f1 c0 f1 c0 f1 c0 f1 c0 f1 c0 f1 >> c0 f1 c0 f1 c0 f1 c0 f1 c0 f1 c0 f1 c0 f1 c0 f1 >> ... >> c0 f1 c0 f1 c0 f1 c0 f1 c0 f1 c0 f1 c0 f1 c0 f1 >> 000688842: 960: 0: snd_pcm_writei 960 3840 >> 00 00 00 00 c0 f1 c0 f1 c0 f1 c0 f1 c0 f1 c0 f1 >> c0 f1 c0 f1 c0 f1 c0 f1 c0 f1 c0 f1 c0 f1 c0 f1 > There are pops in the data you're playing. Thank you very much for your response! I don't understand PCM encodings well enough to know what to expect to hear from the data, but I'm guessing that it's the zeros at the beginning of each bit of data that is doing it? If so, I only see two occurrences of those sequences in the data. Here's the part I don't understand ... on some hardware, I don't get the pops. I get two very soft pops when I replay those ALSA calls on one machine, and I get a sequence of very loud pops on another. The former actually may be expected - corresponding to the two zero segments in the data. But on the other hardware, I get continual popping from the exact same replayed ALSA sequence, and I don't understand why the result should be so different. >> 000675751: 0: 0: snd_pcm_sw_params_set_start_threshold 140099034019584 0 > start_threshold 0 does not make sense; this is likely to result in > underruns if you write very few samples. This is typically set to > something like the period size or the buffer size. > My application generates sound data in realtime and "should" be fast enough to always supply data on time. I am trying to get the lowest latency possible while at the same time avoiding underruns, or at least doing something reasonable when they happen. Previously I was setting the start threshold to about the period size, but I lost that in a merge and by the time I noticed I realized that I wasn't hearing any bad side effects from the 0 threshold; but maybe these pops are the bad side effect? Here is a technique I have tried to reduce the effect of underrun. In my application, underrun either means that the process that is generating audio can't keep up (it's a game emulator, generating audio and video frames at a fixed rate, and some games can't be emulated at full speed and so don't generate audio fast enough, and in that case, the user experience is not going to be great; I'd rather have choppy audio than pops though so this is why I tried the following technique): snd_pcm_sw_params_get_boundary(sw_params, &boundary); snd_pcm_sw_params_set_stop_threshold(pcmM, sw_params, boundary); snd_pcm_sw_params_set_silence_threshold(pcmM, sw_params, 0); snd_pcm_sw_params_set_silence_size(pcmM, sw_params, boundary); The idea here is to play silence on underrun instead of looping (which sounds bad), and also to avoid having to re-prepare the device after underrun which takes time and only compounds the performance problem that is resulting in underruns. The thing is, this technique didn't work on some hardware - once ALSA played silence instead of underrunning one time, it never would play anything again. I didn't investigate too deeply though. Is this technique sensible at all? Please note that I am *not* using this technique in my program currently, which is why you don't see any of those calls in the captured ALSA call log. Thank you! Bryan ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
