Closed jmkristian closed 5 months ago
Fixed in "dev" development branch which will become release 1.8. Only valid channels are listed. Commit c9b7c61 .
Thank you; that's a good start. Now the 'G' response looks better.
However, an AGW client can't use the second AGW port; that is the second in the list of ports in the 'G' response. For details, see the attached log and configuration files.
I built direwolf on Ubuntu 22.04.3 from the dev branch commit c9b7c61f2cb645. direwolf.log direwolf.conf.txt
Shall I open a new issue?
A client can use AGW port 2 (the third port), although it's not listed in the 'G' response. direwolf-2.log
If I configure two mono devices, like this:
... the second device isn't visible to AGW clients. For example, QtTermTCP shows
,
because Direwolf responds to an AGW 'G' request with:
{dataKind:"G", data:"2;Port1 first soundcard mono;Port2 INVALID CHANNEL;Port3 second soundcard mono;Port4 INVALID CHANNEL;Port5 INVALID CHANNEL;Port6 INVALID CHANNEL;\u0000"}
The '2' at the beginning of the data signifies there are only two ports. AGW clients ignore the 'Port3' part, because the data starts with '2;'.
In this case, the 'G' response should either show the second soundcard mono as Port2, or start with '3;' to signify there are three ports. I would prefer the former; that is, an invalid channel is not a port.
To work around this bug, one can configure the first device as stereo (ACHANNELS 2). But this may create a useless port. For example, audio is not transmitted through the right channel of a Digirig Mobile or the left channel of a Masters Communications DRA-65.
I used Direwolf built from source tag 1.7 commit de293a1f2526ec663 on Ubuntu 22.04.3 on an x86_64 laptop.