开云体育

Hello Phil,

But... there is only one audio device and that's the "default" device.

ADEVICE plughw:1,0

Nono.. you misunderstand.? When I say "default" I literally mean it:

?? ADEVICE default

The word "default" is a PulseAudio/Pipewire special device that will send/receive audio to any application if the correct audio it "routed" to it using tools like "pavucontrol"

This is used when the FT-991A? is connected and Direwolf works.

ADEVICE plughw:0,0

In this line, the "plughw" is a specific rate adaptive ALSA control that is exclusively managing the hardware device "0,0"

And this is the only audio device ("default") when the radio is not connected and Direwolf is also happy again.

Does your computer really not have any sound devices on it when no radios, SDRs, etc. are connected?? I ask because I view that having some other device to send various computer UI beeps, boops, etc.notications to is important to have sent to the operator and NOT sent over say one of your radio's sound cards with the risk of being sent over the air.

The problem is that SDRconnect also uses the default device.

No.. the SDRconnect application will be creating it's own audio which is called a audio "source" and that audio stream is then routed via the pavucontrol application to the appropriate "sink" aka sound-device to play that audio stream.? The same methodology/terminology is used for sound recording aka "microphones" for routing any captured audio and routing it to the correct application for processing.? I recommend you do some review on PulseAudio and/or Pipewire terminology and see how it all works.? For example:

??

I have and used to use "soundmodem" before I became aware of Direwolf, Direwolf is a big improvement.

UZ7HO's Soundmodem has similar performance to Direwolf with weak signal decodes and yes, it's a big improvement.? In addition to routing audio around using pavucontrol, Gqrx supports direct audio routing for uses with say Direwolf:

??

--David
KI6ZHD

Hi Josh,

I'm surprised that you expect Direwolf to "see" any SDR. Direwolf looks for audio devices, not SDR receivers/transmitters.

In order to use Direwolf to process the audio from a SDR receiver you do first need an application (SDRconnect as an example) that configures the SDR (frequency, etc.) and demodulates the received signals into an audio stream.

You may want to share some details about your setup (including operating system) and what you are trying to achieve.

73,
Thomas
KK6FPP

On 15/1/25 11:23, David Ranch via groups.io wrote:

Right.. and with using a different Direwolf "ADEVICE" setting in the direwolf.conf file, this should work

But... there is only one audio device and that's the "default" device.

ADEVICE plughw:1,0

This is used when the FT-991A? is connected and Direwolf works.

ADEVICE plughw:0,0

And this is the only audio device ("default") when the radio is not connected and Direwolf is also happy again. The problem is that SDRconnect also uses the default device.

I suppose I could buy a USB sound card if I had a real need to use SDRconect to decode APRS signals. I don't have any need, I was just curious.

Yup.. very true though GQRX's AX.25 decoder can't touch the weak signal decoding capabilities of Direwolf.? If you do a comparison, you'll see.

I have and used to use "soundmodem" before I became aware of Direwolf, Direwolf is a big improvement.

--
Regards,
Phil

开云体育

Hello Phil,

My understanding is that the default audio device is the ALSA device. I'm probably wrong and I'll test that idea.

Right.. and with using a different Direwolf "ADEVICE" setting in the direwolf.conf file, this should work

I was receiving SSTV from the ISS using SDRconnect and QSSTV. When the ISS experimented ended I thought I'd try receiving APRS messages from the ISS but I quickly discovered that SDRConnect and Direwolf won't cooperate with each other because of the shared audio device. I overcame that problem by using GQRX which has an inbuilt ARRS viewer.

Yup.. very true though GQRX's AX.25 decoder can't touch the weak signal decoding capabilities of Direwolf.? If you do a comparison, you'll see.? The Gqrx developers openly mention this and even have talked about removing that function and just tell user to use Direwolf but the convenience is too high to drop it IMHO.

If I were to use my FT-991A then there isn't problem because the use of the radio introduces a new audio device which means that there isn't a shared audio device.

Ok.. got it.? Utimately, for a receive only situation like using SDRs, using Pulse/Pipeaudio should work just fine.? It's when using then for transmissions, then things get weird at times and that's when I recommend to only use ALSA devices.

--David
KI6ZHD

On 15/1/25 10:51, David Ranch via groups.io wrote:

This is not entirely true.? If you configure Direwolf to use an ALSA device, you're right.. Direwolf will want exclusive access to that sound card.? Now, if you configure Direwolf to use the sound device "default" (which is a reserved word meeting PulseAudio or now Pipewire on the newest OSes, you will be able to share the sound device.? To route the audio from the shared sound device, you will need to install and run the "pavucontrol" program.

Hello David,

My understanding is that the default audio device is the ALSA device. I'm probably wrong and I'll test that idea.

All that said, what are you doing that you would want to SHARE audio coming from your radio to both Direwolf and something else?

I was receiving SSTV from the ISS using SDRconnect and QSSTV. When the ISS experimented ended I thought I'd try receiving APRS messages from the ISS but I quickly discovered that SDRConnect and Direwolf won't cooperate with each other because of the shared audio device. I overcame that problem by using GQRX which has an inbuilt ARRS viewer.

If I were to use my FT-991A then there isn't problem because the use of the radio introduces a new audio device which means that there isn't a shared audio device.

--
Regards,
Phil

开云体育

Hello Phil,

Direwolf cannot share an audio device. If the Burr Brown device is not available then there's only one audio device, the default audio device. ADEVICE can be set to UDP: some_port_number rather than an audio device. I should investigate if SDRconnect makes it's audio available via UDP. I don't think it does.

This is not entirely true.? If you configure Direwolf to use an ALSA device, you're right.. Direwolf will want exclusive access to that sound card.? Now, if you configure Direwolf to use the sound device "default" (which is a reserved word meeting PulseAudio or now Pipewire on the newest OSes, you will be able to share the sound device.? To route the audio from the shared sound device, you will need to install and run the "pavucontrol" program.

All that said, what are you doing that you would want to SHARE audio coming from your radio to both Direwolf and something else?

--David
KI6ZHD

On 15/1/25 00:14, sceadued via groups.io wrote:

You could get a cheap soundcard dongle, configure direwolf to that and use a short 3.5mm TRS patch cable from the computer headphone out to the soundcard dongle Mic input.

It's a possibility I suppose Neil and thank you for your reply. I'll think about it.

--
Regards,
Phil

On 15/1/25 01:35, WB2OSZ via groups.io wrote:

If other applications can get audio from SDRconnect, direwolf should also be able to.

That's not the case John, but thank you for your reply. If I connect my Yaesu FT-991A to my laptop then a new audio device becomes available, Burr Brown or some thing like that. I cannot use the radio because I cannot deploy my aerial and it's too much trouble to unpack the radio to confirm the audio device name . Audio from that device is then available to Direwolf.

What audio device name is used by the other applications?

The default audio device. QSSTV, for instance, listens to the audio from the SDR via the default audio device.

Direwolf cannot share an audio device. If the Burr Brown device is not available then there's only one audio device, the default audio device. ADEVICE can be set to UDP: some_port_number rather than an audio device. I should investigate if SDRconnect makes it's audio available via UDP. I don't think it does.

--
Regards,
Phil

开云体育

Hi Cassie

For an FM RX channel one would expect a much higher audio level with zero received signal. ie try increase the slider to around 100% for a start. The way to adjust is on an actual signal receipt that should be logged with the audio level eg;

Digipeater RS0ISS audio level = 73(20/13)??? _|||||___
[0.3 23:24:37 UTC] VK3KAW-10>APRS,RS0ISS*,SGATE,WIDE2-1:=3621.56S/14707.30E`..

The "audio level = 73" should be between 50 and 100 or so.

I can see you already found that in your "UPDATE" email. Suggest you standardise with the pavucontrol Input Devices slider on 100% and adjust the Recording tab slider for (say) 75 on received packets. As a guide (same hardware) my slider is set to 80% for ISS.

The audio level that comes with the direwolf command line -a option, like;

ADEVICE0: Sample rate approx. 48.0 k, 0 errors, receive audio levels CH0 86, CH1 91

can be over 100 for an FM RX (ie mostly just unmuted noise) It depends on the relative deviation, bandwidth and RX design etc.

If the 9100's are adjacent/nearby/running then possibly use one as a TX source to test the other RX. The usual caution about dummy loads and/or no antenna with PTT disabled. This is also a good test bed for finding the right TXDELAY number. If you did a rig reset too the USB port audio output level (menu 56) may have changed (back) to default resulting in over or under deviation.

I think too that using a single 9100 with its monitor turned on (button 2 left/below VFO knob) will feed audio back into direwolf. ie any packet you TX will come back on RX. Handy for all kinds of tests and will also get the input level (above) in the ball park.

Also be aware that the IC9100 has 3 fixed IF FM filters, 15Khz, 10kHz and 7.0Khz (Filter 1, 2 & 3). The TX deviation however for the 2 narrower ones is then set to 2.5kHz. You probably want to only use the 15kHz filter, but keep in mind for Doppler etc situations.

Cheers Bob

On 13/1/25 05:23, Brian - W7OWO wrote:

Since the audio processing is running within SDRConnect you need to redirect the sound Out device of SDRConnect to the input device of Dire Wolf.? I do this all the time on my Windows machines by using a virtual audio cable to connect the ins and outs.

It's a little more complicated that that. I can direct the audio out from SDRconnect to other applications such as WSJT-X and QSSTV. Direwolf requires it's own audio stream, and not a shared one.

Anyway, it's not a major problem I was just curious and thank you your reply.

--
Regards,
Phil

开云体育

Hi Cass

I assume that pavucontrol Recording tab shows PCM2901.. and the input level display is stuttering at least halfway up the scale on no signal? Also check it isn't muted (the red crossed speaker icon background is white not grey) (The stuttering bar graphs will still show even if it is muted!) Also check that both left and right channels are not at 0%

I haven't used iptables in years, but it is possible to clear everything for testing, which then gets reapplied next boot. rigctl (and thus any concern about IP blocking) however can be test with the rigctld window running and in another window (examples);

rigctl -m 2 f
??? will display the operating frequency
rigctl -m 2 T 1
??? Makes the rig TX
rigctl -m 2 T 0
??? Makes the rig RX

Not receiving/decoding packets though isn't rigctld base, unless the wrong RX freq was somehow set!

If you do have to manipulate iptables note that direwolf also listens on tcp 8000 and 8001, along with sending to rigctld on 4532. Your config disables the listeners, but you may want to use those interfaces some day.

Oh and TXDELAY 20 might be a bit too short. I run my 9100 at 30 but haven't really tested the limits.

One day you may want to test the pulse system in a local loopback mode, by using gen_packets to create a wav file of ax25, that can then be played back into direwolf. I'd probably use paplay for that after temporarily changing the pavucontrol direwolf recording input to a monitor of the default output.

I have been working on an audio buffer underrun problem that seems to appear with direwolf and pulseaudio. If you get any of these with repeated transmits get back to me as I may have a solution.

Cheers Bob VK2YQA

On 12/1/25 02:37, Mark Herson wrote:
Thank you Mark for your reply.

I may be wrong about this, but I Think that once SDRConnect is up and running, it assigns itself to the PC's sound playback system. Once assigned, it is not available for other use like direwolf.

That certainly is the case and I have not been able progress any further.

As SDRconnet matures it will include support for 3rd party plug-ins and no doubt one of those plug-ins will be an APRS reader. In the meantime I can continue to use GQRX which does include an APRS reader.

Xastir also works perfectly with Direwolf, or it did until I accidentality deleted a section of Xastir's configuration; I must sort this out sometime.

Thank you again for taking the time to reply.

--
Regards,
Phil