On Wed, Jul 21, 2010 at 03:10:45PM +0400, Dmitrij D. Czarkoff wrote: > Jacob Meuser <[email protected]> wrote: > > > can you try running the following? save it to a file, let's call > > it audrops.c then build it with 'make LDFLAGS=-lm audrops'. > > > > let that run for a while, at least as long as it takes for you to > > normally hear drops and echos. start it with simply ./audrops. it > > should play a steady tone. does it print much? do you hear drops > > and/or echos? > > I let it run for three minutes. During this run I've heard 9 drops with 5 of > them being either long or double (sounded as two clicks one right after > another). > > I actually ran it twice, but the first time I lowered volume with "mixerctl > outputs.master=150" and that led to having less drops. I didn't actually > mesured the effect, but I can if it would help.
you're saying the volume made a difference in how often there were underruns? that is quite odd. hmmm. > At the moment of volume switching I also hear the drops (as far as I can get, > the drops of a higher of switching volumes either on gettting volume lower or > higher). that is strange too. I have, somewhere, a program that twiddles every control on the mixer as fast as possible, several thousand mixer set/get cycles a second, and it hassn't caused dropouts on machines I've run it on. there is a possibility for contention there, but the window should be very small. mixer commands should complete within a few microseconds. > The output of the max volume run (I actually have the volume at max by > default, because I use built-in speakers that are actually weak): > > % ./audrops > pre=16 ch=2 bpf=4 block_size=4096 rate=48000 block_usec=21333 > early return at 1279710059.088985: 416 < 21333 > early return at 1279710059.089085: 100 < 21333 > late return at 1279710065.556951: 559520 > 21333 > late return at 1279710099.639360: 571912 > 21333 these measurements are in microseconds. the above is two times where a single write() of 4096 bytes, which should take approx 21 ms, to complete, took over a half second. > early return at 1279710099.643480: 4120 < 21333 > late return at 1279710109.588648: 426470 > 21333 > early return at 1279710109.588793: 145 < 21333 > early return at 1279710109.588900: 107 < 21333 > early return at 1279710109.589009: 109 < 21333 > early return at 1279710109.589134: 125 < 21333 > early return at 1279710109.589252: 118 < 21333 > early return at 1279710109.589372: 120 < 21333 > early return at 1279710109.589448: 76 < 21333 > early return at 1279710109.589513: 65 < 21333 > early return at 1279710109.589581: 68 < 21333 > early return at 1279710109.589650: 69 < 21333 > early return at 1279710109.589718: 68 < 21333 > early return at 1279710109.589785: 67 < 21333 > early return at 1279710109.589854: 69 < 21333 > early return at 1279710109.589922: 68 < 21333 > early return at 1279710109.589991: 69 < 21333 > early return at 1279710109.590059: 68 < 21333 > early return at 1279710109.590127: 68 < 21333 > early return at 1279710109.590195: 68 < 21333 > early return at 1279710109.590271: 76 < 21333 this is very strange. that block of write()s should have taken 0.404327 seconds to complete, but it completed in 0.002625 seconds. do you have clock issues? are you running ntpd? > late return at 1279710144.015969: 549096 > 21333 > early return at 1279710144.021564: 5595 < 21333 > late return at 1279710149.541125: 570146 > 21333 > early return at 1279710149.547019: 5894 < 21333 > late return at 1279710161.240031: 556813 > 21333 > early return at 1279710205.846800: 7957 < 21333 > late return at 1279710212.051492: 551253 > 21333 > early return at 1279710212.054930: 3438 < 21333 > early return at 1279710236.439423: 10074 < 21333 > ^Cpre=16 ch=2 bpf=4 block_size=4096 rate=48000 block_usec=21333 > bytes written = 34627584 > bytes processed = 34545664 > bytes errors = 73728 this is about the simplest possible audio application. no reading data from disk, not synthesizing the samples. I don't see how this could have underrun so much. what else was running while you ran this? > bytes buffered = 8192 > 34627584 == 34627584 ? > run time = 183.473831 s > avg rate = 47071 one final question, do you have any sort of power management features enabled in the BIOS? hmmm, if the codec is somehow under powered, I guess that could explain the correlation between higher volume and more dropouts? maybe? iirc, you have an eapd mixer control. have you tried switching that to off? I've heard rumors that these are sometimes inverted ... eapd (external amp power down) is a tricky name. -- [email protected] SDF Public Access UNIX System - http://sdf.lonestar.org
