On Wed, 18 Mar 2009 18:32:00 +0100 Alexandre Ratchov <a...@caoua.org> wrote: > On Wed, Mar 18, 2009 at 06:05:18PM +0100, Thomas Pfaff wrote: > > I have the same problem here, running with or without the aucat > > server. I've tried setting a large buffer and a high priority > > on the aucat server process to no avail. > > what priority / buffer size are you using?
-20 and as big as 132k. Makes no difference ... > does the underrun occur on the aucat side or on the application > side? Not sure, but since the same problem occur even if I'm not using aucat (application accessing audio(4) directly) I'm guessing the problem is somewhere deeper in the "stack". > - you can check this by running aucat with AUCAT_DEBUG=2 and if you > get ``mix_xrun: drop = 0'' messages during stuttering, then the > application is not providing data fast enough $ AUCAT_DEBUG=2 aucat -l & $ mpg123 test.mp3 # Start and close firefox a couple of times pipe_write: socket: wrote 40 bytes in 31739us safile_read: hdl: got 11648 bytes in 103190us pipe_write: socket: wrote 40 bytes in 31780us pipe_write: socket: wrote 40 bytes in 31717us safile_read: hdl: got 11648 bytes in 31753us ^C No xrun messages, but I get the above when starting Firefox and the sound starts to stutter (just for a second or two, then it resumes normal playback). > - if ``audioctl play.errors'' is increasing, then aucat is being > preempted by other applications. $ audioctl play.errors play.errors=0 > Oh, last point: a related bug was fixed very recently in aucat, so > check that it's up to date. cvs status says I'm up-to-date.
