Thanks for the reply. I need to read the audio samples, process them, and then send them to the audio hardware for output. The total time from when a sound is sent into the hardware to the time when the sound comes out post processing is of interest to me. The maximum that I can accept is around 30-50ms. Currently, I've got around 90ms, which is unacceptably long. If I can get realtime interrupts on the gumstix, I'm hoping to reduce this latency to the time for the sound hardware to process one DMA fragment (size of a fragment / sound bps) plus the processing time. On other architectures, this is what I've seen.. but I'm unaware of if the UCB1400 is the same.
Craig, I'm curious, what kind of audio application needs real time?
And what latency are you talking about? Do you mean the minumum time
to store a sample from the audio hardware?
Craig Casey wrote:
> I was planning on using the RTLinux 2.4 kernel on my gumstix just to
> check the minimum latency of the audio hardware. Then I can mess with
> the interrutps on 2.6 to get the realtime performance I need once i've
> verified the minimum performance of the hardware. So I really need to
> run Linux 2.4. Have you never put linux 2.4 on the gumstix?
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
gumstix-users mailing list