开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育
  1. BITX20
  2. Topics

SBITX v3 - Ability to use a Headset for phone modes

Paul
 

The challenge - I and many other users want to be able to use a headset for the phone modes in the sbitx e.g. USB headset or a Bluetooth headset.
Logically the problem is similar to the routing of audio for the digital modes from the audioinjectorpi sound card to/from the software used for the digital modes.

The soundcards identified in the sbitx using the command aplay -l | awk -F \: '/,/{print $2}' | awk '{print $1}' | uniq?generates on the sbitx:

pi@sbitx:~ $ aplay -l | awk -F \: '/,/{print $2}' | awk '{print $1}' | uniq
audioinjectorpi
Loopback
Loopback_1
Loopback_2
pi@sbitx:~ $
?
audioinjectorpi (card 0 in ./asoundrc) is the default output (and mic input) for the sbitx analogue audio
Loopback,DEV=1 (card 1 in ./asoundrc) is used for software output(Input) to JTDX, WSJT-X or others
Loopback_1,DEV=0 (card 2 in ./asoundrc) is used for Software input(Capture) from JTDX, WSJT-X or others
?
Question - is Loopback_2 used by sbitx?
If yes, could we use this one to route analogue audio I/O from card 0 (audioinjectorpi) on SBITX to another audio I/O device such as a USB headset or Bluetooth headset?

After connecting my USB headset I ran the command again:
pi@sbitx:~ $ aplay -l | awk -F \: '/,/{print $2}' | awk '{print $1}' | uniq
audioinjectorpi
Loopback
Loopback_1
Loopback_2
II
pi@sbitx:~ $
the II shown in this command output is the USB Headset (Jabra Evolve 30 II in my case)

More detail re the ./asoundrc file:
The system configuration file is /etc/asound.conf (not exist on sbitx), and the per-user configuration file is ~/.asoundrc.
?
sbitx asoundrc:
pi@sbitx:~ $ cat ~/.asoundrc
pcm.!default {
type asym
playback.pcm {
type plug
slave.pcm "output"
}
capture.pcm {
type plug
slave.pcm "input"
}
}
pcm.output {
type hw
card 0
}
?
ctl.!default {
type hw
card 0
}
?
pcm.input {
type hw
card 0
}
pi@sbitx:~ $?
?
A couple of references:



These suggest it looks promising, the devil is in the detail

I am trying to avoid the use of PulseAudio as that has been replaced in newer distributions using Pipewire and Wireplumber, however both of these sit on top of ALSA. Based on this will focus my efforts on using Alsa if possible to minimise complication. Might not be possible but it is a starting point with help from the references above.

Research continues - if I get the answer and tested, it will be added here to begin with and then the wiki page as a Howto
If anyone already solved it then please add to the topic.

Regards
Paul G0KAO
?
?
 

On Mon, Jan 29, 2024 at 04:44 PM, Paul wrote:
Question - is Loopback_2 used by sbitx?
I don't think so.? gives:



So we have plughw device 0 used for the codec, 1 and 2 used for loopback, leaving the third loopback (numbered 3) unused.


The same search gives a hint of how they get used and how they get created:



Line 20 creates three of them, placed at indices 1,2,3.

Line 14: I found it was important to use the full address:port ( 127.0.0.1:4532 ) not just 127.0.0.1?

I edited the wiki page posted earlier so it has this update.

If yes, could we use this one to route analogue audio I/O from card 0 (audioinjectorpi) on SBITX to another audio I/O device such as a USB headset or Bluetooth headset?
Yes.? Below is a proof of concept.

After connecting my USB headset I ran the command again:
pi@sbitx:~ $ aplay -l | awk -F \: '/,/{print $2}' | awk '{print $1}' | uniq
audioinjectorpi
Loopback
Loopback_1
Loopback_2
II
?
Mine gives:

$ aplay -l | awk -F \: '/,/{print $2}' | awk '{print $1}' | uniq
audioinjectorpi
Loopback
Loopback_1
Loopback_2
Device

So it gives the odd name 'Device' to my USB sound card device.

Another way to see it:

$ 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 [Device? ? ? ? ?]: USB-Audio - USB PnP Sound Device
? ? ? ? ? ? ? ? ? ? ? C-Media Electronics Inc. USB PnP Sound Device at usb-0000:01:00.0-1.2.2, full s

These suggest it looks promising, the devil is in the detail
Great, I get to play satan!


I am trying to avoid the use of PulseAudio as that has been replaced in newer distributions using Pipewire and Wireplumber, however both of these sit on top of ALSA. Based on this will focus my efforts on using Alsa if possible to minimise complication. Might not be possible but it is a starting point with help from the references above.

Research continues - if I get the answer and tested, it will be added here to begin with and then the wiki page as a Howto
If anyone already solved it then please add to the topic.
I've done a small proof of concept to play sound from sbitx's loop device out to my usb sound card.

What I did to try to make progress was to set up and test wsjt-x using the settings in the wiki page posted earlier.

That told me what device names to use.

Then I tried a few things but in the end what worked for me was to set up a gnuradio flowgraph using its audio source and audio sink.

This is what it looks like:


?
The stuff in the bottom right shows the variables I created, the same stuff is in the text under each variable block.

To be honest I guessed incorrectly based on what wsjt-x refers to as sound card input vs output.??

I used the 'QT GUI Sink' to show a FFT and waterfall of the data and changed names around and it worked.

This is what is known as the FAFO method (f-around, find out).

Then to show it worked, I moved over to the linux CLI and did:

$ arecord -D "plughw:CARD=Loopback,DEV=1" | aplay -D "plughw:CARD=Device,DEV=0"

and this worked, it records from the loopback device sbitx writes to and plays to the usb device.

In your case, substitute Device with II and I think it should work.

The sound ain't great.? There's things like gains to work out and re-sampling to avoid (hint: plughw is doing resampling if it needs to).

But it is a proof-of-concept, for at least one direction.

Another hint is that the 'sox' program can do this all in one command more efficiently, and can do things like apply gain factors and filtering, etc.

The syntax for 'sox' is pretty unfriendly, though, IMO.

The other direction should just be a matter of putting the right source and destination devices into the same commands.

--
Regards,
Dave, N1AI
 

Hi Dave,

I've being using gnuradio-companion too for simple testing.

I committed some .grc files here, which might be useful:


Cheers,
Rafael

On 1/30/24 01:24, Dave, N1AI wrote:
On Mon, Jan 29, 2024 at 04:44 PM, Paul wrote:

Question - is Loopback_2 used by sbitx?

I don't think so. Searching for 'plughw' in the current code <> gives:



So we have plughw device 0 used for the codec, 1 and 2 used for loopback, leaving the third loopback (numbered 3) unused.


The same search gives a hint of how they get used and how they get created:



Line 20 creates three of them, placed at indices 1,2,3.

Line 14: I found it was important to use the full address:port ( 127.0.0.1:4532 ) not just 127.0.0.1

I edited the wiki page posted earlier so it has this update.

If yes, could we use this one to route analogue audio I/O from
card 0 (audioinjectorpi) on SBITX to another audio I/O device such
as a USB headset or Bluetooth headset?

Yes.? Below is a proof of concept.

After connecting my USB headset I ran the command again:
pi@sbitx:~ $ aplay -l | awk -F \: '/,/{print $2}' | awk '{print
$1}' | uniq
audioinjectorpi
Loopback
Loopback_1
Loopback_2
II

Mine gives:

$ aplay -l | awk -F \: '/,/{print $2}' | awk '{print $1}' | uniq
audioinjectorpi
Loopback
Loopback_1
Loopback_2
Device

So it gives the odd name 'Device' to my USB sound card device.

Another way to see it:

$ 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 [*Device* ? ? ? ?]: USB-Audio - USB PnP Sound Device
? ? ? ? ? ? ? ? C-Media Electronics Inc. USB PnP Sound Device at usb-0000:01:00.0-1.2.2, full s

These suggest it looks promising, the devil is in the detail

Great, I get to play satan!


I am trying to avoid the use of PulseAudio as that has been
replaced in newer distributions using Pipewire and Wireplumber,
however both of these sit on top of ALSA. Based on this will focus
my efforts on using Alsa if possible to minimise complication.
Might not be possible but it is a starting point with help from
the references above.

Research continues - if I get the answer and tested, it will be
added here to begin with and then the wiki page as a Howto
If anyone already solved it then please add to the topic.

I've done a small proof of concept to play sound from sbitx's loop device out to my usb sound card.

What I did to try to make progress was to set up and test wsjt-x using the settings in the wiki page posted earlier.

That told me what device names to use.

Then I tried a few things but in the end what worked for me was to set up a gnuradio flowgraph using its audio source and audio sink.

This is what it looks like:



The stuff in the bottom right shows the variables I created, the same stuff is in the text under each variable block.

To be honest I guessed incorrectly based on what wsjt-x refers to as sound card input vs output.

I used the 'QT GUI Sink' to show a FFT and waterfall of the data and changed names around and it worked.

This is what is known as the FAFO method (f-around, find out).

Then to show it worked, I moved over to the linux CLI and did:

$ arecord -D "plughw:CARD=Loopback,DEV=1" | aplay -D "plughw:CARD=Device,DEV=0"

and this worked, it records from the loopback device sbitx writes to and plays to the usb device.

In your case, substitute Device with II and I think it should work.

The sound ain't great.? There's things like gains to work out and re-sampling to avoid (hint: plughw is doing resampling if it needs to).

But it is a proof-of-concept, for at least one direction.

Another hint is that the 'sox' program can do this all in one command more efficiently, and can do things like apply gain factors and filtering, etc.

The syntax for 'sox' is pretty unfriendly, though, IMO.

The other direction should just be a matter of putting the right source and destination devices into the same commands.

--
Regards,
Dave, N1AI

OpenPGP_signature.asc
OpenPGP_signature.asc

Paul
 

Thanks for this Dave
AS expected replacing your Device with my II worked at treat.
Signal to noise level output not great and is worse in the headset than it is on the sbitx speaker, however its not great there on mine anyway. Turning the volume up on the sbitx just seems to make it worse. The usable volume range is such that there is almost no audio until the volume control reaches a setting of 50+, a reasonably comfortable audio setting of about 86 is required to listen to the sbitx speaker.?
Word of warning for anyone following this thread and using the 64-bit OS. if you boot the sbitx up with the USB headset plugged in, the sbitx app will not start,, unplug the headset and reboot again if this happens.
On the stock v3 sbitx I had a slightly different experience in that if I booted the radio up with USB headset connected, the headset would work in parallel with the sbitx speaker. Adjusting the volume on the rig makes no diference to the audio out of the USB headset currently. The headset has its own volume control in my case, this also changes the volume on the sbitx speaker as well in my case.

this command produces better output in my headset than I get from the sbitx speaker:

arecord -D "plughw:CARD=Loopback,DEV=1" -f cd | aplay -D "plughw:CARD=II,DEV=0"

Just need to increase the volume to it now, perhaps using the rig volume control to allow the headset volume control the local control for fine adjustment

A step in the right direction me thinks

Still testing
Regards
Paul G0KAO
 

On Tue, Jan 30, 2024 at 04:14 AM, Rafael Diniz wrote:
I've being using gnuradio-companion too for simple testing.

I committed some .grc files here, which might be useful:
Thank you!? I have been using your grc files from doc folder in sbitx-core.? I did not know about 'qt gui sink' till I used your flowgraphs.? It's really nice!? You can switch between fft and waterfall or even constellation if you are using complex signals for digital work.? The waterfall has an 'auto gain' button to help you find the signal and a fft size control that lets you change size dynamically. Before this I used the 'qt gui frequency sink' and 'qt gui waterfall' independently.? This is much nicer!
?
--
Regards,
Dave, N1AI
 

On Tue, Jan 30, 2024 at 04:24 AM, Paul wrote:

Thanks for this Dave
AS expected replacing your Device with my II worked at treat.

Wonderful!

Signal to noise level output not great and is worse in the headset than it is on the sbitx speaker, however its not great there on mine anyway.

Some of that could be due to the resampling that I mentioned.? Ideally plughw should not be used.? One should know the sampling rate of each signal and set up each program to match.??

Also the arecord | aplay pipeline is reprocessing the signal.

From the arecord man page:




So it is using 8 bit samples at 8000 hz.??

Bottom line is I did not bother so far to see what sampling rate and sample size is being used in the sbitx_sound.c code when writing to the loopback device, but whatever it is, it would work better if they were all the same.

Also as I said already, 'sox' would be more efficient and would let you set gain and add filtering as it implements various 'effects'.


Turning the volume up on the sbitx just seems to make it worse.

My EE professor would smile now.? Amplifying a bad signal only makes it worse.? He was an analog guy.? In modern terms, resampling a sample just makes it worse.


The usable volume range is such that there is almost no audio until the volume control reaches a setting of 50+, a reasonably comfortable audio setting of about 86 is required to listen to the sbitx speaker.?

Might be partially due to arecord using 8 bit samples, not much dynamic range to work with.


Word of warning for anyone following this thread and using the 64-bit OS. if you boot the sbitx up with the USB headset plugged in, the sbitx app will not start,, unplug the headset and reboot again if this happens.
On the stock v3 sbitx I had a slightly different experience in that if I booted the radio up with USB headset connected, the headset would work in parallel with the sbitx speaker.

This is the physical names vs logical names issue I mentioned earlier.??


this command produces better output in my headset than I get from the sbitx speaker:

arecord -D "plughw:CARD=Loopback,DEV=1" -f cd | aplay -D "plughw:CARD=II,DEV=0"

Ok, you are proving what I said above.? This uses 'CD' format so not 8 bits at 8000 hz, instead 16 bits at 44,000 hz.


Just need to increase the volume to it now, perhaps using the rig volume control to allow the headset volume control the local control for fine adjustment

A step in the right direction me thinks

Agree.
?
--
Regards,
Dave, N1AI

Paul
 

On Tue, Jan 30, 2024 at 05:02 AM, Dave, N1AI wrote:

The usable volume range is such that there is almost no audio until the volume control reaches a setting of 50+, a reasonably comfortable audio setting of about 86 is required to listen to the sbitx speaker.?

Might be partially due to arecord using 8 bit samples, not much dynamic range to work with.
this was on the SBITX speaker, not the headset, hence the headset is more comfortable to listen to once I can get the volume/gain level right and ideally adjustable, the headset volume is restricted by the amount of gain controlled by the loopback device used to test so headset volume adjusted to max and it was easy enough to listen on 40m SSB earlier today even weak signals were audible in the headset compared to listening on the sbitx speaker which is a good improvement really.

The logical next step (for playback anyway) now is to get the audio out of audioinjectorpi into a separate loopback (maybe the unused spare perhaps) as well as the ones used for digital so as not to upset the digital functions that seem to work well so far but volume control fixed in those, need it to be variable in the new Loopback.

While I can figure out and read code to some extent I am not a programmer, logically, I would probably copy the code that drives loopback 0(hw:1,0) from hw:0,0 and use it to drive loopback 2(would be hw:3:0) so that hw:0,0 plays audio output to both loopbacks at the same time. That way the changes to drive another audio device can be made in isolation related to the new loopback device.
Repeat this process again for the Capture side of things if needed but just focusing on play for now.
I did install gnuradio with a view to trying to draw this but bit of a learning curve :-)

The art of drawing in text? :-)
hw:0,0 >>>>>> Loopback,DEV=0 (hw:1,0) >>>>>>>> Loopback,DEV=1 (hw:1,1)? >>>>>>>>>>> Digital Software input
hw:0,0 >>>>>> Loopback_2,DEV=0 (hw:3,0) >>>>>> Loopback_2,DEV=1 (hw:3,1) >>>>>>>>>> Alternative Audio Device input i.e. USB Headset

Sort of makes sense to me but happy to be corrected

Regards
Paul G0KAO
 

On Tue, Jan 30, 2024 at 11:17 AM, Paul wrote:
this was on the SBITX speaker, not the headset
Ok.?

hence the headset is more comfortable to listen to once I can get the volume/gain level right and ideally adjustable,
I have a range of old-school wired headsets and computer speakers to plug into the headset jack.? Audio could be better but not bad overall.

the headset volume is restricted by the amount of gain controlled by the loopback device used to test
Sorry if I'm being redundant but 'sox' can take a gain factor in db.?

so headset volume adjusted to max and it was easy enough to listen on 40m SSB earlier today even weak signals were audible in the headset compared to listening on the sbitx speaker which is a good improvement really.
Nice!

The logical next step (for playback anyway) now is to get the audio out of audioinjectorpi
Hope I'm not being too picky, but what comes out of audioinjectorpi is not audio, it's radio data that needs to be processed by software (DSP code) to get audio.

into a separate loopback (maybe the unused spare perhaps) as well as the ones used for digital so as not to upset the digital functions that seem to work well so far but volume control fixed in those, need it to be variable in the new Loopback.
I think the space needs to be investigated.? Ideally we'd have something like DAX for the Flexradio 6000 where the user could set up the different things they expect to send data or audio to, and then the software would deliver what is requested and nothing more.? Poor JJ, another app for him to write!? As far as I can tell the current software just writes to the two loopbacks all the time, regardless of if anyone is listening or not.

While I can figure out and read code to some extent I am not a programmer, logically, I would probably copy the code that drives loopback 0(hw:1,0) from hw:0,0 and use it to drive loopback 2(would be hw:3:0) so that hw:0,0 plays audio output to both loopbacks at the same time. That way the changes to drive another audio device can be made in isolation related to the new loopback device.
Repeat this process again for the Capture side of things if needed but just focusing on play for now.
That's certainly possible.

I did install gnuradio with a view to trying to draw this but bit of a learning curve :-)
Yes, I agree.? I was thinking of doing a little video at some point to show how I made this simple flowgraph and how easy it is to extend it.

The art of drawing in text? :-)
hw:0,0 >>>>>> Loopback,DEV=0 (hw:1,0) >>>>>>>> Loopback,DEV=1 (hw:1,1)? >>>>>>>>>>> Digital Software input
hw:0,0 >>>>>> Loopback_2,DEV=0 (hw:3,0) >>>>>> Loopback_2,DEV=1 (hw:3,1) >>>>>>>>>> Alternative Audio Device input i.e. USB Headset

Sort of makes sense to me but happy to be corrected
Makes sense.
?
--
Regards,
Dave, N1AI
Paul
 

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
 

Paul,? do I understand this properly:? ? with your solution, a straight-through USB cable from your headset output to a USB connector on a DIFFERENT computer, would appear to be the digital output of a sound card?? ?(Not the analog output that would go to a normal physical speaker)

Do I understand that correctly?
Thanks,
Gordon KX4Z


On Fri, Feb 2, 2024 at 6:10?PM Paul <g0kaohx@...> wrote:
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
Paul
 

Hi Gordon
While that may be possible I think it might need a bit more work, however once the routing of audio is possible to a USB headset or other audio device, then yes if for example you had another computer running JTDX, then yes at least from an audio perspective only, you could connect it to the sbitx audio.
What I have achieved so far with the steps outlined is the consistent ability to identify a USB connected audio device in this case that can be hotplugged into the sbitx without affecting the current audio delivery to the core functions of the radio.
The challenge now is to sort out the routing of the audio from the sbitx application to the USB audio, if you try the command line arecord command using the existing loopback feed it does work, but the audio level is fixed, this might be good enough for digital modes output to another computer but its not really enough for SSB work which is the bit I want to address.
I quote JTDX because it is my preferred FT8 application but the same applies for other digiital audio applications too.
It does have the potential to open up other possible audio use cases I think once this is sorted.

Regards
Paul G0KAO
Paul
 

Essentially that is what the loopback interfaces are. So what I have done is identified the existing loopback interfaces and how they are used, I have then created a new pair ready to route the sbitx audio to a different device.
To illustrate:
Loopback 1 is used to send receive audio from the sbitx app at a fixed volume level to the digital software e.g. wsjt-x
Loopback 2 is used to capture output(mic) audio from the digital software e.g. wsjt-x and feed that back to the sbitx app for transmission

I have created a new pair of Loopback interfaces (3 & 4) to replicate this functionality with a USB connected audio device/headset but I need the source audio to have adjustable volume(gain) controls for SSB purposes.
That is the next puzzle to solve which will involve a bit of coding in the sbitx application. I will investigate this but need to better understand the coding architecture so that I can have a go at making the required updates.
At least the structural foundation is there now from a hardware perspective.

Regards
Paul G0KAO
 

Paul,
See the mixer functions of sound_sbitx.c, they should help.

On Sat, Feb 3, 2024, 4:04 PM Paul <g0kaohx@...> wrote:
Essentially that is what the loopback interfaces are. So what I have done is identified the existing loopback interfaces and how they are used, I have then created a new pair ready to route the sbitx audio to a different device.
To illustrate:
Loopback 1 is used to send receive audio from the sbitx app at a fixed volume level to the digital software e.g. wsjt-x
Loopback 2 is used to capture output(mic) audio from the digital software e.g. wsjt-x and feed that back to the sbitx app for transmission

I have created a new pair of Loopback interfaces (3 & 4) to replicate this functionality with a USB connected audio device/headset but I need the source audio to have adjustable volume(gain) controls for SSB purposes.
That is the next puzzle to solve which will involve a bit of coding in the sbitx application. I will investigate this but need to better understand the coding architecture so that I can have a go at making the required updates.
At least the structural foundation is there now from a hardware perspective.

Regards
Paul G0KAO
Paul
 

Thanks Ashar
I am guessing you mean sbitx_sound.c as I can’t find the one you said :-)
Paul
 

I may have some success, there is a caveat in that the master volume control doesn't work, yet to adjust USB volume, however my Jabra Evolve USB headset has an inline volume control, the ALSA mixer also allows volume adjustment. The modification also appears to mute the radio speaker but for now having rx audio out via USB headset when sbitx starts is a modest win I think. While writing this I tried unplugging the USB headset to see if audio returned to the speaker, it didn't, it didn't return following a reboot until I reconnected the USB headset. So not quite the win I had hoped but some progress in a small way.

I finally dipped my toe into the code, first time modifying code for a very long time, the modification is to sbitx_sound.c. If you want to try this noting that you will lose speaker audio with this mod, then insert the following lines of code after line 1054 in the original sbitx_sound.c file AFTER BACKING UP THE ORIGINAL FILE FIRST:

// New code to add playback out to a second Loopback device plughw:3,0 which will be used to?
//play audio out to a USB audio device e.g. USB Headset though actually may not need loopback, could go direct to?
//snd_usb_audio (plughw:5,0) this would be better
for (i = 0; i < 10; i++){
if(sound_start_play("plughw:5,0") == 0) #assumption is that USB headset is card 5 in the aplay -l interface list
break;
fprintf(stderr, "*Error opening USB Play device");
delay(1000);
printf("Retrying the sound system %d\n", i);
}
if (i == 10){
fprintf(stderr, "*Error opening USB Play device - Aborting");
return NULL;
}

I went straight for USB direct connection rather than use a Loopback interface described in my comments in my code update and it worked.
Just for clarity the next original line of code after this should read:
sound_thread_continue = 1;
to make sure the new code is inserted into the right place.

Once the code has been updated and saved, you will need to rebuild the sbitx application using the command ./build sbitx within a terminal window after changing to the sbitx directory with the cd sbitx command.

Assuming you have inserted the code correctly and not received any errors from the build process you can start the sbitx app with your usb headset connected.

I looked at other areas of modification, this one seemed the lowest impact and more logical, Still work to do to get it right?

Regards
Paul G0KAO
Paul
 

Notes for myself, series of tasks required to solve this:
  • Make whatever is sent to the radio speaker go the USB audio device as well, regardless of what it is
    • arecord -D "plughw:CARD=Loopback,DEV=1" -f cd | aplay -D "plughw:CARD=II,DEV=0? //works from terminal command line, reduced gain due to fixed gain sent to loopback interface, slightly better quality audio than from the speaker with the -f cd parameters added
  • Make the radio volume control work for both audio devices
  • Make whatever is input from USB audio device microphone go to the same input point used for the physical microphone (logically at least)
    • arecord -D "plughw:CARD=II,DEV=1" | aplay -D "plughw:CARD=Loppback_1,DEV=0" //not tested, but think it should work from a second terminal command line?
  • Make the Mic gain work for both USB and physical microphone devices
  • Identify where input/output devices are defined and then used as parameters passed to other code modules e.g. sound.h, sbitx_sound.c or within sbitx.c
    • Think this may be done in sbitx.c within void setup_audio_codec(){? ?strcpy(audio_card, "hw:0");? //rest of code snipped,
    • I have written a module for USB device which is? a copy of the one used but refers to USB device instead, 1st line is?strcpy(audio_card_usb, "hw:5"); rest of code module same but replace audio_card with audio_card_usb
  • Identify the appropriate parameters in the called modules and replace with an array to accept multiple devices
    • then replace the device parameters within the modules/subroutines to use the array name instead
  • Once the above is solved, make sure that radio speaker and microphone(s) are the default if any additional configured audio device is disconnected
  • or find a way to incorporate the command line snippets above so that they are part of the app at start rather than tying up 2 terminal sessions to run them outside the app. Volume/Gain would need to be adjusted as part of this to get satisfactory levels
  • If the code is updated and a modular approach defined then it should be possible to add Bluetooth Audio capability at some point in the distant future as the same approach used to solve the tasks above should be possible by adding the interface to the appropriate sections i.e. definition and arrays
  • further nice to have would be the ability to select from the app which device is to be used for rx audio or tx audio
The possible solution I outlined in the above message while it works is not the right answer especially now I have outlined the tasks needed to solve the problem and the problems already identified above.?
I tried a couple of software approaches to mapping the app process and calls but not been able to get them working on the pi as yet, so its the long method which takes a lot of time.?

It has been a very very long time since I had to do any real coding so any coders out there, feel free to help :-)

Paul G0KAO
?
 

  • Make whatever is sent to the radio speaker go the USB audio device as well, regardless of what it is
    • arecord -D "plughw:CARD=Loopback,DEV=1" -f cd | aplay -D "plughw:CARD=II,DEV=0? //works from terminal command line, reduced gain due to fixed gain sent to loopback interface, slightly better quality audio than from the speaker with the -f cd parameters added

Hey Paul,

Try this.. I am using a USB sound card on my sBitx64bit and was able to amplify the receive audio using sox..?

sudo apt-get install sox


arecord -D "plughw:CARD=Loopback,DEV=1" -f cd | sox -v 50.0 -t wav - -t wav - | aplay -D "plughw:CARD=5,DEV=0"

sox-v is the volume amplification level that you can adjust.



I was not able to get the USB mic input routing working yet..





-JJ
Paul
 

Thanks JJ
That works well for play in the Jabra Headset that I use, sox was already installed on the 64-bit image I use, here is the near enough final command line command that works for me:
pi@sbitx:~ $ arecord -D "plughw:CARD=sbitxdigiout,DEV=1" -f cd | sox -v 25.0 -t wav - -t wav - | aplay -D "plughw:CARD=5,DEV=0"? //lets me adjust a nice level of audio range with the headset volume control

I have renamed the loopbacks using a process I described in another post but essentially the command in my /etc/rc.local file is:
modprobe snd-aloop enable=1,1,1,1 index=1,2,3,4 id=sbitxdigiout,sbitxdigiin,sbitxusbout,sbitxusbin

The names are a bit long and might be shortened but just needed something I could relate to easily to begin with

Now I know the playback side of things work from the command line to a USB headset, want to incorporate into the app now so its a bit more automatic, yes it could probably be done by a startup script for the app perhaps and that might be the easiest approach but I prefer it to be within the app if possible. Audio out is better in the headset and not as coarse as it is from the speaker

Thanks again
Paul G0KAO
 

On Sat, Mar 9, 2024 at 03:47 AM, Paul wrote:
Thanks JJ
That works well for play in the Jabra Headset that I use, sox was already installed on the 64-bit image I use, here is the near enough final command line command that works for me:
pi@sbitx:~ $ arecord -D "plughw:CARD=sbitxdigiout,DEV=1" -f cd | sox -v 25.0 -t wav - -t wav - | aplay -D "plughw:CARD=5,DEV=0"? //lets me adjust a nice level of audio range with the headset volume control

I have renamed the loopbacks using a process I described in another post but essentially the command in my /etc/rc.local file is:
modprobe snd-aloop enable=1,1,1,1 index=1,2,3,4 id=sbitxdigiout,sbitxdigiin,sbitxusbout,sbitxusbin

The names are a bit long and might be shortened but just needed something I could relate to easily to begin with

Now I know the playback side of things work from the command line to a USB headset, want to incorporate into the app now so its a bit more automatic, yes it could probably be done by a startup script for the app perhaps and that might be the easiest approach but I prefer it to be within the app if possible. Audio out is better in the headset and not as coarse as it is from the speaker

Thanks again
Paul G0KAO
I could create an app for this.. It would be great to add more flexibility to the radio since the stock mic is not that good. Can you send me the working procedure that needs to be done to get it working with commands, files, and modifications?


Thanks,
JJ
 

I added this modification to my radio. and it works vert well.?
I did need to turn the sox level up to 50 for my headset but other than that it is a very straight forward and useful add on
I just threw a .sh script to my desktop to fire it off.. when the headset is unpluygged the process dies clean?

The only issue I have is with the digi modes now.. I need to figure out the new mappings for in's and out's because the expected device names are now augmented.

-W2JON

1 - 20 of 66