On Saturday 20 March 2010 16.46.02 steve-k@... wrote:
> > The problem is that all these small delays here and there add up to
> > larger delays. The problem is most noticeable in repeated audio in a
> > RepeaterLogic.
> > Also, delay is intentionally added by some SvxLink features like DTMF
> > muting.
> > Adding these delays up in the end will make you hear yourself when
> > releasing
> > the PTT. I've actually heard people on a couple of occasions calling QRZ
> > after
> > (unknowingly) hearing themselves after a transmission :-)
> Sorry, but this would happen if you had put the TX FIFO where it should be
> located, that is where RX and TX are connected together and before the
> squelch valve.
> Remember our discussion, it was your idea to but it at the very end of the
> TX chain, where all sources are connected together.
> I never had such a problem myself anyway, so it may be more related to the
> sound card driver.
I'm not sure I could have done it in another way but I'm always open to
suggestions. If there is a better solution I'm all for going in that
> > I guess what I'm saying is that the old FIFO, even though not properly
> > designed in theory, will perform better in certain situations due to the
> > current design of the audio pipe which force a designer of an audio
> > component
> > to think of what is happening after it in the pipe. Not good but that is
> > how
> > it is right now.
> I see the problem from a different perspective: The new FIFO can't be used
> because it does not work on all systems as expected, because it will
> produce audio drop-outs.
Well, your latest version may not have drop outs. I have not had time to test
it yet. Maybe today.
> > The two different FIFO:s will actually fulfil two different purposes. The
> > old
> > FIFO will be better when short transmissions are used, which should be
> > the "normal" SvxLink case and what it was originally designed for. The
> > new FIFO
> > will be better when long transmissions are used, like in a totally
> > different
> > application that is meant to transport audio to/from a remotely
> > controlled station.
> I do not agree here, the application is generally the same and I can't use
> the old FIFO design e.g. when connecting from DB0TUD-R to DB0FBG-R,
> because the sample rates seem to be highly different and there is network
> packet loss due to WLAN problems at DB0FBG-R. I can tolerate the 70ms
> additional delay when the connection is more stable.
Yes, this is a drawback with the current FIFO design. It will not work well in
rare cases where sample rate differs much. I'm actually surprised that the
implementation used today work as well as it does. The fact is that, over the
years, there have been no complaints about this problem and I have never had
the problem myself so it cannot be that common.
But of course, if the new FIFO will work well in all cases, I'm all for using
> > Hopefully, when the new audio pipe flow control is in place only one FIFO
> > implementation will be necessary that handle both cases well. Until then,
> > we'll just have to look at the situation and use the one that work best
> > in that specific case.
> I think the audio pipe can do this only to a limited extend, because it can
> not look what's happening behind a FIFO. A FIFO is normally used to
> decouple stream operation, so the only way is to (re)move some of the FIFO
> buffers. As stated above, I'd suggest to move the TX buffer first.
With the new audio pipe flow control you will know that no samples are buffered
in filters, interpolators or other block processing components. Samples will
only be requested by a sink from a source when they are needed. But of course,
if you put a FIFO somewhere, it will buffer samples as expected.
The purpose of the TX FIFO is not primarily as a rate regulating component.
It's purpose is twofold. The first is to build up an initial buffer of a couple
of blocks before releasing the audio to the audio device (pre-buffering). The
second purpose is when using multiple AudioIO streams that should be mixed
together. The AudioDevice class must have a buffer to pick audio blocks from.
With the new audio pipe flow control, samples can be requested on demand from
any source so the FIFO will, in theory, be unnecessary in the audio mixing
The pre-buffering remains to be solved though. The best solution would be if
the audio driver handle this itself. I believe the current Alsa code do this
by setting the snd_pcm_sw_params_set_start_threshold. I don't see there is
something like that in the OSS driver so maybe that have to be solved in the
> > > > That being said, I don't think this problem is especially noticeable
> > > > in the EchoLink case but could be in other situations.
> > >
> > > Yes, it is more noticeable when local repeater and EchoLink operate
> > > simultaneously.
> > Precisely and normally you don't start to speak in the middle of an
> > EchoLink
> > transmission even though it is possible, which would then cause you to
> > hear
> > your own transmission.
> No, this does not happen. A main reason for sending you the FIFO patches is
> to find out why it causes audio drop-outs on your computer, not the delay,
> which is not remarkably longer. I've tested the new FIFO on three
> computers with different sound cards, but I can't reproduce the drop-out
I'll probably get some time to test it today.
> Enclosed you'll find a patch which adds SPEEX support to the EchoLib
> library. Audio quality is significantly higher when using SPEEX,
> interoperability with existing systems both under Linux and Windows has
> been successfully tested. Codec parameters are set to narrow band at 25
> kBit/s, high quality, high compression effort.
> Final approval of the EchoLink developers is still pending.
This is a big step forward and a really important addition! It's been in my
plans since the beginning of the project so thank you for implementing it!
I have not looked at the code yet but it sounds like you have found an elegant
way of integrating the new codec into the existing protocol. I hope that the
EchoLink team is willing to accept the new standard.
This one I'm eager to try ;-)
I'll probably initially make this a new branch in Subversion but if it seems
to work well I think we can merge it into trunk pretty soon.
73's de SM0SVX / Tobias
> vy 73s de Steve, DH1DM