On 06/14/12 23:12, Bryan Ischo wrote: > 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. >> >>> 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. > > OK, I've done some more data gathering. And now, even more data gathering. The behavior of ALSA is truly bizarre to me here. I can take my ALSA capture files as I posted in my last email and manually edit them to change the sequence of or timing of ALSA calls that are made. If I change *just* the PCM name that I open; e.g. change this line from my capture file: 000668371: 0: 0: snd_pcm_open default 0 0 to this: 000668371: 0: 0: snd_pcm_open hw:0,0 0 0 ... and change absolutely nothing else, then I don't get any of the pops at all. So the problem is clearly somehow related to the "default" PCM device, whatever that is. I am having a hard time figuring out what "default" actually means on my system. I *think* I should look at the file /usr/share/alsa/pcm/default.conf, but I have no idea how to interpret what I see in that file. Anyway, what's really weird to me is that *if* I switch my program to use hw:0,0 instead of default, then I don't get any pops - but I *do* get a different audio anomoly; at the very end of replay of the file, I get a very brief burst of whatever audio was last played by a separate, unrelated program. It's like there is some data left in a buffer that has persisted and somehow that data is being played out by ALSA at the very end of the run of my replay program. Weird. But it gets even weirder. If I run my replay program with the PCM device changed to hw:0,0, I get no pops and I get that other minor audio anomoly at the end of playback as I just mentioned. And then if I change the PCM device in my capture file back to default, on the *first run* of my replay program, I get no pops. But then on *every successive run*, I get the pops. It is 100% reproducible. If anyone has any clue at all what is going on here I would be most appreciative. Thanks, 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
