design suggestions for minimal-latency full-duplex io?

design suggestions for minimal-latency full-duplex io?

[Marcus Blomenkamp]

Hi there.

What is the best way to achieve minimal transport latency in an application 
constanty capturing data from one interface and playing it through another. 
The purpose of this app would be some kind of software loop-through 
converter. My problem domain is that I have my PC connected to an amplifier 
through SPDIF while the TV-card is connected to the soundcard only through 
analog wires. However my sound chip CMI8738 does not suppport hardware 
realtime monitoring from analog input to digital output. So my suggestion was 
to concurrenly read data from the ADC input and write it to SPDIF output.

I initially wrote this as an OSS app but i'm slightly dissappointed about the 
minimal IO latency I could reach with the common iterative read/write 
mechanism. So I decided to try the ALSA way to reduce the throughput delay.

Is it possible to have both stream pointers working on the same physical 
buffer? A slightly delayed start of playback should then give a nice IO 
latency. Are there any other approaches viable? Ideally i'd like to get this 
working while not depending on userspace scheduling heavily.

Any suggestions/constraints about the following ideas?
1. traditional blocking read/write in seperate threads
2. traditional non-blocking read/write in a single thread
3. asynchronous SIG_IO triggered read/write handling
4. mmap'ed buffer for read+write

Especially for the last candidate i'd appreciate any kind of pseudo-code since 
i'm not yet quite familiar with ALSA and MMAP audio IO.

Regards, Marcus



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: design suggestions for minimal-latency full-duplex io?

[Paul Davis]

>Is it possible to have both stream pointers working on the same physical 
>buffer? A slightly delayed start of playback should then give a nice IO 
>latency. Are there any other approaches viable? Ideally i'd like to get this 
>working while not depending on userspace scheduling heavily.

you have to depend on userspace scheduling unless you write a kernel module.

>Any suggestions/constraints about the following ideas?
>1. traditional blocking read/write in seperate threads
>2. traditional non-blocking read/write in a single thread
>3. asynchronous SIG_IO triggered read/write handling
>4. mmap'ed buffer for read+write

the JACK code for its alsa_driver shows the way to get the lowest
latency and greatest efficiency that i know of without playing "dirty"
tricks.

it uses mmap access, and sleeps using poll(2) to wait for the audio
interface to be ready. read/write access would not change the latency,
it would be just a little less efficient for large numbers of
channels. the code is rather complex, however. there is a simpler
example in my ALSA primer which has links on the ALSA programmers
documenation page at www.alsa-project.org.

personally, i'd just fire up JACK and use a slight, tiny modification
to the jack_simple_client example to do this. you hardly have to write
any code then.

--p


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com