Re: users of drivers/misc/echo ?

[Harald Welte <laforge@gnumonks.org>]

Hi Dave, Arnd, Greg,

On Tue, Feb 25, 2025 at 01:01:06PM +0000, Dr. David Alan Gilbert wrote:
> > However, those DAHDI-using deployments that I personally am familiar
> > with do not use the software echo canceller discussed here.  On the
> > other hand, I'm quite certain that there are many PBX/IVR related
> > systems out there (unrelated to my area of cellular or trunked radio)
> > that would still use the echo canceller discussed here.

I have to correct myself here:  "that would still use software echo cancellation".

As I stated before, in "my" deployments, the echo canceller is not used
and hence I'm not super familiar with it.  My use cases either don't
need echo cancellation, or use hardware echo cancellation.

Revisiting the DAHDI source code as a result of this thread: There are
actually several different software echo cancellation implementations,
only one of which (oslec) is using the drivers/misc/echo.

> Some questions:
> 
> 1) I see drivers/dahdi/dahdi_echocan_oslec.c
> 
> /* Fix this if OSLEC is elsewhere */
> #include "../staging/echo/oslec.h"
> //#include <linux/oslec.h>
> 
> now that moved to drivers/misc in 2014 by Greg's
> 6e2055a9e56e ("staging: echo: move to drivers/misc/")
> 
> So is most of this on ancient kernels or do people
> actually use modern stuff?

Actually, looking at DAHDI, I really don't think anyone is still using
the dahdi_echocan_oslec code.  It is disabled by default and only built
if explicitly enabled by the user, and indeed if anyone did that it
would fail to build for any kernels that have moved it out of staging.

> 2) I see there is a fir.h that's different from the kernels
> drivers/misc/echo/fir.h  doesn't that cause problems?
> Should one get updated from the other somehow?

I'll not investigate that given the above determination.

> 3) Any idea why it's never been upstreamed?

I can only speculate, but I guess it was never a strong priority for the authors,
and indeed likely the code would have had to undergo quite some changes.

DAHDI is clearly well beyond its peak user base these days, and I would
expect the amount of effort into mainlining it, together with the
associated risk of introducing bugs during required refactoring simply
doesn't make it an attractive proposition.  Also, given that userspace
applications for it have been around for decades, it would be impossible
to address any upstreaming related change requests without rendering
those applications incompatible.

So I'd really not bother at this point anymore.  The few adjustments
I/we had to make to keep it building + working with recent kernels over
the past few years are minimal, and mostly trivial stuff like minor
kernel API changes.  In the end, DAHDI doesn't interact with a lot of
other kernel.  It talks to the hardware via its own device drivers, and
it talks to userspace programs via character devices.  So unless some
core kernel memory allocator, or PCI or USB device drive APIs or
character device API changes, we're mostly good.

-- 
- Harald Welte <laforge@gnumonks.org>          https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)