Analog_Bridge and audio processing


Patrick Perdue
 

Steve:

I understand the concept of the shin. That's a bit beyond my skill set at the moment, but something like that which could host LADSPA plugins would be really cool.

Thanks for the tips on dynamically changing parameters with DVSwitch.


On 11/1/2019 10:34 AM, Steve N4IRS wrote:
Patrick,
The band pass filter is not configurable. I believe it's 300 to 3000 Hz. If you want to insert audio processing between Analog_Bridge and Asterisk, (The USRP channel driver) you might want to create a "shim" the shim would extract the PCM audio from the USRP data stream, make your adjustments and then rebuild the USRP data before sending on to ASL or Analog_Bridge in the other direction. This is a broad stroke of a idea and could be fleshed out.

I have seen your post on the HAMVIOP list and as Steve said, you can "steer" Analog_Bridge and MMDVM_Bridge via a external interface. The example he pointed you to is simple and we are putting the finishing touches on a script that would give users a simple commandline interface to changing parameters on the fly. Below is a partial list of comands.

Usage:
./dvswitch.sh   {mode | tune | ambesize | ambemode | update | tlvAudio | usrpAudio | tlvPorts | info | mute | message |
        pushfile | collectProcessDataFiles | collectProcessPushDataFiles | pushurl | collectProcessPushDataFilesHTTP}
         tune tg                                         tune to specific TG/Reflector
         ambesize
         ambemode {DMR|NXDN|P25|YSFN|YSFW|DSTAR}         Set AMBE mode
         mode {DMR|NXDN|P25|YSF|DSTAR}                   Set Analog_Bridge mode
         update                                          Update callsign databases
         tlvAudio gain                                   Set AMBE audio gain
         usrpAudio gain                                  Set PCM audio gain
         tlvPorts rxport txport                          Set Analog_Bridge receive and transmit ports
         mute {OFF|USRP|TLV|BOTH}                        Cause Aanlog_Bridge to mute a stream
         info                                            Update ABInfo and send to DVSM/UC
         message msg                                     Send a text message to DVSM/UC
         pushfile file                                   Push file to DVSM
         pushurl url                                     Push URL to DVSM
         collectProcessDataFiles                         Collect and prepare DVSM data files
         collectProcessPushDataFiles                     Collect, prepare and upload DVSM data files
         collectProcessPushDataFilesHTTP                 Collect, prepare and upload DVSM data files over http

We are adding more commands as we "expose" the TLV commands available. 

73, Steve N4IRS

On 10/29/2019 12:56 PM, Patrick Perdue wrote:
Hi all:

Yesterday, I configured a bridge between ASL and DMR using md380-emu. Everything is working great, but I'm wondering if I can improve audio quality on the ASL to DMR side other than just changing levels. I don't really like the sound of decoded audio from DMR on ASL, but I expect most of this is due to md380-emu. I have ordered more ThumbDV dongles, so that will probably help some in and of itself. Some is probably due to the entire stack working at 8 kHz. I haven't done any testing, but anecdotally, it seems that, on a real DMR radio, the vocoder is perhaps running at a higher sampling rate, though the audio itself is 8 kHz.

I noticed an Analog_Bridge option called USE_AUDIO_BPF, but couldn't find any info on it. I assume this is a band pass filter. Is it configurable, or fixed frequencies? If there are arguments, what does the syntax for this look like?

I'd ultimately like to use LADSPA effects to do things like downward expansion from ASL to DMR to clean up some low level noise before it hits the vocoder, maybe put a slight EQ or multi-band dynamics processing to fill out some of the low-end from analog radios. My thought, though I'm not sure how this would actually be done, is to pipe Analog_Bridge to SoX for real time processing, then back to another Analog_Bridge instance for the node. I'm just not sure of a good way to pipe raw PCM audio from A_B to stdin, so that SoX can process the audio, then pipe raw PCM audio post-processing to, I assume, a second A_B configured to send to the node

, or if this is even possible without a bunch of latency and a huge mess. Has anyone tried anything like this before?





Steve N4IRS
 

Patrick,
The band pass filter is not configurable. I believe it's 300 to 3000 Hz. If you want to insert audio processing between Analog_Bridge and Asterisk, (The USRP channel driver) you might want to create a "shim" the shim would extract the PCM audio from the USRP data stream, make your adjustments and then rebuild the USRP data before sending on to ASL or Analog_Bridge in the other direction. This is a broad stroke of a idea and could be fleshed out.

I have seen your post on the HAMVIOP list and as Steve said, you can "steer" Analog_Bridge and MMDVM_Bridge via a external interface. The example he pointed you to is simple and we are putting the finishing touches on a script that would give users a simple commandline interface to changing parameters on the fly. Below is a partial list of comands.

Usage:
./dvswitch.sh   {mode | tune | ambesize | ambemode | update | tlvAudio | usrpAudio | tlvPorts | info | mute | message |
        pushfile | collectProcessDataFiles | collectProcessPushDataFiles | pushurl | collectProcessPushDataFilesHTTP}
         tune tg                                         tune to specific TG/Reflector
         ambesize
         ambemode {DMR|NXDN|P25|YSFN|YSFW|DSTAR}         Set AMBE mode
         mode {DMR|NXDN|P25|YSF|DSTAR}                   Set Analog_Bridge mode
         update                                          Update callsign databases
         tlvAudio gain                                   Set AMBE audio gain
         usrpAudio gain                                  Set PCM audio gain
         tlvPorts rxport txport                          Set Analog_Bridge receive and transmit ports
         mute {OFF|USRP|TLV|BOTH}                        Cause Aanlog_Bridge to mute a stream
         info                                            Update ABInfo and send to DVSM/UC
         message msg                                     Send a text message to DVSM/UC
         pushfile file                                   Push file to DVSM
         pushurl url                                     Push URL to DVSM
         collectProcessDataFiles                         Collect and prepare DVSM data files
         collectProcessPushDataFiles                     Collect, prepare and upload DVSM data files
         collectProcessPushDataFilesHTTP                 Collect, prepare and upload DVSM data files over http

We are adding more commands as we "expose" the TLV commands available. 

73, Steve N4IRS

On 10/29/2019 12:56 PM, Patrick Perdue wrote:
Hi all:

Yesterday, I configured a bridge between ASL and DMR using md380-emu. Everything is working great, but I'm wondering if I can improve audio quality on the ASL to DMR side other than just changing levels. I don't really like the sound of decoded audio from DMR on ASL, but I expect most of this is due to md380-emu. I have ordered more ThumbDV dongles, so that will probably help some in and of itself. Some is probably due to the entire stack working at 8 kHz. I haven't done any testing, but anecdotally, it seems that, on a real DMR radio, the vocoder is perhaps running at a higher sampling rate, though the audio itself is 8 kHz.

I noticed an Analog_Bridge option called USE_AUDIO_BPF, but couldn't find any info on it. I assume this is a band pass filter. Is it configurable, or fixed frequencies? If there are arguments, what does the syntax for this look like?

I'd ultimately like to use LADSPA effects to do things like downward expansion from ASL to DMR to clean up some low level noise before it hits the vocoder, maybe put a slight EQ or multi-band dynamics processing to fill out some of the low-end from analog radios. My thought, though I'm not sure how this would actually be done, is to pipe Analog_Bridge to SoX for real time processing, then back to another Analog_Bridge instance for the node. I'm just not sure of a good way to pipe raw PCM audio from A_B to stdin, so that SoX can process the audio, then pipe raw PCM audio post-processing to, I assume, a second A_B configured to send to the node

, or if this is even possible without a bunch of latency and a huge mess. Has anyone tried anything like this before?





Patrick Perdue
 

Hi all:

Yesterday, I configured a bridge between ASL and DMR using md380-emu. Everything is working great, but I'm wondering if I can improve audio quality on the ASL to DMR side other than just changing levels. I don't really like the sound of decoded audio from DMR on ASL, but I expect most of this is due to md380-emu. I have ordered more ThumbDV dongles, so that will probably help some in and of itself. Some is probably due to the entire stack working at 8 kHz. I haven't done any testing, but anecdotally, it seems that, on a real DMR radio, the vocoder is perhaps running at a higher sampling rate, though the audio itself is 8 kHz.

I noticed an Analog_Bridge option called USE_AUDIO_BPF, but couldn't find any info on it. I assume this is a band pass filter. Is it configurable, or fixed frequencies? If there are arguments, what does the syntax for this look like?

I'd ultimately like to use LADSPA effects to do things like downward expansion from ASL to DMR to clean up some low level noise before it hits the vocoder, maybe put a slight EQ or multi-band dynamics processing to fill out some of the low-end from analog radios. My thought, though I'm not sure how this would actually be done, is to pipe Analog_Bridge to SoX for real time processing, then back to another Analog_Bridge instance for the node. I'm just not sure of a good way to pipe raw PCM audio from A_B to stdin, so that SoX can process the audio, then pipe raw PCM audio post-processing to, I assume, a second A_B configured to send to the node

, or if this is even possible without a bunch of latency and a huge mess. Has anyone tried anything like this before?