On Wed, Dec 23, 2009 at 05:39:16PM +0100, Mads Kiilerich wrote: > Stefan Schoenleitner wrote, On 12/23/2009 12:08 AM: > > I mean how should it work with an alsa plugin if not even this simple simulation code works > > in a timely and precise manner ? > > * What am I doing wrong ? > > I thought of adding buffering so that the socket read operations do not have a strict timing schedule. At this point you're not really dealing with ALSA issues at all, the scheduling of tasks in Linux is handled by the core kernel scheduler code. Rather than looking at the audio APIs it seems like you'd be better off looking at either reducing your dependency on highly accurate scheduling or looking at how to work best with the scheduler to get the best possible performance from it. > > It is connected over UART at 460800 baud and requires exactly 160 16bit PCM samples > > with 8kHz sampling rate each 20ms for speech compression. > It is my experience that it matters that two different oscillators never > have exactly the same frequency, so over time you will get an over- or > under-run. Indeed. If you've got two different clock domains and no way of lining them up you'll eventually get drift between the two sufficient to cause an under or overrun if you run for long enough without a break. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
