Linux: Timing during recording/playing sound

I have a more general question, regarding timing in a standard Linux-OS dealing with playing sound and receiving data over a serial port.

In the moment, I'm reading a PCM-Signal arriving over a USB-to-Serial Bridge (pl2303) which is recorded, encoded and sent from a FPGA.

Now, I need to create "peaks" at a known position in the recorded soundstream, and plan to play a soundfile from the same machine which is recording at a known moment. The peak has to begin and stop inside windows of maximal 50ms, it's length could be ~200ms...

Now, my question is: How precise can I expect the timing to be? I know, that several components add "unkown lag", jitter:

• USB-to-Serial Bridge collects ~20 bytes from the serial side before sending them to the USB-side (at 230400Baud this results in ~1ms)
• If I call "`sleep 1; mpg123 $MP3FILE` &" directly before my recording software, the Linux-Kernel will schedule开发者_开发问答 them differenty (maybe this causes a few 10ms, depending on system load?)
• The soundcard/driver will maybe add some more unkown lag...
• Will tricks like "nice" or "sched_setscheduler" add value in my case?
• I could build an additional thread inside my recording sofware, which plays the sound. Doing this, the timing may be more precise, but I have a lot more work to do ...

Thanks a lot.

I will try it anyway, but I'm looking for some background toughts to understand and solve my upcoming problems better.

---

I am not 100% sure, but I would imagine that your kernel would need to be rebuilt to allow the scheduler to reduce latency time in switching tasks a la multitasking, in kernels 2.6.x series, there's an option to make the kernel more smoother by making it pre-emptible.

• Go to Processor Type and features
• Pre-emption Model
• Select Preemptible kernel (low latency desktop)

This should streamline the timing and make the sounds appear smoother as a result of less jitters.

Try that and recompile the kernel again. There are of course, plenty of kernel patches that would reduce the timeslice for each task-switch to make it even more smoother, your mileage may vary depending on:

1. Processor speed - what processor is used?
2. Memory - how much RAM?
3. Disk input/output - the faster, the merrier

using those three factors combined, will have an influence on the scheduler and the multi-tasking features. The lower the latency, the more fine-grained it is.

Incidentally, there is a specialized linux distribution that is catered for capturing sound in real-time, I cannot remember the name of it, the kernel in that distribution was heavily patched to make sound capture very smooth.

---

it's me again... After one restless night, I solved my strange timing-problems... My first edit is not completely correct, since what I posted was not 100% reproducible. After running some more tests, I can come up with the following Plot, showing timing accuracy:

Results from analysis http://mega2000.de/~mzenzes/pics4web/2010-05-28_13-37-08_timingexperiment.png

I tried two different ubuntu-kernels: 2.6.32-21-generic and 2.6.32-10-rt

I tried to achieve RT-scheduling: sudo chrt --fifo 99 ./experimenter.sh

And I tried to change powersaving-options: echo {performance,conservative} | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

This resulted in 8 different tests, with 50 runs each. Here are the numbers:

                                   mean(peakPos)  std(peakPos) 
rt-kernel-fifo99-ondemand          0.97           0.0212 
rt-kernel-fifo99-performance       0.99           0.0040 
rt-kernel-ondemand                 0.91           0.1423 
rt-kernel-performance              0.96           0.0078 
standard-kernel-fifo99-ondemand    0.68           0.0177 
standard-kernel-fifo99-performance 0.72           0.0142 
standard-kernel-ondemand           0.69           0.0749 
standard-kernel-performance        0.69           0.0147