A little progress made to solve a bit of a thorny issue regarding what happens when the sbitx is rebooted when a usb device is connected like a headset. Sorry bit of a long post, but it needs to be.
Not much point in connecting things up if a reboot changes the order of devices, this has involved a fair amount of learning and research but hopefully it has been worth it.

• I know if I run the speaker-test -D default -c 1 -t wav command the sound comes out of the sbitx speaker
• If I run the?speaker-test -D plughw:CARD=II,DEV=0 -c 1 -t wav command, the sound comes out of my USB headset

and then if I run the arecord -D "plughw:CARD=Loopback,DEV=1" -f cd | aplay -D "plughw:CARD=II,DEV=0" and then start the sbitx app, I get sound from the radio fed to both the speaker and my USB headset. The headset volume is a little on the low side but it is usable and is progress. Adding the -f cd option to the arecord command actually improves the audio quality fed to the headset by reducing some of the noise level on the audio from the radio.

I have now updated the /etc/rc.local file to create/amend the number of Loopback devices available:

modprobe snd-aloop enable=1,1,1,1 index=1,2,3,4

(If you are not interested in connecting other headset devices e.g. USB or Bluetooth, I would amend this line to read modprobe snd-aloop enable=1,1 index=1,2 to remove the unwanted Loopback_2 interface to keep things simple and tidy.)

Using this update creates 4 loopback interfaces so that when cat /proc/asound/cards is run you get a list of the available sound cards:

pi@sbitx:~ $ cat /proc/asound/cards

?0 [audioinjectorpi]: audioinjector-p - audioinjector-pi-soundcard

? ? ? ? ? ? ? ? ? ? ? audioinjector-pi-soundcard

?1 [Loopback? ? ? ?]: Loopback - Loopback

? ? ? ? ? ? ? ? ? ? ? Loopback 1

?2 [Loopback_1? ? ?]: Loopback - Loopback

? ? ? ? ? ? ? ? ? ? ? Loopback 2

?3 [Loopback_2? ? ?]: Loopback - Loopback

? ? ? ? ? ? ? ? ? ? ? Loopback 3

?4 [Loopback_3? ? ?]: Loopback - Loopback

? ? ? ? ? ? ? ? ? ? ? Loopback 4

We know that audioinjectorpi (card 0) is used for the sbitx audio I/O
We know that Loopback (card 1) is used for the output to digital software such as JTDX, FLDIGI etc.
We know that Loopback_1 (card 2) is used as the capture interface from the digital software such as JTDX, FLDIGI etc.
As delivered Loopback_2 (card 3) is not used for anything (that I can find anyway)
So to mirror the digital audio I/O I created an additional Loopback interface using the update to /etc/rc.local

Now for the device order problem: when I connected the USB headset after powering on the radio it would appear at the end of the list using cat /proc/asound/cards:

pi@sbitx:~ $ cat /proc/asound/cards

?0 [audioinjectorpi]: audioinjector-p - audioinjector-pi-soundcard

? ? ? ? ? ? ? ? ? ? ? audioinjector-pi-soundcard

?1 [Loopback? ? ? ?]: Loopback - Loopback

? ? ? ? ? ? ? ? ? ? ? Loopback 1

?2 [Loopback_1? ? ?]: Loopback - Loopback

? ? ? ? ? ? ? ? ? ? ? Loopback 2

?3 [Loopback_2? ? ?]: Loopback - Loopback

? ? ? ? ? ? ? ? ? ? ? Loopback 3

?4 [Loopback_3? ? ?]: Loopback - Loopback

? ? ? ? ? ? ? ? ? ? ? Loopback 4

?5 [II? ? ? ? ? ? ?]: USB-Audio - Jabra EVOLVE 30 II

? ? ? ? ? ? ? ? ? ? ? GN Audio A/S Jabra EVOLVE 30 II at usb-0000:01:00.0-1.1, full speed

pi@sbitx:~ $?

However if I rebooted the radio with the USB device still connected then the listing would look like?

pi@sbitx:~ $ pactl list cards short

54??????????????alsa_card.usb-GN_Audio_A_S_Jabra_EVOLVE_30_II_0000F358FA9E07-00????????????alsa

55??????????????alsa_card.platform-soc_sound??????????????????alsa

56??????????????alsa_card.platform-snd_aloop.2???????????????alsa

57??????????????alsa_card.platform-snd_aloop.1???????????????alsa

pi@sbitx:~ $

NOTE the different command used, still achieves the same thing and this was being used before I got to my solution. The issue here is that the USB device is now top of the ordered list and prevents sbitx from accessing the audioinjectorpi card because the USB device is now hw:0,0 instead of the audioinjector pi device. Note also that a Loopback interface has also disappeared!
if I unplug the USB device and reboot the correct order is resumed :

pi@sbitx:~ $ pactl list cards short

54????????????? alsa_card.platform-soc_sound????????????????? alsa

55????????????? alsa_card.platform-snd_aloop.2?????????????? alsa

56????????????? alsa_card.platform-snd_aloop.0?????????????? alsa

57????????????? alsa_card.platform-snd_aloop.1?????????????? alsa

pi@sbitx:~ $

Normal service is resumed now, If I connect the USB headset again it gets added to the list at the end as it should:

connect headset:

pi@sbitx:~ $ pactl list cards short

54????????????? alsa_card.platform-soc_sound????????????????? alsa

55????????????? alsa_card.platform-snd_aloop.2?????????????? alsa

56????????????? alsa_card.platform-snd_aloop.0?????????????? alsa

57????????????? alsa_card.platform-snd_aloop.1?????????????? alsa

106?????????? alsa_card.usb-GN_Audio_A_S_Jabra_EVOLVE_30_II_0000F358FA9E07-00??????????? alsa

pi@sbitx:~ $

Reboot again with the headset connected just to prove the point:

pi@sbitx:~ $ pactl list cards short

54????????????? alsa_card.usb-GN_Audio_A_S_Jabra_EVOLVE_30_II_0000F358FA9E07-00??????????? alsa

55????????????? alsa_card.platform-soc_sound????????????????? alsa

56????????????? alsa_card.platform-snd_aloop.2?????????????? alsa

57????????????? alsa_card.platform-snd_aloop.1?????????????? alsa

pi@sbitx:~ $

After headscratching, extensive use of Google and testing and retesting here is the solution:
In order to consistently achieve a correct order of devices a couple of commands were used to determine device names, note that I am totally focussed on using ALSA here to minimise complexity.
What we need to achieve is this order whenever the device is rebooted:

pi@sbitx:~ $ cat /proc/asound/modules

?0 (efault)

?1 snd_aloop

?2 snd_aloop

?3 snd_aloop

?4 snd_aloop

?5 snd_usb_audio

pi@sbitx:~ $?

or

pi@sbitx:~ $ cat /proc/asound/cards

?0 [audioinjectorpi]: audioinjector-p - audioinjector-pi-soundcard

? ? ? ? ? ? ? ? ? ? ? audioinjector-pi-soundcard

?1 [Loopback? ? ? ?]: Loopback - Loopback

? ? ? ? ? ? ? ? ? ? ? Loopback 1

?2 [Loopback_1? ? ?]: Loopback - Loopback

? ? ? ? ? ? ? ? ? ? ? Loopback 2

?3 [Loopback_2? ? ?]: Loopback - Loopback

? ? ? ? ? ? ? ? ? ? ? Loopback 3

?4 [Loopback_3? ? ?]: Loopback - Loopback

? ? ? ? ? ? ? ? ? ? ? Loopback 4

?5 [II? ? ? ? ? ? ?]: USB-Audio - Jabra EVOLVE 30 II

? ? ? ? ? ? ? ? ? ? ? GN Audio A/S Jabra EVOLVE 30 II at usb-0000:01:00.0-1.1, full speed

pi@sbitx:~ $

The solution is straightforward when you know how and what it is but it took a bit of finding along with trial and error :-)
Create this file (it doesn't exist on the delivered sbitx) using the command:
sudo nano /etc/modprobe.d/alsa-base.conf?

Add these lines to the file:

options (efault) index=-2? ? ? ? ? ? ? ? ? ? ? ? ? #am sure this should say default in the brackets but that is how the hw:0,0 device we want was listed in the cat /proc/asound/modules command

options snd_usb_audio index=5

?

Save the file and reboot with the USB device still connected. Note it is the output from the command cat /proc/asound/modules command that is important for this to identify the correct device names to use in the file. The higher the index value, the lower down the priority list they appear. to be really sure it might be worth adding the all the interface modules with an assigned index value to properly maintain the list order.

Do the check commands to ensure the USB device is at the bottom of the list (index=5) following reboots:

pi@sbitx:~ $ cat /proc/asound/cards

?0 [audioinjectorpi]: audioinjector-p - audioinjector-pi-soundcard

? ? ? ? ? ? ? ? ? ? ? audioinjector-pi-soundcard

?1 [Loopback? ? ? ?]: Loopback - Loopback

? ? ? ? ? ? ? ? ? ? ? Loopback 1

?2 [Loopback_1? ? ?]: Loopback - Loopback

? ? ? ? ? ? ? ? ? ? ? Loopback 2

?3 [Loopback_2? ? ?]: Loopback - Loopback

? ? ? ? ? ? ? ? ? ? ? Loopback 3

?4 [Loopback_3? ? ?]: Loopback - Loopback

? ? ? ? ? ? ? ? ? ? ? Loopback 4

?5 [II? ? ? ? ? ? ?]: USB-Audio - Jabra EVOLVE 30 II

? ? ? ? ? ? ? ? ? ? ? GN Audio A/S Jabra EVOLVE 30 II at usb-0000:01:00.0-1.1, full speed

pi@sbitx:~ $ cat /proc/asound/modules

?0 (efault)

?1 snd_aloop

?2 snd_aloop

?3 snd_aloop

?4 snd_aloop

?5 snd_usb_audio

pi@sbitx:~ $?

?

Now that bit is sorted we can start to try and reliably route audio to a USB headset based on the knowledge that the device whether plugged in or not won't affect the core audio routing of the sbitx radio.?
Just got to work that bit out now using the Loopback_2 for playback to the USB device and Loopback_3 for capture from the USB device microphone, that way we don't impact the digital functionality of the radio.
Might need some coding help with that bit, logically I know it can be done having proved some of the routing via the command line earlier, but now need the output from the codec that feeds the speaker and Loopback(card 1) to also feed Loopback_3(card 3) for play with a volume control (maybe using the Master Volume)? capability to drive the headset with more audio.?
Another option would be to take the output/input directly to/from the USB device but maybe that's a bit trickier

I believe an alternative headset solution is now a bit nearer

Regards
Paul G0KAO

Hi Gordon,

Sure you can receive email. We worked quite a bit in the email system to
provide the needs for our partners and communities in the field, be it
in Amazon rainforest or Central Africa. I'm happy Winlink has all these
human involvement and provides all these services over HF, and more
importantly, keep it working!

Btw, I never proposed a replacement to Winlink. I'm just commenting on
UUCP over HF, including its uses in remote and war-torn areas, or just
as backup communication. In terms of networking technology, it fits the
purpose very well, while being well supported in any Linux distribution
and email stacks (Postfix, Exim, sendmail). For eg., UUCP is ready to be
installed / used from the app repository (including Debian / Raspberry
OS), while being in use for 40+ years.

Cheers,
Rafael

On 2/2/24 15:26, Gordon Gibby wrote:
> FAscinating!? ?Does it work in reverse?? ?Can you RECEIVE email?
>
> 1.? ?The Winlink peolpe had to deal with the fact that receiving
> email?is 3rd party traffic and has to follow the laws.? ?They also
> wanted to completely avoid spam email.? ?They worked out very
> intricate systems to protect and allow workarounds for "emergency?
> break glass" situations.
> 2.? The winlink people also came up with a large number of automated
> systems of knowledge, because they began with the maritime oceanic
> sailing community.? So for example if you are in the middle of the
> ocean, you can ask for and receive by email, a WEATHER MAP for your
> part of the ocean.? ?They have like about 40 different products you
> can receive in this manner, including news and other things you might
> really want to know.? ?Weather forecasts, yada yada yada.? ?they had
> to do a lot of legwork to make all that work, and to KEEP IT WORKING.?
> ?It has proven to be very useful during emergencies.? ?For example, I
> can pull weather information in the middle of a hurricane when other
> sources are no longer available
> 3.? The winlink network includes both peer to peer and client server
> and radio only.? ? Radio only was demanded by the US Government.? ?It
> provides automated, computer/radio to compuer/radio routing of email.?
> ?For example, I once deposited a radio-only email in Canada, and
> wihtin an hour it had been relayed (all without human inervention)
> through esablished servers along the USA East Coast, and was availble
> for me to receive.? ?When you arre?"radio only" -- there is NO
> INTERNET? ?So you cannot pick your mail by using your regular email
> vendor -- you must use a radio!? ?The email is cached for you at 1, 2
> or 3 servers that you have pre-picked and are known to the system.?
> ?The radio only email is cached at all of them, mirror-like
>
> Those folks have been at it for over 2 decades and have been used in
> just about every disaster you can think of, albeit peripherally.?
> ?They have a ton of "institutional knowledge" about "human behavior
> and needs" in those situations.? ?Missionaries, medical trips, a bunch
> of groups have taken advtange of their system.? Currently, ARES(R)
> groups all overr?the nation are using them, as have Red Cross
> systems.? ?Out of a war-torn area -- Winlink works.
>
> Despite the FCC prohibition of encryption, they found a way to provide
> fairly reliable "user identification" so as to avoid spoofing.? ?You
> can even use telnet to access their system....but it is PaINFUL.
>
> I hope this information is helpful.? ?A replacement system needs to
> provide all the same, or better, integration into human needs and
> behaviors in both normal and disaster/war days.
>
> Thanks for all you are telling me about!
> Gordon KX4Z
>
>
> On Fri, Feb 2, 2024 at 9:42?AM Rafael Diniz <rafael@...>
> wrote:
>
>? ? ?Hi Gordon,
>
>? ? ?If later on anyone wants to put up a ham radio uucp HF gateway, As
>? ? ?uucp
>? ? ?setup is not that easy, I can help with all the uucp setup for remote
>? ? ?and gateway stations (I have bash scripts and templates ready) and
>? ? ?provide server access to our *.hermes.radio (just choose a subdomain)
>? ? ?for initial testing, if needed. This is what we call "central"
>? ? ?server,
>? ? ?with real IP in the VPS. The "gateway" station just relays emails to
>? ? ?"central" email server, and connects (or receive connection) to the
>? ? ?"remote" stations over HF. This is the topology I put in place. With
>? ? ?VARA and/or Ardop (this is what my uucp bridge supports [1]).
>
>? ? ?for example, to triger the connection to the gateway (and
>? ? ?consequently
>? ? ?synchronize the uucp jobs, aka. emais), from a remote station, I
>? ? ?just do:
>? ? ?uucico -S gw
>
>? ? ?where gw is a uucp alias to the uucp gateway nodename, and
>? ? ?remember to
>? ? ?put the radio in the same frequency of the other station.
>
>? ? ?the uucp bridge automatically calls the nodename to be connected,
>? ? ?which
>? ? ?in the case is the callsign of the station, for example, PU2UIT (the
>? ? ?nodenames must be valid callsigns for vara and ardop be happy).
>
>? ? ?[1]
>
>? ? ?Cheers,
>? ? ?Rafael
>
>? ? ?On 2/2/24 14:22, Gordon Gibby wrote:
>? ? ?> Rafael, that is very upstanding of you!? ?I had no idea that
>? ? ?uucp is
>? ? ?> still moving such traffic over HF radio? (I'm not counting
>? ? ?Internet).
>? ? ?> Thank you for the education -- I'm benefitting from your
>? ? ?knowledge and
>? ? ?> experience!
>? ? ?>
>? ? ?> The Winlink folks have both a centralized and a decentralized
>? ? ?model,
>? ? ?> so it can gett tricky to count, but the data piles up month over
>? ? ?month
>? ? ?> here:
>? ? ?> (click the "traffic" tab):
>? ? ?> ?(see attachment)
>? ? ?>
>? ? ?> looks like about 76,000 per HF in January
>? ? ?> another 45,000 or so over VHF
>? ? ?> Total over RF >100,000? or over 3,000 per day.
>? ? ?>
>? ? ?> Again, EVENTUALLY a system will show up that gains even wider
>? ? ?> acceptance.? ?For all I know UUCP is "there" if you count military
>? ? ?> (the above figures have no military).? ? I hadn't thought of
>? ? ?that.....
>? ? ?>
>? ? ?> THANKS!? It is great to learn from all the smart people here!
>? ? ?> Gordon KX4Z
>? ? ?>
>? ? ?>
>? ? ?> On Fri, Feb 2, 2024 at 9:16?AM HA3HZ <gyula@...> wrote:
>? ? ?>
>? ? ?>? ? ?There are a few LOG programs on github that work under Linux.
>? ? ?>? ? ?It is currently still being developed. It communicates with the
>? ? ?>? ? ?radio via port:
>? ? ?>
>? ? ?>? ? ?FieldDayLogger <>
>? ? ?>
>? ? ?>? ? ?not1mm <>
>? ? ?>
>? ? ?>? ? ?As far as I know, the N3FJP AC program works under Windows.
>? ? ?>? ? ?Wine or box86 seems to me to be highly OS dependent.
>? ? ?>? ? ?Therefore, I think that communication through the port should be
>? ? ?>? ? ?prioritized.
>? ? ?>? ? ?It is difficult to part with the usual program. We need to know
>? ? ?>? ? ?that only change is constant.
>? ? ?>? ? ?--
>? ? ?>? ? ?Gyula HA3HZ
>? ? ?>
>? ? ?>
>
>
>
>
>
>