> If I understand your question correctly, it is because they use two > different buffers. If you aren't trying to play the capture buffer, it > would wreak havoc to try to use it for playback while capture is going > on. So there is a buffer for capture and a buffer for playback. And > each has a latency. Someone who understands the system better might be > able to give a better explanation, or even suggest a workaround.
Sure - there is one input double buffer and one output double buffer. However, I wonder if there is a way to (somehow) get rid of the latter. The idea is the following : 1.) Of course there has to be an input double buffer which generates the desired block of samples. 2.) Once this is generated it takes 2,6 ms to generate the next one. 3.) Rather than using a double buffer for the playout wouldn't it be possible to choose only one physical playout buffer and parse the captured data in right at the interrupt. Or would this approach lead to timing and synchronisation problems ? I can see that either a parsing slightly too fast or too slow would result in wrong data but anyway - just an idea. What do you think ? Best regards -- A l e x -- Dipl.-Ing. Alexander Carôt PhD Candidate Email : [EMAIL PROTECTED] Tel.: +49 (0)177 5719797 Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
