Re: [GnomeMeeting-devel-list] Choppy Audio / Audio Dropout

[Damien Sandras <dsandras seconix com>]

Hi Craig,


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?

Thank you,

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
> underrun/overflow.
> 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
> it.
> 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
> improvement.
> 
> > 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.
> 
> Regards,
> 
> _______________________________________________
> Gnomemeeting-devel-list mailing list
> Gnomemeeting-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
-- 
 _      Damien Sandras
(o-     
//\     Ekiga Softphone: http://www.ekiga.org/
v_/_    FOSDEM 2006    : http://www.fosdem.org/
        SIP Phone      : sip:dsandras ekiga net
                         sip:600000 ekiga net