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. I have two capture files that are almost entirely identical, one captured right after the other. One of them suffers from the constant pops problem, the other not so much (the first has maybe 15 loud pops over the course of the three seconds of capture; the second has one pop aside from the opening and closing of the PCM which always produces a sound a bit like a needle being picked up off of an LP record, if anyone else remembers what that sounds like). There is almost no difference between the two files. The timings are very slightly different, and for some reason, in the "no pops" case, the fifth snd_pcm_writei call failed with error code -32, which resulted in a subsequent snd_pcm_prepare and re-write of the data which then succeeded. Otherwise, the sequences are fairly identical. I have played around and added large start thresholds, but they don't have any effect. The amazing thing is that with my retrace_alsa program, the playback is absolutely identical each time and the audio defects are 100% identical between runs. The status code of the ALSA calls is even identical, down to the fifth snd_pcm_writei always failing with the same error code -32 in the nopops case. It's absolutely eerie that it can be so reproducible. The "no pops" trace file is at: http://www.ischo.com/trace_alsa_out.nopops.gz The "pops" trace file is at: http://www.ischo.com/trace_alsa_out.pops.gz And the program to replay the traces is at: http://www.ischo.com/retrace_alsa.c Once again, to use these files: $ gunzip trace_alsa_out.nopops.gz $ gunzip trace_alsa_out.pops.gz $ gcc -o retrace_alsa retrace_alsa.c -lasound -lrt $ ./retrace_alsa < trace_alsa_out.nopops $ ./retrace_alsa < trace_alsa_out.pops If anyone has any clue whatsoever about what could cause such a vast and reproducible difference in the audio output of these two files, I would love to hear about it. Also - this problem is not always reproducible on all hardware. On one machine that I have access to, that uses an Intel ICH10 integrated audio solution, I don't get any pops no matter what. But on my home workstation, which has: card 0: SB [HDA ATI SB], device 0: ALC892 Analog [ALC892 Analog] I do get the pops. Is it just that the card sucks and everything I am doing is kosher, or is my code doing something to cause these pops? And - can anyone else see the value in a tool like this retrace_alsa program I wrote? I think it's pretty cool to be able to capture and perfectly replay a set of calls into the ALSA library to accurately and easily reproduce problems. ALSA gurus can see exactly the sequence of ALSA calls that were done and can even re-play them on their own systems with very close to identical timings. I think that could be a very powerful debugging tool. Maybe there are already existing solutions that do stuff like this - record the sequence of calls made into a shared library, along with timestamps, and all parameter data, saving the captured data into a file, and providing a program for re-playing those same calls again at will? If there is a general way to do this, someone please let me know; because it was a bit of a pain in the butt to implement the capture software and the replay software, and my implementation is incomplete in that I only trace and replay exactly those ALSA library calls that my program makes, not any of the other 1,400+ ALSA functions that I find listed in libasound.so ... I never posted my capture code but it's kind of obvious; it just implements some ALSA functions and uses dlopen to manually open libasound, passing through the calls to the ALSA library but first logging them to a file. You have to use LD_PRELOAD of course to get my symbols to be used in preference to the real ALSA ones. Any help at all with my strange audio popping problem would be most appreciated. 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
