From: "Dr. David Alan Gilbert" <linux@treblig.org>
To: Harald Welte <laforge@gnumonks.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, david@rowetel.com
Subject: Re: users of drivers/misc/echo ?
Date: Tue, 25 Feb 2025 13:01:06 +0000 [thread overview]
Message-ID: <Z72_EnXyHoDACRk5@gallifrey> (raw)
In-Reply-To: <Z724l3DFJbGevtPF@nataraja>
* Harald Welte (laforge@gnumonks.org) wrote:
> Hi Arnd,
>
> > Adding Harald to Cc, might know more about it.
>
> thanks for Cc'ing me on this thread.
Hi Harald,
Thanks for the reply.
> On Sun, Feb 23, 2025 at 09:38:12PM +0100, Arnd Bergmann wrote:
> > I don't see any in-tree users for it either, but I found one
> > project using the exported symbols, and there is a debian
> > package for it as well:
> >
> > https://tracker.debian.org/pkg/osmocom-dahdi-linux
> > https://gitea.osmocom.org/retronetworking/dahdi-linux/src/branch/master/drivers/dahdi/dahdi_echocan_oslec.c#L34
>
> Note: The official upstream of DAHDI is maintained as part of the Asterisk soft switch project,
> the Osmocom fork has just become more popular in recent years due to very slow maintenance of
> upstream.
>
> Any of the DAHDI forks is used in production deployments by a number of
> different telephony / softswitch / telecom software projects (like
> Asterisk, FreeSWITCH, yate or many osmocom sub-projects) in order to
> interface with classic anaolog or TDM (time division multiplex)
> telephony technology.
>
> Even today this TDM technology (most likely in most instances without
> open source softswitches) is still relevant in commercial production
> deployments, including many (but not all) cellular carriers
> around the world, but for example also as part of GSM-R (railway
> communications systems) for at least until 2035. I personally also know
> of present-day production deployments in satellite telephony
> infrastructure.
>
> 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.
>
> In any case, for this discussion, it doesn't matter, as all DAHDI
> flavours make use of the same API function.
>
> > With our normal rules, we should just remove it as there is no
> > way to use the code without external modules, but I don't know
> > how we even got to this state.
>
> I'd expect the echo cancellation code was used by mISDN for as long as
> that was still in upstream. As mISDN has (sadly, but understandably)
> been removed, the echo canceller likely remained in the tree without any
> other in-tree users.
OK.
> DAHDI has been using the in-kernel echo canceller for decades. If it's
> removed now, it will likely mean that DAHDI will carry a copy of it and
> selectively compile that as out-of-tree module for future kernel
> versions.
Well, it's a bit odd - but if it's actively used it's not terrible.
(I guess there are kernel drivers that are fully usable that are never used!)
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?
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?
3) Any idea why it's never been upstreamed?
I guess the problem is that dahdi-base.c is quite a chunk and
that would have to go in to take any of the useful other bits.
Oh hmm, and a whole bunch hasn't got signed-off's so it's
very hard.
Dave
> I personally wouldn't see that as a big problem, as DAHDI itself has
> always been out-of-tree anyway, and adding one more module to that is
> not a big deal. Note that I cannot speak officially for the DAHDI
> project as I'm just maintaining the Osmocom fork.
>
> Kind regards,
> Harald
> --
> - 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)
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
next prev parent reply other threads:[~2025-02-25 13:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-23 17:23 users of drivers/misc/echo ? Dr. David Alan Gilbert
2025-02-23 20:38 ` Arnd Bergmann
2025-02-25 12:33 ` Harald Welte
2025-02-25 13:01 ` Dr. David Alan Gilbert [this message]
2025-02-25 13:58 ` Harald Welte
2025-02-25 18:39 ` Dr. David Alan Gilbert
2025-02-25 19:02 ` Arnd Bergmann
2025-02-25 19:08 ` Harald Welte
2025-02-25 22:04 ` Dr. David Alan Gilbert
2025-02-26 7:12 ` Harald Welte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z72_EnXyHoDACRk5@gallifrey \
--to=linux@treblig.org \
--cc=arnd@arndb.de \
--cc=david@rowetel.com \
--cc=gregkh@linuxfoundation.org \
--cc=laforge@gnumonks.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.