Re: [GnomeMeeting-devel-list] Choppy Audio / Audio Dropout
- From: Damien Sandras <dsandras seconix com>
- To: GnomeMeeting development mailing list <gnomemeeting-devel-list gnome org>
- Subject: Re: [GnomeMeeting-devel-list] Choppy Audio / Audio Dropout
- Date: Fri, 31 Mar 2006 09:31:42 +0200
There is a variable named "soundChannelBuffers" in src/opal/pcss.cxx.
Just to make sure, can you try changing its value to 1 and to 3, 4, ...
to see if it makes a difference without your patch or not?
Le vendredi 31 mars 2006 à 02:23 +0100, Craig Shelley a écrit :
> On Thu, 2006-03-30 at 10:29 -0800, Dan Sandberg wrote:
> > Hi Craig,
> > This is great! I've been wrestling with the same problem myself and
> > haven't known where to start fixing it.
> Cool, have you tested it on your system and had successful results?
> > So what is the problem exactly -- the ALSA driver doesn't queue the
> > audio if it gets behind, it simply throws away audio? How do you know
> > that this is a ALSA specific problem rather than an inherent property of
> > the sound hardware? Does the problem not happen with OSS drivers?
> Essentially the problem occurs when the audio buffer for playback
> underruns, or when the buffer for recording overflows. In either case,
> data is lost, and the audio drops out while things resync. Obviously
> this is more likely to happen when the buffers are small. In this case
> the buffers are intentionally small in order to provide low-latency
> communications. For XMMS and other audio applications, the buffers can
> be much bigger, making the playback much more robust.
> The problem occurs when the buffer is not being serviced (read from /
> written to, depending if recording / playing) by the application
> frequently enough.
> For example, if the sound driver is configured to use a buffer such that
> it contains 40mS worth of audio samples, the application must service
> this buffer at least once every 40mS in order to prevent
> So the thread that is responsible for regularly servicing a buffer such
> as this must not do anything that is either too computationally
> intensive, or any operations involving the OS that are likely not to
> return in time, for example file/network IO.
> A further issue arises by the fact that the OS will be multi-tasking, so
> at any point during the execution of the buffer service routine, the OS
> could decide that this thread has been executing for long enough, and
> will switch context to some other process/thread, and give that some CPU
> time. This issue can be solved to some extent by setting the scheduling
> policy for the thread, and giving it a high scheduling priority.
> Another problem is where certain device drivers hog the CPU for long
> periods of time, possibly several tens/hundreds of milliseconds. What is
> worse, since these CPU hogging sessions can be triggered by a hardware
> interrupt, they can occur at any time.
> The general solution is:
> * Put the low-level service routines in a thread of their own
> * In the main service loop do not make any system calls, or perform
> operations that directly cause IO or a context switch.
> This includes printing messages to stdout/stderr & calling malloc/free
> * Ensure that the hardware buffer size is large enough to cope with the
> potentially random latencies caused by device drivers.
> * The software buffer managed by the thread should be big enough to deal
> with the latency of the rest program performing IO operations, and
> context switches to other applications. However it must be small
> enough as not to cause too much lag to the user.
> * The thread can optionally be given higher scheduling priority if
> sound dropouts are still occurring, eg with small buffers.
> > If it is truly ALSA specific, has there been a bug report / patch
> > proposal for ALSA?
> For me, these problems were solved by modifying the alsa output plugin
> of pwlib. In hindsight, I should have made the modification in the opal
> library, thus enabling it to work with all output plugins, and should
> also work on windows. All I have done here, is to prove the theory in
> the simplest way I could see. The actual implementation would be to
> rewrite this in the proper place, and perhaps give the user the ability
> to set the buffer size, like the "jitter buffer", or possibly replacing
> Unfortunately I don't have any spare time now until the summer, so it'll
> have to be done as a feature request or similar, or potential future
> > Finally, is there an improvement without the 'chrt ...' command? Having
> > to do that seems like the problematic
> > part of the solution, the rest can be cleaned up...
> Yes definitely, on my system, without the realtime scheduling, there is
> still a vast improvement. I still get the occasional dropout when
> changing between workspaces while the system is under load. With the
> realtime scheduling, it is almost impossible to cause dropout.
> I can even switch between X and console with no problems, that is
> something even XMMS fails with on my system.
> Gnomemeeting-devel-list mailing list
> Gnomemeeting-devel-list gnome org
_ Damien Sandras
//\ Ekiga Softphone: http://www.ekiga.org/
v_/_ FOSDEM 2006 : http://www.fosdem.org/
SIP Phone : sip:dsandras ekiga net
sip:600000 ekiga net
] [Thread Prev