开云体育

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

Are you sure you can do I2S through some GPIO pins? Otherwise it would not work as Pi replacement for the sBitx.

- Rafael

Hi Dave,

On 2/3/24 23:29, Dave, N1AI wrote:

On Sat, Feb 3, 2024 at 05:35 PM, Rafael Diniz wrote:

I'm playing with csdr [1] and it is pretty cool.
[1]

*Aside #1:* I found it difficult to get that version of csdr to build on newer systems.
Also as it says when you load the page, that version hasn't been maintained since 2020
I found the best version to use these days.
*It comes from* *the openwebrx project which is a heavy user of csdr.*

There are some old CFLAGS. I made a fork and fixed the Makefile to have sane intel and arm parameters:

They also publish Python wrappers,
According to a video I watched, pycsdr makes it pretty easy to put together DSP piplelines.
Probably more efficient than using bash, because unix/linux pipes are inefficient.
I haven't tried coding to pysdr yet, though.

*Aside #2:* I now have a Hermes Lite 2 feeding 8 streams of data to a dedicated Pi5 doing FT8 decoding.
That Pi5 is running openwebrx headless, it's pretty easy to manage.
If you look for spots from n1ai on pskreporter.info you will see what I'm harvesting.

Openwebrx would run well in the sBitx, I'll install here to play with.

Just to be sure - it makes no sense to add this DC component to tx
/ speaker paths, right?

[1]

Personally I would say it doesn't make sense.
I can't explain why it is happening.
Someone who is better with schematics and data sheets than I am should look into it, IMO.

That is my feeling too.

Cheers,
Rafael

Paul,
Your perseverance on this topic is very sympathetic and I hope you can fulfill your original idea.
This is how you can get from "PlughW: 1.0" and "Plughw: 2.1" to [Sbitxdigiout] and [Sbitxdigiin].
The latter are more understandable to users.
This is where teamwork can be seen, where everyone adds their own knowledge to achieve a common goal.
--
Gyula HA3HZ