rec audio clicking/chopping on peaks

[ct1iqi]

@n1gp
tnx for feedback. I don't understand your 'do it from a VNC connection'.
All my reports are about pihpsdr running in CM4' Linux OS. How I start pihpsdr makes no difference; have done so via ssh as a console command, or using VNC to select the application menu item 'pihpsdr' from a window on another PC, that replicates G2's screen. But in all cases pihpsdr runs in G2's CM4.
VNC is just bringing the desktop, as shown on G2' s local screen, to another PC. On the audio break-ups it has no effect. When I stop the PC's VNC client, CPU load on the CM4 goes down since its VNC server has no work to do, but it does not remedy the audio problem.
The max CPU freq reported here is indeed 2000000.

[n1gp]

For more context, I had said, 'But, then I decide to do it from a VNC connection.'

By which I mean that previously I had the HDMI cable plugged into the back in HDMI1
and using a USB Mouse and Keyboard plugged into the back USB connector.
My Pi desktop was in my HDMI monitor and I started a terminal and then started pihpsdr.
Everything running on the CM4, not just pihpsdr.

'But, then I decide to do it from a VNC connection.' Yes, the pihpsdr is still running on the
CM4 but part of the GUI is now running on a seperate PC. In THIS mode I start seeing/hearing
the audio glitches you are talking about. Very much different FOR ME.

Am I to interpret that you have done the same and it makes NO difference on the audio glitches?

BTW, I tried as you did, while the VNC client was running and getting glitches, to kill the client.
Yes, pihpsdr still is running and I hear glitches. Yet, the vncserver still is running and has a desktop
with pihpsdr running. Try killing the vncserver and of course pihpsdr now stops.
Now try running without VNC, only on the ANAN-G2 with HDMI1 GUI. I get no audio glitches until
sample rate is > 384k.

[rbanasik]

I have been dealing with stuttering and breakup issues since receiving the G2 and using Thetis 2.10.1 with an i7NUC directly connected to the Anan. I've throttled down speed to 192,000 and that helps reduce load but does not completely fix the problem. I've heard others are also experiencing similar issues with their G2s, but I've not heard of anyone solving this yet. It also happens using the front panel controls on the rig.
I've heard mention of new firmware for the Anan Saturn board. Thoughts anyone? -- Bob - Ki1n

[Trucker]

Rob,I received an email from another G2 Saturn owner with the front panel today and he told me that Apache labs, either through Doug or another person, is sending him a new SD card for his radio that should solve the audio problem you and others are experiencing. I would suggest you contact Doug to find out what the details are and see if they will send you the new card with updated software etc.
You will have to open up the radio to install the new card. But, beyond that, I don't know any other details about the installation process.
James
WD5GWY

[rbanasik]

Rob,I received an email from another G2 Saturn owner with the front panel today and he told me that Apache labs, either through Doug or another person, is sending him a new SD card for his radio that should solve the audio problem you and others are experiencing. I would suggest you contact Doug to find out what the details are and see if they will send you the new card with updated software etc.
You will have to open up the radio to install the new card. But, beyond that, I don't know any other details about the installation process.
James
WD5GWY

Hi James.
That sounds great. Do you have any contact info for Doug, or is he at Apache Labs?
-- Bob - Ki1n

[ct1iqi]

@n1gp
tnx. It seems we have a different perception of how VNC works.
I think in essence the vncserver, started under systemctl as vncserver-x11-serviced.service, only allows a remote VNC client to produce a copy of the local screen on a remote screen, and feed the remote mouse/keyboard back to the local application as if they were local. So embedded pihpsdr is not 'aware' of y/n vnc; it just keeps doing what it is doing, regardless of VNC active.

Anyway, to make sure, while listening in USB to the carrier of some strong AM station, issued
systemctl stop vncserver-x11-serviced.service ,
and its start equivalent. This stops and starts the vncserver. It makes no difference on the little hick-ups one hears in the audio on the headphone.
Connected to the G2 are a 7" HDMI screen, a wireless mouse, a midi DJ unit for tuning, and the headphones. So really a stand-alone transceiver that way. Started pihpsdr on the CM4 by connecting over ssh and issuing the command
export DISPLAY=:0 && cd ~ && /usr/local/bin/pihpsdr &
This tells pihpsdr where to send its graphics, changes to pi's home folder, and starts pihpsdr, which is in its very latest version.

@192k 1 rx, the CM4 CPU load reported for pihpsdr ~100%, X11 ~25%
With the vncserver active but idle no consuming processes are shown. With a client connected vncserver-x11-c appears with ~90% CPU load.
Indeed the chopping gets worse with a client connected, but it does not completely disappear when the client connection is stopped.
Perhaps there is an issue in how the various threads get distributed over the 4 CPUs and indeed a momentary shortage of CPU cycles .

[Trucker]

On the Apache Labs main website there is a contact Customer Service link that should put you in touch with him.
James
WD5GWY

support@apache-labs.com

[rbanasik]

On the Apache Labs main website there is a contact Customer Service link that should put you in touch with him.
James
WD5GWY

support@apache-labs.com

Thanks James. I'll be sure to contact them!
-- Bob - Ki1n

[rbanasik]

The codec is connected to the FPGA; it receives (and generates) samples at 48KHz synchronously to the ADC & DAC. Audio samples are transferred via the Raspberry pi, but it is not interfaced to the operating system so you cannot send WAV files to it. That's why you see no audio device listed.

When you get the chopping noise, what RX sample rate are you using? The raspberry pi will not be able to execute piHPSDR at 1536KHz; a PC, on the other hand, can execute DSP software at that rate. I would guess the single RX sample rate limit for local processing might be somewhere between 192 & 384KHz; and if you have two receivers operating, you might well have to halve that rate.

In my experiences lowering the sample rate to 192K helped somewhat but did not eliminate the issue. I still experience stuttering on both Xmit and Receive. I heard in another thread that Doug or someone was able to send an SD card with a solution to another user who was experiencing this problem. Is that true? Could someone from ApacheLabs offer a fix for this problem to the rest of us? -- Bob - Ki1n

[w-u-2-o]

I merged the other, similar topic into this one.

With regard to the SD card fix, is this to update software or are the cards physically bad?

[ct1iqi]

Does Apache Labs have a site from where one can download a new SD card image?
Or a patch file to apply to the current card image.

Some more measurements.
2 RX @768k gives much breaking up of the audio. mpstat shows for the 4 CPUs:
09:04:15 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
09:04:15 AM all 30.32 0.00 9.31 0.81 0.00 0.03 0.00 0.00 0.00 59.53
09:04:15 AM 0 30.57 0.00 13.55 1.00 0.00 0.07 0.00 0.00 0.00 54.81
09:04:15 AM 1 31.93 0.00 7.44 0.61 0.00 0.02 0.00 0.00 0.00 60.00
09:04:15 AM 2 29.66 0.00 8.46 0.65 0.00 0.03 0.00 0.00 0.00 61.19
09:04:15 AM 3 29.11 0.00 7.96 0.98 0.00 0.01 0.00 0.00 0.00 61.94

So all have still some headroom.

[Trucker]

I merged the other, similar topic into this one.

With regard to the SD card fix, is this to update software or are the cards physically bad?

Scott,
I apologize for not responding sooner. I have been trying to find the email I received regarding the replacement SD card that I mentioned earlier. For whatever reason, I cannot locate it. I don't believe I deleted it. But, at my age,anything is possible!
If I do find it, I will email the author and ask him to post the information here. As it is, I would disregard my comment concerning a replacement SD card. I do know that it wasn't because the SD card was defective. But, was because the person that emailed me, had problems with using the Command line to download and compile updates to the radio that he said was supposed to fix the clicking audio problem.
I will refrain from sharing things like this until I can better verify what I am being told.
Sorry for the confusion.
James
WD5GWY

[K6JR]

Well it has been 2 months that I have had the G2 with display and bad receive audio. Support, Tony and Doug are aware of the problem but I have heard nothing in regards to fixing it. The sounds of crickets on here also. I'm about to ask for a refund. I'll continue to use my other Anans that work correctly. Buyer beware if you are going to order a G2 with display, the stand alone receive audio is unacceptable.

[rbanasik]

Well it has been 2 months that I have had the G2 with display and bad receive audio. Support, Tony and Doug are aware of the problem but I have heard nothing in regards to fixing it. The sounds of crickets on here also. I'm about to ask for a refund. I'll continue to use my other Anans that work correctly. Buyer beware if you are going to order a G2 with display, the stand alone receive audio is unacceptable.

I'm not sure if my situation could be related, but FWIW, I had significant Xmit audio stuttering or clipping and on receive I had frequent distortions. Reflashing the firmware on the Saturn board and updating the PiSDR seemed to remedy most of the issues. Some transient audio clips on xmit remain as well as occasional distortions on Rx, but the situation is 95% improved.
Hope this helps.
-- Bob - Ki1n

[K6JR]

Thanks Bob. I also upgraded the Pi and P2 and it is still not right. Tony says they are working on it but it has been a while since anything has been said as to whether or not they are making progress.
73, Jim K6JR

[rbanasik]

Thanks Bob. I also upgraded the Pi and P2 and it is still not right. Tony says they are working on it but it has been a while since anything has been said as to whether or not they are making progress.
73, Jim K6JR

Well, obviously these new units are a work in progress. That's ok but I sure look forward to clearing up a couple of these glitches. In the meantime, though, I sure am having fun with all the capabilities of the G2—overall it's a great rig!
-- Bob - Ki1n

[administrator]

Jim,

What sampling rate are you using?

I would suggest 48KHz to see if that helps.

Tony

Thanks Bob. I also upgraded the Pi and P2 and it is still not right. Tony says they are working on it but it has been a while since anything has been said as to whether or not they are making progress.
73, Jim K6JR

[K6JR]

Hello Tony. Yep, 48 is better but still not good. There are at least 5 of us with the G2 display that are all having the same problem.
73, JR

[administrator]

Hi Jim,

Thanks.

I believe this is not an issue with the hardware for several reasons:

1. Protocol 2 on the G2 with Thetis have no issues, a couple of users had reported sequence errors but that was setup related. So data transfer using the CM4 seems to be working well.
2. The CM4 CPU usage is not very high when running PiHPSDR so it also does not seem to be a case of the hardware maxing out.

Have you made any updates/changes to the G2 Linux image? are you running any additional programs along with PiHPSDR? if so what CPU usage do you see?

Maybe one experiment that you can do to see if this is being caused by the XDMA transfer:

1. Power up the G2
2. Exit PiHPSDR
3. Launch the P2app
4. Go to github/pihpsdr and manually launch pihpsdr
5. you will then see an option of starting PiHPSDR with XDMA or LAN, choose the LAN option and see if you still get the audio anomalies.

Regards,

Tony

Hello Tony. Yep, 48 is better but still not good. There are at least 5 of us with the G2 display that are all having the same problem.
73, JR

[laurencebarker]

One thing that might affect piHPSDR when using XDMA connection direct to the radio hardware is: is p2app also running at the same time? I don't know why but p2app running while another application uses the audio path causes problems.

to see if it is running: type ps -ax into a console window
scroll through the listing and look for p2app in the listing. Note its process number: for example 703
then type sudo kill 703 (or whatever process number you found).

It would he helpful to know in any reports:


1. did you connect using XDMA or to an IP address
2. what sample rate are you using
3. Are you hearing pops/clicks, or distortion on peaks (which may be a different issue).

I suspect that the sample rate of 768KHz I saw reported somewhere is way too high. Start at 96KHz as a suggestion, until we make progress with this.

[rbanasik]

Jim,

What sampling rate are you using?

I would suggest 48KHz to see if that helps.

Tony

Thanks Bob. I also upgraded the Pi and P2 and it is still not right. Tony says they are working on it but it has been a while since anything has been said as to whether or not they are making progress.
73, Jim K6JR

I went back up to 768000 to challenge the rig and see if the problems were completely gone. I had rare occurrences of distortion on receive and almost no xmit clipping. I then lowered to 384000 (where I am now) to see if that would eliminate the remaining issues but that had no effect as far as I can tell. I haven't gone lower that that yet, but might go one more step.
Earlier last week before making progress with the reflash, I had tried down to 48000, that might have help somewhat but probably 75% of the problems remained. This rig should be able to operate at 1576000, so 48000 seems pretty desperate.
Let us know if you make any progress.
-- Bob - Ki1n

[administrator]

Bob,

Are you using Thetis or PiHPSDR at these sampling rates? there is no issue whatsoever running Thetis at any sampling rate. If you are getting artifacts on Thetis it is most likely a localized network/PC issue.

Tony

[ct1iqi]

as the forum thread is getting long, some info may get forgotten.
The problem is not limited to G2s with display. Mine, w.o. display, I'd also like to use stand-alone with the embedded pihpsdr doing the work. But same problem with audio.
Using the exact same pihpsdr, but compiled for my Linux PC and running there, and connected per LAN, the audio is fine.
In that case the chain is FPGA <> XDMA <> P2app_on_CM4 <> LAN <> Pihpsdr_on_PC. When you think about this, and where the cause of the problem might be, it could be inside pihpsdr in its interfacing to XDMA. That chain is much shorter: FPGA <> XDMA <> Pihpsdr, but it has the audio problem.
It could also be caused by the wdsp library. Running on an Intel modern multi-core CPU OK, but perhaps struggling on a quad core ARM to keep up. Wdsp is doing an immense number of double precision floating point calculations and has to keep supplying pihpsdr with audio, and taking it for transmit, in a timely manner. The ARM cores each are single thread. So multi-threading in the sense of real parallelism, is limited to 4. There can be many more threads in software in a simulated fashion, but for execution they'll have to wait for a physical one to be free.
Perhaps the maker of wdsp can help in suggesting ways to verify whether a timely completion issue exists while wdsp is at work on the CM4 platform.

[Trucker]

I am not sure if this is relevant, but when I use my V1 controller running PiHPSDR ( with my 8000DLE) which is using an older version of the Raspberry Pi, I don't experience any audio glitches. PiHPSDR in the controller is using WDSP for audio processing.
I would think the CM4 module is more powerful than the module in my v1 controller. But, then again, the Pi module in my controller is communicating with my 8000DLE over ethernet and not the PCIe interface as the CM4 does in the G2.
Maybe the clue to the problem is the fact lowering the Sample Rate lowers the occurrence of audio glitches. ( even if it doesn't get rid of them)
I am still on the fence about getting a G2 Saturn. But, if problems like this one get resolved, then that might be enough to push me into buying one.
James
WD5GWY

[KC2QMA]

As a listener of multiple anan 7000dle's running Thetis in various nets and rag chews I have been hearing this very “Clicking/Chopping” sound on some of there signals for at least a year now.
I don’t know what their setups are but Just my personal observation.

[DL8LAQ]

The piHPSDR controller V1 connected to the ANAN-G2 runs 384k samp rate without any disturbing noise on the audio signal. PIHPSDR is build 2023-09-22.

[ct1iqi]

NR0V, Warren, the author off wdsp was so kind to give some hints on how to test whether wdsp is short of CPU cycles.
With a setting with lots of audio hick-ups, the tests were negative. If it were wdsp causing problems, adding certain CPU intensive functions like noise cancellation would add to the problem.
But I did not notice that. Also, when wdsp exchanges data with pihpsdr, there is an error detection mechanism in case wdsp did not finish its processing in time. Those errors are not being thrown. So that is good news.
The problem must be in the way pihpsdr communicates with the FPGA via xdma. The xdma driver as such works fine with p2app. This points at pihpsdr doing something incorrectly in its use of that xdma interface while exchanging audio.

[rbanasik]

Bob,

Are you using Thetis or PiHPSDR at these sampling rates? there is no issue whatsoever running Thetis at any sampling rate. If you are getting artifacts on Thetis it is most likely a localized network/PC issue.

Tony

Hi Tony. Thanks for your note. Yes, I am running Thetis v2.10.1 on an i7 NUC 4.7Ghz 6 cores 12 threads w/ 800Mhz UHD graphics directly connected to the G2 via DHCP. These anomolies also appear using the G2 standalone via the control head. They have been reduced significantly since the firmware reflash but remnants of the issues still remain.
-- Bob - Ki1n