|
Error in Sound Input I got the above error message while using sbitx with an external hdmi monitor and the jtdx program. The built-in RPi4 has 4GB of memory. I've been using the device in this configuration for a few days and occasionally I get this message, which I can eliminate by restarting. My audio settings are: input: plughw:CARD=Loopback, DEV=1 mono output: plughw:CARD=Loopback_1,DEV=0 mono Maybe my audio input setting is wrong? I am sure that I have output when I have the above output settings. When the error message appears, it still works, the sound does not drop. -- Gyula HA3HZ 
|
the error message cannot be read well.  -- Gyula HA3HZ
|
I have had this error, my suspicion is that it might be rf feedback disrupting the software, it clears if I stop and restart the program especially if it has been running for sometime. Sometimes it might need a full reboot. I used it this weekend while away in our motorhome on 40m and 20m without issue running only 2w into a ground mounted Ampro mobile whip for 40m and one for 20m and I had no issues, both these antennas were tuned so no need for an atu, hence my suspicion about possible rf feedback.
Regards
Paul G0KAO
|
Paul, interesting what you say. When I started using the device in November, I started tidying up the table so that there were no wires crossing each other. There should be no ground loop, and at the same time I knocked down a 2-meter 5/4" iron pipe as grounding, which I introduced and which is connected to the device at one point at the antenna output.
Then I put several ferrite rings in different places, and there is also a filter on the power supply input, which was made on FT140-43 by winding the input wire bifilarly. So I rule it out, although I've never checked with tinySA for this kind of confusion.
I was thinking of emptying the cache from time to time, but I don't know how to make this automatic. Could this be the reason for the message at all? I tried to start with gdb, but the error comes from jtdx. Therefore, I do not know how it could be examined in this way.
--
Gyula HA3HZ
|
Gyula,
Try running htop in a terminal window to see if the Raspberry Pi is hitting its processing limits.? I have found that an external HDMI monitor adds significant load onto the RPi4.? This was improved in the 3.0 updates.? I have not tried running an external program like JTDX to determine the generated load.
73
Evan
AC9TU
|
Evan, thanks for the suggestion.
Until the last few days, I used only the basic device.
Due to the complex callsigns I was forced to use external screen and jtdx.
I haven't had a similar message so far, but I will test it.
This message appears after about an hour of use.
--
Gyula HA3HZ
|
Gyula,
I have monitored both my DE and V3 sbitx and found that a process builds up and, after a few minutes, will peak one of the processors to 100% and then reset and starts building again.? As far as I know, sbitx is single-threaded, and if the JTDX call for data happens simultaneously as the sbitx process peaks, there may be a starved data condition.? It may be hard to see the condition when it occurs as the process will return to a low load condition right after the peak.? There may be a way to capture the timing of a file, though I have not tried that.
I noted that you have screen area available to run the htop terminal while running the radio.
The program top is an alternate to htop.? Both have web pages with installation and use pages.
73
Evan
AC9TU
|
Evan,
i did several tests today but i can't determine the cause. I tried removing the grounding, the error message still appears. It comes later when using wsjt-x. With jtdx, twice as many stations are visible during decoding and the message appears after 40-50 minutes. When it appears and I click OK, the message appears again when switching from reception to transmission or from transmission to reception. The message appears, but there is no change in the sound. In the case of jtdx, when loading and decoding the program, the cpu usage reaches 250% (the percentages of the 4 core threads are added). With wsjtx you don't get such a high cpu %.
By definition, it decodes far fewer stations.
I don't see a solution for the time being.
--
Gyula HA3HZ
|
Gyula,
Can you post a screenshot of htop after 10 or so minutes of run time?? Also, can you confirm that one of the processors peaks out to 100%???
It seems to be a buffer underrun.? Not sure of the root cause.
Hopefully, others in the group can offer suggestions.
73
Evan
AC9TU
|
Evan, I am attaching the pictures. I made a lot more, but since the external hdmi and sdi are in one picture, each picture is 2MB in size, so I converted some of them. These were made under jtdx-- Gyula HA3HZ 
|
Gyula,
I am not the expert, but it looks to me like there is a performance issue.? The sbitx program seems to be cycling through the low to high CPU usage.? At the same time, JTDX uses a lot of CPU.? Does JTDX have the ability not to do a deep decode or some other process to limit processor needs?
73
Evan
AC9TU
|
I don't think I have had the error since I upgraded the PI to an 8GB version and the OS to 64-bit, will need to test further because I think when I last had the error I was using it via VNC from the laptop. I used it for quite a while on Saturday on 40m and 20m without a problem using just the sbitx. On reflection it could be a resource/process issue, the error is reporting that audio is not being processed fast enough and when I had the problem it always appeared to be when transmitting, hence my thoughts about rf feedback as a potential cause. I haven't spent any real time investigating as my focus has been on the SSB side of things Regards Paul G0KAO
On Tue, 27 Feb 2024 at 19:10, Evan Hand < elhandjr@...> wrote: Gyula,
I am not the expert, but it looks to me like there is a performance issue.? The sbitx program seems to be cycling through the low to high CPU usage.? At the same time, JTDX uses a lot of CPU.? Does JTDX have the ability not to do a deep decode or some other process to limit processor needs?
73
Evan
AC9TU
|
Interesting error.
I have run WSJT-X,? WSJT-Z? and JTDX with an ext hdmi monitor for several months with no issues. My pi4 is a 4gig version My sbitx - v2
Wondering if it is V3 causing the issue.
I recently sold my unit so can't test With V3.
Joe VE1BWV?
On Thu, Feb 29, 2024, 3:32?a.m. HA3HZ < gyula@...> wrote: I'll tell you what I came up with.
I read the discussions about this on the Internet on various forums and websites. Where the solution was mostly interference protection of the wire between the PC and the radio.
Here, the solution is more difficult because it is a construction and it is more difficult to trace the path of the signals. (since there is no pcb schematic).
However, I managed to achieve something. Which may also depend on the spread. I use the device with this setup at 14 MHz, where my antenna has 1.05 swr.
The error message says 'Sound data is not being transferred to the audio input device fast enough'.
From this I drew the conclusion that too much data wants to enter the input. I looked at the jtdx menu settings and it is set to the most insensitive.
That's why I took a look at the RPi Alsa sound control panel.
The question is not simple, because there are several possible statements.
I need to find the adjustment option for the reception to reduce it. I noticed that the setting values are fixed in the program, it always jumps there when broadcasting.
However, it allows you to take it smaller.
I took advantage of this and started setting it lower. It happens that the program hangs and in this case restarting jtdx helps.
I turned it on in the evening and the error message did not appear. At the same time, we also managed to collect nice dx's.
So I've made it this far.
I'd love to hear if anyone has any comments or further insights.
--
Gyula HA3HZ
|
I could not eliminate the cause of the error message.
When the number of stations in the band is low, the message does not appear. The RPi 4B has 4GB of memory and htop shows that almost all 4 cores work at 100% during decoding, but there is no additional memory usage beyond 318MB. There is only a significant change in the use of the cores. When there are many stations in the band, the decoding naturally takes longer (in my case it happened for 5 seconds), so I set the AUTOSEQ setting to 'Call based on end of decoding'.
The various forum discussions and websites with this topic always talk about the separate PC and separate radio, where they try to eliminate the presence of rfi.
In our case, this is difficult to check because everything is built into one.
If you live in a less densely populated area and use the radio, you will probably not experience this error message.
--
Gyula HA3HZ
|
Hello,
I'll tell you what I found by debugging the 'Error in SoundInput' message. I visited several forums where this was discussed, but the only possible solution was RF interference filtering.
For me, who uses an integrated Rpi and radio, this was not an option.
Over the weekend, fellow amateur W9JES posted the sBitx control installed on Bookworm (Debian 12). Unlike Buster 32-bit, Bookworm 64-bit uses Pipewire, not Alsa, for audio processing. If you read the Bookworm demo where Alsa is described as a rudimentary simple audio manager, then Pipewire is a better option.
So I have been using this since yesterday and the above error message did not occur. The jtdx_improved version ran all day.
An important note: the reception level of the jtdx should not be higher than 30-40dB. If it's higher, you can overdrive the input.
I use the same hardware as before, only instead of Buster (Debian 10) 32-bit, I run Bookworm (Debian 12) 64-bit OS. It's much faster, because now I'm not loading from the sd card, but from a USB-3.1 stick. And the time synchronization is NTPsec instead of NTP, which finds synchronization within 10 seconds. In contrast to the previous 1.5-2 minutes, I waited for synchronization.
So go ahead Bookworm.
--
Gyula HA3HZ
|
  -- Gyula HA3HZ
|
On Tue, Mar 5, 2024 at 12:11 AM, HA3HZ wrote:
Bookworm 64-bit uses Pipewire, not Alsa, for audio processing.
Hi Gyula,? where are you adjusting the audio levels for JTDX?? I tried Pulseaudio and alsamixer, but could not get the output audio to increase. For now, the sbitx does not have an ALC meter, so it is not easy to know the best audio level.? So, I did a test today with JJ's 64bit Bookworm, and the sbitx version of FT8 was driving at 8w, while JS8Call was only achieving 3w at the same sbitx "drive level", suggesting to me that the audio was low. The power measurements were taken from the MFJ ATU.? Both modes were on 20M. As you understand, FT8 and the other FSK modes (JS8 is my favorite mode) need to be well modulated by the audio output for it to be successfully decoded at "the other end". REF:?? -- Pete VK3PYE
|
Peter,
In the pictures above, you can see that I set the sound level coming out of the radio on the sbitx gtk screen that controls the radio, and that sound level goes into the jtdx as the reception level. I didn't go into the sound control panel.
So, I reduced the IF and AUDIO (Volume) levels of the radio so that the received sound level of the jtdx input signal is no higher than 30-40dB. This can be read on the level meter in the lower right corner of the jtdx.
Yes, the most important change in our case is that the audio handling system does not collapse because the amount of data cannot fit during decoding.
And in the case of Debian 12, Bookworm, we can thank the Pipewire sound system.
It is worth where the system is presented and the changes are described.
--
Gyula HA3HZ
|
ps.: Yes, I see you are asking about the broadcast side.
When I started to look for the cause of this error, I found that the sound control panel was also open during transmission and the sound level jumped to a fixed value during transmission. From this I concluded that this level receives control from the program. I don't have a problem with this, because in at ft8 and ft4 modes, if there is no qsb or another station is not installed on my transmission frequency, then the QSO is done with a single transmission and reception.
--
Gyula HA3HZ
|
On Tue, Mar 5, 2024 at 07:11 PM, HA3HZ wrote:
I see you are asking about the broadcast side
Yes, the transmit cycle.? Thank you for your feedback on this.? I have not tried JTDX on the sbitx as yet, I do use it on my desktop PC with an IC-7300.? So the next test I need to do, will be to check to see if JTDX is also giving a lower power output compared to the gtk FT8, when both are at the same Drive Level.? Both JTDX and JS8Call are using the same audio input/output pairs, so they should be giving out the same power. More testing and "poking at" to come ... "the plot thickens" ...? -- Pete VK3PYE
|
HA3HZ
Peter VK3PYE