Hi Jochen, > 2. use a lower frame size, than my codec/systems framing. (e.g. 128 > instead of 256, but still transmit 256 in one pass) Yes - a good idea, however, sometimes depending on the actual machine and OS (or even low-latency patches) problems might occur when running below 256 samples/frame - especially when running the coding and network functionality. This is why I am trying to approach a solution that simply gets rid of the playout latency. > You know that you can have one frame(-1 sample) additional delay, > depending on the absolute framing of sender and receiver sound cards? > E.g. the sender starts to grab samples at sample time 0, encodes it > and sends it to the receiver. lets say the receiver has exactly the > same framing as the sender and starts its play-out at sample time 0 as > well. The transmission/decoding/etc needs one sample time and so the > receiver has the current frame available at sample time 1. It just > played out the last frame (at time 0) and the current frame needs to > wait framesize-1 samples, and therefore almost one frame of additional > delay. > Regarding a double/multi buffers in ALSA, I have not played around > yet, but maybe the threshold values for starting the play-out are a > good starting point. Did you try those? You know, at play-out, the > delay is not introduced by the number of 'periods', but the time the > play-out starts. I once implemented a soundcard synchronisation which parses an incoming buffer slightly before the receiving card´s interrupt. The problem in that context is that the receiver is also a sender, which messes up this principle into the other direction. In turn this means that a sync at T/2 (half of the period) for both cards is most useful since it provides an equal delay for both ends. The reason why this practically still doen't work is that depending on the actual soundcard very often there is a slight soundcard drift which messes up this synchronisation over time anyway. It would be great to keep up the discussion. Thanks -- A l e x > > Best Regards, jochen > > On 10.Jun, 2008, at 17:02 , Alexander Carôt wrote: > > >> 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 : Alexander@xxxxxxxx > > 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@xxxxxxxxxxxxxxxxxxxxx > > https://lists.sourceforge.net/lists/listinfo/alsa-user > > - jochen > gpg: 1024D/FFE35929 > > -- 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
