> Steve Underwood wrote:
> > Jamie Lokier wrote:
> > > I plan to do something much like that. An auxiliary streaming channel
> > > is required for things like dial/busy tone detection, because I've found
> > > (non-RT) user space scheduling isn't fine grained enough for simple "is
> > > there a tone now?" questions to distinguish different patterns. At
> > > least, according to certain country-specific parameters.
> >
> > This doesn't make sense. You just need to count your way through the received
> > samples as you run them through the tone detector That gives you the cadence
> > precisely. Its both more accurate and more efficient than any other strategy.
> > There are no scheduling issues on the receive side at all. You just need to
> > keep up, and not drop samples.
>
> I was referring to when the on-board DSP does the tone detection.
> The driver needs to record what the DSP says and when it says it.
> That record is the auxiliary channel. Probably only needs to be one
> entry long :-) (I.e., record one "event" and "time of event").
>
> You are right when the tone detection is done in software. Then you
> just count samples.
It still doesn't make much sense. Like most good real time problems, the way to
solve it is to turn it into a non-real time problem. If the DSP doesn't time stamp
the events it outputs, get the interrupt routine to do so. I doubt there are FIFOs
on these cards, so the interrupt routine's time stamp must be rather better than
is needed. The user space code can then deal with the event stream in a more
leisurely way.
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/