Closed JimZAH closed 4 months ago
Did you recompile dahdi with dahdi_dummy?
The instructions at https://wiki.allstarlink.org/wiki/Dahdi_dummy are not exactly right for the current release because of the version number changes.
Ah,
I used the phreaknet script install listed here: https://allstarlink.github.io/developers/source-install/
It appears I don't have the Dahdi Dummy module.
root@debian:/home/jim# lsmod |grep dahdi
dahdi_transcode 16384 0
dahdi 258048 1 dahdi_transcode
Assuming I still need the Dahdi dummy module?
I recommend that it be installed. Some systems need the benefit of the timing module in dahdi.
Thanks Danny.
I'll give that a go.
On 23 July 2024 21:02:25 BST, Danny Lloyd @.***> wrote:
I recommend that it be installed. Some systems need the benefit of the timing module in dahdi.
-- Reply to this email directly or view it on GitHub: https://github.com/AllStarLink/app_rpt/issues/369#issuecomment-2246201681 You are receiving this because you authored the thread.
Message ID: @.***>
I'm confused.
It appears the dahdi_dummy module is part of the phreaknet install, unless I'm missing something. Here's the info output of the dahdi module:
root@debian:/usr/src/app_rpt# modinfo dahdi
filename: /lib/modules/6.1.0-23-amd64/dahdi/dahdi.ko
alias: dahdi_dummy
license: GPL v2
description: DAHDI Telephony Interface
author: Mark Spencer <markster@digium.com>
version: 3.4.0
srcversion: C775BF74A6596D0E788C181
depends:
retpoline: Y
name: dahdi
vermagic: 6.1.0-23-amd64 SMP preempt mod_unload modversions
parm: initdir:deprecated, should use <tools_rootdir>/usr/share/dahdi (charp)
parm: tools_rootdir:root directory of all tools paths (default /) (charp)
parm: debug:Sets debugging verbosity as a bitfield, to see general debugging set this to 1. To see RBS debugging set this to 32 (int)
parm: deftaps:int
parm: max_pseudo_channels:Maximum number of pseudo channels. (int)
parm: hwec_overrides_swec:When true, a hardware echo canceller is used instead of configured SWEC. (int)
parm: auto_assign_spans:If 1 spans will automatically have their children span and channel numbers assigned by the driver. If 0, user space will need to assign them via /sys/bus/dahdi_devices. (int)
Note the alias is dahdi_dummy.
In the cli type dahdi show status
Do you see dahdi dummy listed.
I'm afraid it appears the command dahdi doesn't exist. I do however have the following options:
root@debian:/home/jim# dahdi_
dahdi_cfg dahdi_span_assignments
dahdi_genconf dahdi_span_types
dahdi_hardware dahdi_speed
dahdi_maint dahdi_test
dahdi_monitor dahdi_tool
dahdi_registration dahdi_waitfor_span_assignments
dahdi_scan
Even if you want to compile directly, I would strongly suggest using the ASL3 Repo and install the dahdi-source
and dahdi-dkms
packages. That will ensure that Dadhi is running on a known-tested version and will survive Kernel updates.
Also, what is the underlying hardware? I assume Debian 12 x86_64?
The command would need to be run at the asterisk prompt.
@KB4MDD Sorry, I assumed the wrong CLI.... It appears to list nothing much at all:
debian*CLI> dahdi show status
Span Description Alarms IRQ bpviol CRC Fra Codi Options LBO
@jxmx Thank you, I'll give that a go.
The hardware is X86_64 5 year old i5 laptop.
Thanks both, I've managed to get this working. For anyone else who has issues installing from source please try the below.
dahdi-source
and dahdi-dkms
.phreaknet install -d -v 20 -f
note '-f'.This should get you up and running with dahdi_dummy.
CLI output:
debian*CLI> dahdi show status
Span Description Alarms IRQ bpviol CRC Fra Codi Options LBO
1 DAHDI_DUMMY/1 (source: HRtimer) 1 UNCONFI 0 0 0 CAS Unkn 0 db (CSU)/0-133 feet (DSX-1)
lsmod output:
root@debian:/usr/src# lsmod | grep dah
dahdi_dummy 16384 0
dahdi_transcode 16384 0
dahdi 258048 18 dahdi_dummy,dahdi_transcode
I'm running Allstar manually built from master branch.
This is running on a base station repeater running at home. There is a noticeable audio artifact which sounds like users are underwater. This appears to be from the receiver side of the system, users over the network sound fine.
I've tried everthing I can think of, jitter buffer, rebuilding without debug flags. Nothing seems to improve it.
It's a very similar issue the Raspberry PI's had which I believe was a timing issue?