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, -- Craig Shelley EMail: craig microtron org uk Jabber: shell jabber earth li
Attachment:
signature.asc
Description: This is a digitally signed message part