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. I have written a shared library to override the ALSA functions that I call and to record them and their data to a file, and another program to read back this output and "replay" the ALSA calls in the same order with as close to the exact same timings as possible. I used these tools to capture the sequence of ALSA calls that results in these pops. The capture file is available at: http://www.ischo.com/trace_alsa_out.gz The C file containing the program for replaying that is at: http://www.ischo.com/retrace_alsa.c To compile: gcc -o retrace_alsa retrace_alsa.c -lasound To run: (first, gunzip trace_alsa_out.gz) then: retrace_alsa < trace_alsa_out You can look at the trace_alsa_out file and see the sequence of ALSA calls that it has logged, as well as the data that is being played. I think the format of the lines is readable and easy to understand, here is a sample from the file: 000000000: start 000672261: 0: 0: snd_pcm_open default 0 0 000675388: 0: 0: snd_pcm_hw_params_any 140099034019744 000675500: 0: 0: snd_pcm_hw_params_set_access 140099034019744 3 000675537: 0: 0: snd_pcm_hw_params_set_format 140099034019744 2 000675563: 0: 0: snd_pcm_hw_params_set_channels 140099034019744 2 000675585: 0: 0: snd_pcm_hw_params_set_rate_near 140099034019744 48000 0 0 000675628: 0: 0: snd_pcm_hw_params 140099034019744 000675749: 0: 0: snd_pcm_sw_params_current 140099034019584 000675751: 0: 0: snd_pcm_sw_params_set_start_threshold 140099034019584 0 000675754: 0: 0: snd_pcm_sw_params 140099034019584 000675761: 0: 0: snd_pcm_prepare 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 ... The first line just says that the capture has started. The other lines start with a timestamp which is the number of microseconds since start that the ALSA call was made. Then are two numbers (0: 0: for most lines), that are a snd_pcm_t identifier (the same snd_pcm_t always gets the same number, you can see from my file that I only ever open a single snd_pcm_t, always identified as 0), the second number is the return status of the ALSA call (0 in most cases, meaning success). Then follows the name of the ALSA call that was made, and then the arguments. For those ALSA calls that take a snd_pcm_hw_params_t or snd_pcm_sw_params_t, the big number is the address of that value as an integer; I use that on playback just as an identifier so that I always use the same instance in the right places (think of the big number as an ID); and then any subsequent arguments to the ALSA function are also printed out. For example: 000675563: 0: 0: snd_pcm_hw_params_set_channels 140099034019744 2 means that at 675563 microseconds after the program started, I called snd_pcm_hw_params_set_channels with the first snd_pcm_t that my program used (index 0), and a snd_pcm_hw_params_t that is identified as 140099034019744, and a channel count of 2. The snd_pcm_writei parameters are the 'size' parameter and additionally I print the number of bytes that were in the buffer that was passed to the snd_pcm_writei call, and then follow that with all the bytes. Anyway, I had hoped that this would be a good way for ALSA gurus to evaluate whether or not I was calling ALSA functions in the right order, with the right parameters; and also to re-play exactly the sequence of calls, timing, and data that I used to further diagnose the problem. If you replay those ALSA commands using my tools, you will hear a bunch of pops. Can anyone explain exactly what causes them? Is it the data? Something I have mis-configured on the PCM? Bad timing? Something else? The thing is that I don't hear these pops on some hardware, but do on others. I can provide more details tomorrow when I have gotten some sleep (it is 2:10 am here!). Also sorry the retrace_alsa program is so poorly written, I hacked it together really quickly. 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
