Friday, June 14, 2013 steve-k@... wrote:
> Hi Tobias,
> as I remember correctly we already had a discussion about the audio
> framework a while ago. The main idea behind the new framework is that
> sources and sinks are either free running or use a handshake protocol. Any
> connection is possible, provided that you use specific glue components.
Can you give some examples of where a free running component should be used
and when a handshake component should be used?
Don't you risk loosing samples without handshake?
How do you handle "unclocked" sources like reading from a file without
Without handshake, how can you synchronize the audio stream with other events?
One example would be when detecting a squelch close in the RX you may want to
turn the transmitter off. If the transmitter is turned off before all samples
have been flushed, the end of the transmission will be cut. Now this is a
constructed example since SvxLink does not work like this today but it used
to. It's just an illustrative example of what I mean by synchronizing the
audio stream with other asynchronous events.
> A connection between a free running source and sink or a handshake source
> and sink does not require any glue component. Buffering is only used for
> data processing efficiency, the pipe itself does not utilize buffering.
> Handshake is implemented in both direction (availSamples/requestSamples).
Having handshake in both directions sounds interesting. One of the changes I
have thought of doing in the audio pipe framework is to turn the flow control
around, making the sinks ask for samples instead of the sources to push
samples down the pipe. I think this would eliminate a lot of buffering which is
necessary today. I guess the effect is the same in your framework. I'm
interested in how you use the both handshake methods. When do you use one or
the other? Is both needed? Why?
73's de SM0SVX / Tobias
> Both signal latency and CPU load can be decreased using the new framwork
> and the code of many audio components looks a lot cleaner.
> The framework is not yet in a finished state, but it already runs stable
> for years on three German repeaters: DM0LEI-R, DB0FBG-R and DB0TUD-R.
> I agree, that this is an afternoon research project that is part of the
> game of open source software development. I would have already given up
> reading all the emails on the list.
> If you feel the code could be useful again for svxlink please let me know.
> I've already spent a lot of time on debbuging all the stuff.
> 73s Steve DH1DM
> ----- Original Nachricht ----
> Von: Tobias Blomberg <sm0svx@...>
> An: Discussions about development issues
> <svxlink-devel@...> Datum: 12.05.2013 14:05
> Betreff: Re: [Svxlink-devel] new_audio_pipe branch
> > On 05/11/2013 08:51 PM, steve-k@... wrote:
> > > Hi Tobias,
> > >
> > > hereby I'd like to announce that I'll no longer maintain the
> > new_audio_pipe branch.
> > > The perspective of what happens with the code in this branch is yet
> > > very
> > unclear,
> > > it will certainly not be integrated into trunk in the near future.
> > > As the new new audio framework required small adaptions to almost any
> > component
> > > of the svxlink system, it is a very time consuming task to keep this
> > branch in sync
> > > with trunk (manual diff evaluation exceeds 20k lines now).
> > OK, Steve. That is unfortunate but I fully understand your reason. I'm
> > sorry that I have not found the time to go through your rewrite of the
> > audio pipe system but I believe it to be too much work involved in going
> > through the code in comparison to what I gain. I don't believe the
> > delays introduced by the current audio pipe design is that annoying.
> > I agree though that the audio pipe need to be redesigned some day, for
> > more than one reason, but it's not top priority for me right now. To
> > keep my enthusiasm up I need to work with what I think is fun. If I feel
> > I'm forced to do something I don't think is fun or something that I
> > think have low priority, I'd rather do nothing. I think that would be
> > worse.
> > It would be nice if you could tell me your thoughts behind doing the
> > rewrite.
> > What is the specification for writing an audio pipe component in the
> > new_audio_pipe branch? How should a component behave in its
> > communication with other audio pipe components? How is the flow
> > controlled? What functions are involved in the flow control?
> > Why is the new audio pipe better than the current implementation?
> > What additional features have you implemented in the new_audio_pipe
> > branch? Does all new features require the functionality of the
> > new_audio_pipe branch?
> > 73's de SM0SVX / Tobias
> > > I'll continue the support of this branch at the German repeaters DB0FBG
> > and DM0LEI.
> > > vy 73s de Steve, DH1DM