On Sun, Feb 4, 2024 at 11:59 AM, Dave, N1AI wrote:

I have done manual setups for using RTP streams using Pulse in Debian 11 with the "quisk" app driving the Hermes-Lite 2 SDR.

It more or less happens automatically if you use ssh with x-windows tunneling enabled, but you may need to set some environment variables to get things to work the way you want.

To try to add more detail, if you do 'man ssh' on a linux box you should see the '-X' option described as:


?
I guess it's proper name is "X11 forwarding" but most of us call it "tunneling".

On my Linux laptop I enable this by default by having the following in .bashrc:



When I use ssh from my laptop to the sbitx pi then start the 'vlc' program, its video is sent in the ssh tunnel using X forwarding to my laptop.

If I then use vlc's 'Media -> Open File' menu to open an audio file and hit the || button to play, I hear the audio.

The tunnel contains both xlib primatives for graphics as well as RTP/RTSP streams for audio.

This works because vlc is sending audio to the default PulseAudio device on the sbitx which is sending the audio via RTP that is then tunneled by ssh session to the Linux laptop which then sends it to the local PulseAudio to play on the laptop's default device.

If you run the PulseAudio 'pavucontrol' app on the laptop you can see that it is getting audio from VLC which is NOT running on the laptop!



If I start the sbitx application I do see its video, but do not hear any audio, it is playing to the sbitx speaker still.?

This is because the sbitx application hard codes use of the ALSA 'audioinjectorpi' device which writes the audio samples to the sbitx speaker.??

If you have a good 'ssh' client for Windows I believe all the same things will still happen when you use the equivalent of the '-X' flag to start it.

My favorite is MobaXterm ( ,? ).??

My head exploded when I first encountered it in the late 2010s.? It has an entire X server, plus ssh client, plus bash, plus all the rest of the Cygwin linux command set for DOS, plus lots of other stuff, all in a single Windows application?? I had worked with X on early RISC processors of the 1980s and 1990s, as well as early Linux x86 boxes from '386 onward.? All that stuff in a single Windows program?? I just could not believe it!!!

Having said that, these days I don't use Windows much so I have never tried it for this exact purpose, but I am pretty confident that it will work.

--
Regards,
Dave, N1AI

开云体育

I would listen to my broadcast . This way, the setting will be personalized.
--
Gyula HA3HZ

Hi David,

Thanks for the response. It is available with Adafruit. I have clone version. But it works.
I have put a 2k pot to ground on the O/P and wiper is presently connected to my PC to see the O/P.

The compression ration of this chip is 1:500 1:2000 and 1:4000. I cannot understand which is the best.

Regards
Ashok

Using google, the manufacturer's description is:
You can set the AGC and the gain to 3 different settings.
Details in the description.
--
Gyula HA3HZ

On Sun, Feb 4, 2024 at 10:07 AM, Dave, N1AI wrote:

cd $HOME
./build sbitx

Brain fart.

This should be:

cd $HOME/sbitx
./build sbitx
?
--
Regards,
Dave, N1AI

On Sun, Feb 4, 2024 at 08:46 AM, Ashhar Farhan wrote:

Is there a way we can provide a selection of where the audio routes from some kind of command??

Yes.? I will share one of your favorite diagrams:



It is the sbitx app that decides to read audio in from the 'right in' channel of the codec and write sound to the 'left out' of the codec.

These paths are hard-wired to the speaker and mic.??

It is a "simple matter of software" for the code to chose devices, perhaps with some conversion of data formats, but not difficult to accomplish.

A bit of device discovery/configuration/naming code is needed to make this relatively easy for the user to chose their favorite sources/sinks.

I would love to ideally route the mic and speaker to a bluetooth headset or some rtp stream or the default speaker/mic.

ALSA supports Bluetooth directly via plug-in modules.

The easiest way (IMO) to do RTP streaming is to use PulseAudio in Debian 10/11 and PipeWire in Debian 12.

I have done manual setups for using RTP streams using Pulse in Debian 11 with the "quisk" app driving the Hermes-Lite 2 SDR.

It more or less happens automatically if you use ssh with x-windows tunneling enabled, but you may need to set some environment variables to get things to work the way you want.

There are other/better approaches to streaming audio over a wide area network, but this approach works well on a local area network.

As Paul is finding, there is a bunch of digging one needs to do, but pretty much everything is there, it's just a matter of figuring out the best way to access it.
?
--
Regards,
Dave, N1AI

Hi Dave,

I agree that solving the root problem is a much better solution if it is incorporated into the main code. ?It becomes difficult if the modifications need to be done every time you want to update.?

I do not feel that you are picking on me. ?I am always open for new information and the opportunity to learn

Thank you for the feedback and the work you are doing on the sbitx.?

73
Evan
AC9TU

Ashok,

Might think about putting a potentiometer in line to vary the output. This might have the possiblities of over driving the internal amp of the ubitx.Would be a neat project to have a separate screen to monitor the outputs ,in the same cabinet. run by a separate arduino ? might be a very stupid suggestion, but if it could be done you would have a built in modulation monitor with ur ubitx for SSB . I bet Someone could whip up something for that. Maybe even have the amp level controlled via the arduino? via another tft screen?

just throwing out stupid suggestions.

73
David
ac9xh

Ashok,


Where does one purchase this item. if it has compression capabilities thats a benefit.

73
David
ac9xh

On Sun, Feb 4, 2024 at 03:32 AM, Paul wrote:

initial signs look positive

You are definitely getting to the heart of the issue.?

The issue now is that the sbitx application is still relying on the codec to be at index 0, loopback to be at 1, loopback_1 to be at 2.

That's because it opens the ALSA devices using names based on their index, i.e. "plughw:0,0", "plughw:1,0", "plughw:2,1".

It's better if the app uses names that are not based on index.

You are heading down the path of still making sure codec is 0, loopback is 1, loopback_1 is 2, etc.

You're changes are helping make that happen and at the same time giving them better names.

I'm not that confident that you can be sure to get the right index in every use case of things plugged into the Pi.

For instance HDMI audio is started very early in the boot process so if it is enabled then it probably gets index 0.

I think it's better to just not rely on the index and to have the sbitx app use the right name to find the right device regardless of index.

That's why I recommended:
Go into sbitx.c and change?"plughw:0,0" to?"plughw:CARD=audioinjectorpi,DEV=0".
Go into sbitx_sound.c and change?"plughw:1,0" to?"plughw:CARD=Loopback,DEV=0".
Go into sbitx_sound.c and change?"plughw:2,1" to?"plughw:CARD=Loopback_1,DEV=1".

These are the default names.

Your approach is an improvement because it assigns better names for the loopback devices.

In turn this will make the documentation easier to write and understand, IMO.

If we can assign a better name to the codec instead of "audioinjectorpi" then it too could be found by that name instead of "audioinjectorpi".

On the other hand, some may say that this adds more complexity to /boot/config.txt and /etc/rc.local and makes it harder for "tinkerers" to understand what is going on because we're not using the default (standard?) names.

Also it makes it more difficult for others to get the sbitx code by doing "./update", they also must change /etc/rc.local and /boot/config.txt to get the better names to be present.? We know many here aren't going to want to have to do that.?

So, I think you are definitely getting to the heart of the matter, but may just want to try changing the code the way I suggest and seeing if it works with the default/standard names so that complexity is avoided.? If it works, the code can be merged then ./update will still work.

Just use a simple editor (nano?) to change those three places to use the names I suggest, then do:

cd $HOME
./build sbitx

and see if it still works.

--
Regards,
Dave, N1AI

On Sun, Feb 4, 2024 at 02:42 AM, Paul wrote:

If you are able to identify the HDMI interface and set its priority as I did for the USB ports then at least you can prevent clashes with the loopback interfaces.

I agree.

The one bit I probably haven’t quite answered is the naming of the loopback interfaces, though I think looking at the alsa modules config might be the starting point.?

This bit of config would be the same regardless of the codebase as it is core sound config from a naming perspective, though that would have an impact on the code as references to the loopbacks would then have to be updated to reflect the new device names.

I am now at the point where I need to understand the code architecture at a higher level to see how the code modules (assuming its modular) interact with each other.?

While Ashar pointed me at the mixer section of the sbitx.sound.c code, it is called by something else that passes the device names, hence me needing to understand the code at an architectural/flow level before digging in. Maybe in doing so we can get to device naming at the same time.?

I am confident that I am showing the exact lines of code that set the device names in this post.

Look for the highlighted "plughw" strings in three places in that post.

These are the three device names being used by sbitx to access the codec and the two loopback devices.

They are being set by the functions that start the sound handling threads.

This is also why I say they are running even when no one is listening, the code for the devices are being started unconditionally.

And I am giving the names that I think should work and will not depend on boot order:
Go into sbitx.c and change?"plughw:0,0" to?"plughw:CARD=audioinjectorpi,DEV=0".
Go into sbitx_sound.c and change?"plughw:1,0" to?"plughw:CARD=Loopback,DEV=0".
Go into sbitx_sound.c and change?"plughw:2,1" to?"plughw:CARD=Loopback_1,DEV=1".

From what I can tell in the code Ashar refers to the aplay -l (or -L) command to get device names, what I don’t see is how this is done and its not in the sbitx.sound.c code.

ALSA config will be the source of naming of devices but on reflection maybe the loopbacks could be individually named in the /etc/rc.local file instead of using the combined name of snd-aloop for all devices, try creating a line for each loopback e.g.

?

modprobe sbitx-digi-out enable=1 index=1

modprobe sbitx-digi-in enable=1 index=2

?

Instead of

?

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

?

I suspect this is where /proc/asound/modules gets the loopback names from, do cat /proc/asound/modules to see what I mean.

I think that's not going to work.?

'modprobe' loads LKMs (loadable kernel modules) into the kernel.

So 'snd-aloop' is the name of a module ( snd-aloop.ko ) that provides support for the loopback devices.

I think changing the names this way will not work.
?
--
Regards,
Dave, N1AI

On Sun, Feb 4, 2024 at 06:14 AM, Evan Hand wrote:

You can disable the HDMI audio in the config.text file in the boot folder. ?I am laid up and can not get to my computer to look up the specific line to add the “,noaudio” to the end of the dev= line and do not remember the driver that the video is using.?

I hope no one thinks I'm picking on you.? I admire your many helpful posts here.? I hope you are feeling better soon.?

However, the point I am making is it should not be necessary to disable HDMI speakers, USB headsets, or the on-board headphone jack either, if just three lines of code in the sbitx application are changed.

IMO, we should be asking the question "how can I use other audio devices" instead of "how do we turn off other audio devices".

This is really relevant to those of us who have the board-only option and want to use the Pi in sbitx for many different things instead of it just being an embedded radio dsp/gui device.

And, for Paul, he wants to use his USB headset without having to take it out every time he reboots.

These are sensible goals, no?

I admire Paul's work.? He already has a deeper understanding of the situation than I do.

I don't really care which exact approach is taken.??

And in the case of Paul's work, maybe a better understanding of Linux's audio options will lead to everyone being able to use USB headsets and other USB-attached sound devices, perhaps Bluetooth as well.

Unfortunately for me it's bad timing for me to dig deeper into this space, all I can do is keep trying to get people to focus on what I think the goal should be.
?
--
Regards,
Dave, N1AI

Thanks Rafael, ?that is the line in config.txt.?

73
Evan
AC9TU

Hi all,

I want to use the MAX9814 microphone amp to improve the low SSB power O/P in uBitx.
It have compression capability also.


Many have used MAX9812, but MAX9812 is not available so I want to use MAX9814. Ned suggestions for the wiring to uBitx.

Regards
Ashok VU3KFK

dtoverlay=vc4-kms-v3d,noaudio

You can disable the HDMI audio in the config.text file in the boot folder. ?I am laid up and can not get to my computer to look up the specific line to add the “,noaudio” to the end of the dev= line and do not remember the driver that the video is using.?

If you post the contents of config.txt I can tell you the link to modify. ? A search for noaudio in the group may also work

73
Evan
AC9TU