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

Actually had a bit of a google after I wrote the reply, this may be more help:?
snd-aloop is a module so the key is to change the id associated with it to? make it more identifiable, will still need a line for each loopback along the lines of :

Ok I did a test, I want to know the answer to this too, NOTE - I haven't run the sbitx app yet with these changes, it might not work from that point of view but answers the device naming question I think.
I tried two changes:

• ?sudo nano /etc/modprobe.d/alsa-base.conf
• options (efault) index=-2
  options snd-aloop index=1 id=sbitx-digi-out
  options snd_usb_audio index=5

This resulted in no change to the output from?cat /proc/asound/modules
pi@sbitx:~ $

the output from p
i@sbitx:~ $ cat /proc/asound/cards
?0 [audioinjectorpi]: audioinjector-p - audioinjector-pi-soundcard
? ? ? ? ? ? ? ? ? ? ? audioinjector-pi-soundcard
?1 [sbitxdigiout? ?]: Loopback - Loopback
? ? ? ? ? ? ? ? ? ? ? Loopback 1
I trimmed the rest as there was no change.
The next test was updating /etc/rc.local as I suggested as a possible option earlier:
pi@sbitx:~ $ sudo nano /etc/rc.local

开云体育

Hi Dave

开云体育

开云体育

开云体育

Dave, I'm sorry I appear to have upset you - in the context of this mail list, I asserted that it would require a significant effort to use a $100ish N100 system in a uBitx, and you agree with me, as best I understand your responses.

Referring to:?

Since my other comments on other issues have gone unanswered, I will try to discuss this here.

A screenshot of part of the issue:

I've talked about this a few times in this group:

/g/BITX20/message/108542? -- you don't have to rely on order of discovery if you use proper names

/g/BITX20/message/108485? -- stop using numbers, start using names

A fix is IMO pretty easy:
Create and use a new git branch so sending a PR is easier ('git checkout -b sbitx-alsa-names' will do this)
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".

--
Regards,
Dave, N1AI

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??is the best version to use these days.
It comes from the openwebrx project which is a heavy user of csdr.

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.

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.
?
--
Regards,
Dave, N1AI

On Sat, Feb 3, 2024 at 04:46 PM, Ken N2VIP wrote:

On Feb 3, 2024, at 14:43, Dave, N1AI <n1ai@...> wrote:

The point I was trying to make is that Upton's tiny desktop concept risks getting buried by N100 or similar systems.

My point was they were designed for different use cases.

You wrote "his goal was a $100ish desktop?that required a TV for output that could be used in education for third-world students using phone chargers, cheap keyboards/mice, etc." -- how is that use case different from what you can do with a $100-ish N100???

Then consider the N100 can run far more software natively and is more expandable so quite possibly a better purchase than a Pi 5 desktop.

?

Overall IMO this, and the newly-announced IPO, will put pressure on Upton and team to crank up the innovation.

RPi Foundation has been building selling *huge* numbers of boards for embedded applications to industrial customers. I haven't heard about an IPO, but I suspect it will allow RPi Foundation to focus on educational issues and applications and the spin-off commercial organization can focus on industrial issues and applications, as well as (I imagine) help sponsor RPi Foundation.

N.B. Your linked-to alternative is priced at $279, more than 3x the cost of an 8 Gig RPi 5...

I guess you just aren't following along, because I just wrote "It's a bit pricier now, but overall it seems quite possible that an Intel variant could take away a lot of Pi's lunch money sooner or later", and earlier in this thread (?here ) I wrote "Jeff is right that the Pi world requires you to select, purchase and assemble more 'stuff' to get a useful setup whereas most SFF PCs come with all the stuff you need right out of the box" and provided links to Jeff's video which shows if you price out all the stuff you need to buy to use a Pi 5 in a desktop configuration then you spend a lot more than the $85 or so that a raw Pi 5 8GB costs.? Want power?? More money!? Want a fan?? More money!? Want a case?? More money!? Want storage faster than a micro sd card?? More money!

I get it, Pi excels at embedded applications, but hfsignals.com sells board-only setups and ones in cases, and most of the board-only units seem to stay in people's shacks, from what I read on this forum.? I own one of each and my board-only unit is probably never going into a case.? I might have considered interfacing it to something other than a Pi, but the mechanical design pretty much rules that out in the near term.

?
--
Regards,
Dave, N1AI

Thanks for all the answers. Does it makes sense to use a dc blocking filter to mic and radio rx paths? I'm playing with csdr [1] and it is pretty cool. Just to be sure - it makes no sense to add this DC component to tx / speaker paths, right?

[1]

- Rafael