> I think you would have to customize the driver to do this. In the > special case that you are playing back the recorded input, you write the > input buffer directly to the output buffer every time the input buffer > interrupts because it is time to empty it. Adds an extra branch in the > driver logic, and it has to know things outside of kernel space that it > doesn't know now. Or if you are only going to use the card this way, > you always do it. No need for extra branch or state knowledge. Hey, if > you are going to customize drivers, why not make them really specific? > :-) > > The idea that Florian suggested, shrinking the latency by shrinking the > callback interval and increasing the frame rate is easier from user space. Yes it is but as I said I don't want to increase neither the samplerate nor decrease the framesize since 48 kHz at 256 samples/frame is still ok in terms of network conditions. Otherwise effects of network jitter mess the stream up. So in turn I wouldn't mind having a *very* specific solution since this topic is in fact very specific. Thanks for the help so far, best -- A l e x -- Dipl.-Ing. Alexander Carôt PhD Candidate Email : Alexander@xxxxxxxx Tel.: +49 (0)177 5719797 GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx ------------------------------------------------------------------------- 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@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
