Topics

bridging ASL, DMR and DSTAR

Patrick Perdue
 

Hello everyone:

I currently have a bridge between a Brandmeister DMR talk group and DSTAR via an XLX reflector, using a remotely connected machine running ambed with two ThumbDV dongles.

I am thinking of setting up an ASL bridge. However, it occurs to me as an audio guy that just connecting ASL directly to DMR with the current bridge as it is wouldn't be the best sounding option, as calls to and from DSTAR would be transcoded through DMR before it gets to ASL. I would think that using ASL as a hub would mitigate this problem, but perhaps cause new ones, such as no data for call signs between DMR and DSTAR.

What would be the best approach for handling this? Also, do I need more ambe vocoder channels, or is two plus instances of Analog_bridge sufficient for these three modes??


Thanks and 73

KE4DYI

Steve KC1AWV
 

>  However, it occurs to me as an audio guy that just connecting ASL directly to DMR with the current bridge as it is wouldn't be the best sounding option, as calls to and from DSTAR would be transcoded through DMR before it gets to ASL.

Well, you're going to have to get the analog audio vocoded to DMR or D-Star anyway. Going from ASL to DMR is easier as there exists vocoding software to do so. ASL to D-Star (if you're worried about audio quality) will require another hardware vocoder, so you're going to need another AMBE stick.

To keep things simple, I would choose this path: ASL <-> AB <-> MB <-> BM <-> XLX. You're already using the existing XLX server to do the transcoding into a common format; in this case it's DMR being sent off to Brandmeister. Then, it's an easy hop from DMR to Analog. I have not experienced any significant audio quality issues going from D-Star to DMR to Analog.

>  I would think that using ASL as a hub would mitigate this problem, but perhaps cause new ones, such as no data for call signs between DMR and DSTAR.

If you want to use ASL as a hub, then you will probably want to drop the BM to XLX link and let ASL do the heavy lifting. You'd be looking at this: XLX <-> MB <-> AB <-> ASL <-> AB <-> MB <-> BM. As you can see, it's a bit more involved as far as setup goes, but it can be done. Also, AB handles the metadata for callsigns, so no worries there - though all calls passing through ASL from one side to the other will always look like they're coming from whatever callsign is being used in Analog_Bridge. This is because as far as I know, app_rpt does not know about the metadata being passed through it. Not sure if I'm correct on that point, so don't take my word for it.

Steve KC1AWV

Patrick Perdue
 

Hi Steve:


OK, thanks for that. I'll probably just go with the first option for ease-of-setup. Maybe I'll try it with a soft vocoder before committing to more hardware, since the XLX reflector is already translating to DSTAR.

But, this leads me to another question.

Would it be possible to insert ladspa DSP effects between analog_bridge and DMR using SoX or some other method? I'm thinking of using, say, a downward expander to minimize some background from analog to digital, so the encoder doesn't have to work so hard when there is some noise on the analog signal. Of course, this won't do any good for extreme cases, but for excellent to moderate signals. Maybe a limiter on the input to ASL from DMR might be nice, too.

Steve KC1AWV
 

I don't see why not. Though you may want to play with the analog audio while it's in ASL before it goes to AB. Generally speaking, if it can be done in asterisk, it can also be done in ASL.


On Wed, Oct 2, 2019, 4:58 AM Patrick Perdue <patrick@...> wrote:
Hi Steve:


OK, thanks for that. I'll probably just go with the first option for
ease-of-setup. Maybe I'll try it with a soft vocoder before committing
to more hardware, since the XLX reflector is already translating to DSTAR.

But, this leads me to another question.

Would it be possible to insert ladspa DSP effects between analog_bridge
and DMR using SoX or some other method? I'm thinking of using, say, a
downward expander to minimize some background from analog to digital, so
the encoder doesn't have to work so hard when there is some noise on the
analog signal. Of course, this won't do any good for extreme cases, but
for excellent to moderate signals. Maybe a limiter on the input to ASL
from DMR might be nice, too.




Patrick Perdue
 

It's been a long time since I've done anything with Asterisk (I used to manage some phone systems years ago,) but I don't recall being able to easily process audio without making changes to source. ASL already has some DSP-based stuff built-in, so maybe I can look at what it's doing and go from there. I'd rather do as much processing within Asterisk, but I am more familiar with passing audio in real time through SoX and LADSPA processors, which I assume I could pipe AB to and from if necessary. Time to experiment, I guess.

Steve KC1AWV
 

I like these kinds of projects, ones that make me think! If I take a step back and take a higher level look, these are my thoughts.

If we don't want to fiddle with the Asterisk code, then we have two options on where to play with the audio. Either before it gets into ASL, or on its way out into AB. If I had to guess, then the audio on its way out of ASL and into AB might be the better option. When sending audio to AB, you're practically just taking audio from an Asterisk conference bridge through an extension and using chan_usrp to pipe it into AB. If there's a way to take the audio being piped from ASL through chan_usrp, play with it a bit, then pipe it into AB... that could be an option. Though I've never tried it, so your mileage may vary. If there's someone that has more experience with tinkering the audio path between ASL and AB, they might have a better answer.

On Wed, Oct 2, 2019 at 6:36 AM Patrick Perdue <patrick@...> wrote:
It's been a long time since I've done anything with Asterisk (I used to
manage some phone systems years ago,) but I don't recall being able to
easily process audio without making changes to source. ASL already has
some DSP-based stuff built-in, so maybe I can look at what it's doing
and go from there. I'd rather do as much processing within Asterisk, but
I am more familiar with passing audio in real time through SoX and
LADSPA processors, which I assume I could pipe AB to and from if
necessary. Time to experiment, I guess.





--
Steve Miller
KC1AWV

Ken KE2N
 

going the other way (DMR/C4FM-> Analog) could use help too.  It seems the vocoders are quite capable of making a lot of sound energy in the 3-4 kHz range.  It's what gives those digital modes a characteristic "sharp" sound.  Unfortunately, on the ASL side, things are affected by the 8 ks/sec rate.  Although it is theoretically possible to reproduce 3.99 kHz sound with this sampling rate, audio gets more and more distorted as you go above 3 kHz.  It would be a big improvement if the digital stream were filtered through a steep low pass filter - with a shoulder just above 3 kHz - before being passed to the analog side of things,

Ken
KE2N

Steve KC1AWV
 

I see what you're getting at, Ken. I wonder if anyone has tried G722 on ASL? I think I have a desk phone that supports it, maybe I can try it out and see what happens.


On Wed, Oct 2, 2019 at 11:09 AM Ken KE2N via Groups.Io <ke2n=cs.com@groups.io> wrote:
going the other way (DMR/C4FM-> Analog) could use help too.  It seems the vocoders are quite capable of making a lot of sound energy in the 3-4 kHz range.  It's what gives those digital modes a characteristic "sharp" sound.  Unfortunately, on the ASL side, things are affected by the 8 ks/sec rate.  Although it is theoretically possible to reproduce 3.99 kHz sound with this sampling rate, audio gets more and more distorted as you go above 3 kHz.  It would be a big improvement if the digital stream were filtered through a steep low pass filter - with a shoulder just above 3 kHz - before being passed to the analog side of things,

Ken
KE2N



--
Steve Miller
KC1AWV

Ken KE2N
 

If you could run G722 at 16 kHz sampling within ASL that would be great.  But I imagine the 8 ks/sec rate is pretty hard-coded into asterisk and not easily changed.  Basically the issue is that the digital modes use vocoders and the analog side uses codecs.  The 8 kHz codecs were never intended to reproduce anything above 3.4 KHz.  If you pipe your digital radio to spectrum lab, or similar, you may be  surprised how much “stuff” there is up around 3.5 kHz on some signals …  it is better to chop that stuff off rather than generate a whole bunch of IMD with it.

 

 

Ken

 

 

 

From: main@DVSwitch.groups.io [mailto:main@DVSwitch.groups.io] On Behalf Of Steve KC1AWV
Sent: Wednesday, October 02, 2019 11:40 AM
To: main@dvswitch.groups.io
Subject: Re: [DVSwitch] bridging ASL, DMR and DSTAR

 

I see what you're getting at, Ken. I wonder if anyone has tried G722 on ASL? I think I have a desk phone that supports it, maybe I can try it out and see what happens.

 

 

On Wed, Oct 2, 2019 at 11:09 AM Ken KE2N via Groups.Io <ke2n=cs.com@groups.io> wrote:

going the other way (DMR/C4FM-> Analog) could use help too.  It seems the vocoders are quite capable of making a lot of sound energy in the 3-4 kHz range.  It's what gives those digital modes a characteristic "sharp" sound.  Unfortunately, on the ASL side, things are affected by the 8 ks/sec rate.  Although it is theoretically possible to reproduce 3.99 kHz sound with this sampling rate, audio gets more and more distorted as you go above 3 kHz.  It would be a big improvement if the digital stream were filtered through a steep low pass filter - with a shoulder just above 3 kHz - before being passed to the analog side of things,

Ken
KE2N



--

Steve Miller

KC1AWV

Patrick Perdue
 

Yes, I've also thought of high pass/low pass filtering into and out of ASL. Ideally, I'd use a chain that looks something like this:

DMR > hpf/lpf > limiter > AB > ASL

Throw an expander after the hpf/lpf when going the other way, and maybe not use a limiter.

Some of these digital radios are just unnecessarily hot (Radioddity GD77S, for example,) and I'd like to tame that on the way in to ASL without just attenuating the entire signal, since levels will be everywhere.