rec audio clicking/chopping on peaks

[K6JR]

I have the G2 with knobs. The PiPHSDR rec audio Clicks and chops on peaks. The rec audio sounds fine on thetis. Tony said to upgrade the Pi and thetis which I did. There was no change in the choppy rec audio. The balanced tx audio works great now. I lowered the sample rate to 48000 and that helped but didn't get rid of the problem. Any ideas?
Tnx, Jim K6JR

[TonyBlight]

I have the G2 with knobs. The PiPHSDR rec audio Clicks and chops on peaks. The rec audio sounds fine on thetis. Tony said to upgrade the Pi and thetis which I did. There was no change in the choppy rec audio. The balanced tx audio works great now. I lowered the sample rate to 48000 and that helped but didn't get rid of the problem. Any ideas?
Tnx, Jim K6JR

What in the menu gets you to PiPHSDR rec audio.Support mention the G2 with knobs have not the record play back function.

[dl4zbg]

I suppose, rec should mean "Received" and not "Recorded".

I am suffering from the same. Audio on Thetis is great, but whith piHPSDR you hear clicking ONLY WHEN SIGNAL is present.

73

Volker

[K6JR]

Sorry. rec is received audio. I had contact with another g2 owner with knobs and he also has the choppy received audio when running piHpsdr. I bet they are all that way but haven't received any suggestions as to what to do about it. I have been in contact with Tony from support and Doug at the US repair center. I will contact Tony again now that we have 3 confirmed cases of the choppy receive audio.

[w-u-2-o]

Is this audio coming from the CODEC output on the G2, i.e. the audio output of the Orion SDR board? It must be, since AFAIK there is no audio output from the Pi CM4 module.

If that's the case, then there's nothing Apache can do about this. It most probably reflects a problem in the piHPSDR code, since the firmware, drivers and p2app middleware are all well behaved with Thetis. If this is correct then it's up to a developer to perform a fix to piHPSDR.

[ct1iqi]

@wu2o
disagree with the separation line you draw in responsibilities. The G2 is now sold as a self-contained unit that, using an embedded pihpsdr, acts as a stand-alone transceiver, not in need of any external signal processing. Hook it up to some speakers, a display, a microphone, and a mouse/keyboard/midi device, and you should be able to operate the g2 without signal quality issues. My G2 (recvd Sep.1 ) refused to transmit using the embedded pihpsdr and produced endless relay clicking in tx mode. With help of hams on this forum it turned out I needed to update the FPGA code. My conclusion: embedded pihpsdr was not thoroughly tested yet. So in any case would suggest new owners to update the FPGA code to the latest version. Other problem in general with declaring Thetis sort of the gold standard for a G2 being good: it is Windows only. Don't use that here, nor want to.

[w-u-2-o]

@wu2o
disagree with the separation line you draw in responsibilities.

If you mean that Apache is somehow responsible for fixing software or firmware bugs you are going to be disappointed.

For some historical background, see this topic: https://community.apache-labs.com/viewtopic.php?f=9&t=4531&p=23606

The G2 is now sold as a self-contained unit that, using an embedded pihpsdr, acts as a stand-alone transceiver, not in need of any external signal processing. Hook it up to some speakers, a display, a microphone, and a mouse/keyboard/midi device, and you should be able to operate the g2 without signal quality issues.

I can't disagree with that statement. However, the responsibility for making that happen is and has always been divided. Apache delivers hardware and does us all the favor of supporting the open source developers and preloading their open source software and firmware. Volunteer, unpaid, not-employed-by-Apache, hobbyist developers create the open source firmware, middleware and software out of their love for the project and the hobby. They add features they think are important, fix bugs they think are important, and work at their own pace on their own time. This is not to say that the community, and Apache, can't lobby them for features and fixes, but Apache can't force the issue, they have no real control over the developer community.

My G2 (recvd Sep.1 ) refused to transmit using the embedded pihpsdr and produced endless relay clicking in tx mode. With help of hams on this forum it turned out I needed to update the FPGA code. My conclusion: embedded pihpsdr was not thoroughly tested yet.

That's definitely true. I even expressed that concern to the developer community and Apache privately well prior to the first unit shipping. Nevertheless, together they thought it was time to ship product when they did.

Other problem in general with declaring Thetis sort of the gold standard for a G2 being good: it is Windows only. Don't use that here, nor want to.

It's not so much that Thetis is the gold standard (even if it is ), but that it provides another benchmark for testing. Since the hardware, firmware and middleware work for Thetis, that means the problem must be associated with piHPSDR. It's nice having two clients because it often allows the root cause of the problem to be narrowed down more easily.

[laurencebarker]

I look at the Thetis vs piHPSDR in this case differently: it helps to isolate where the issue may be.

Firstly, the FPGA firmware change was a trivial change that will not have affected any relays. I have never encountered the relay clicking you describe.

When you run piHPSDR you have to select the interface to the hardware. The "normal" one to run is XDMA: because that accesses the hardware directly.

Could you try running p2app (see the manual) in a console window, then connect piHPSDR to one of the ethernet addresses offered - that will use the p2app interface to the hardware. It will be interesting to see if it behaves differently.

[n1gp]

Also if you can share a video/audio of it happening, that would be helpful.

Audio settings, Filter widths, anything that isn't default.

Which audio output, or all?

[ct1iqi]

@wu2o
This G2 responsibility subject would probably deserve its own thread as it won't help solving the clicking/chopping that started this thread. Thank you for the elaborate answer. How this historically came about is clear for those involved but not for newcomers. Apache-Labs in its marketing for the G2 and in the manual describes the embedded pihpsdr as part and parcel of the product and during the ordering process never ever has made a disclaimer about the embedded software as being 'alien' to their product and not their responsibility. Also noted that there is no circuit diagram published. That does not help perfectioning the hardware-software interaction.

[w-u-2-o]

Apache will provide schematics to owners on request. Send them an email.

[K6JR]

Laurence. thanks for the suggestion. I am 400 miles from home so can't try it now. Will get to it next week. The clicking / choppy audio has nothing to do with relays. It happens on the peaks of received audio.
Tnx, 73. Jim

[ct1iqi]

Also find that the audio, that in my case is listened to via the headphone output and a headphone, is distorted at all times, and is further deteriorated by break-ups.
That is using the headphone output on the 'G2/100W/no display' back panel. The embedded pihpsdr is used, controlled via a VNC client on my PC.
The breaks, that sound like brief hick-ups, even happen at the lowest sample rate 48k and get worse towards the highest rate. 1536k is not of any use. At al times the audio sounds sharp and rough. Reducing AF gain does not change the distorted sound.
Tried whether CPU loading might be a cause; At 348k the VNC server and pihpsdr use about equal CPU capacity (using 'top' to view).
Halting the VNC link and thus releasing that CPU capacity does not have any effect on the hick-ups. Not sure though whether the pihpsdr / wdsp combi uses multi threads and the 4 CPUs available.
In any case can confirm the clicking/chopping effects. Whether only at peaks I am not sure. Also listening to white noise one hears these little breaks.

[dl4zbg]

I do confirm the observations of ct1iqi. If you are connected to a signal generator (s-meter testing) you don't hear clicks.

[ct1iqi]

notice that the chopping disappears nearly completely when activating, in the RX menu, just 1 receiver.

Is there somebody here that knows how the audio codec is interfaced to the Raspberry CM4 system?
I had the idea of testing just audio quality by playing some .wav files. But the local audio does not show up as a card in either alsa or pulseaudio.
aplay -L only yields as CARD 'vc4hdmi0', the audio related to HDMI.
When, in pacmd, issuing 'list-cards' while pihpsdr is active, the answer is '0 card(s) available'.
After having stopped pihpsdr through 'exit', list-cards gives 'name: <alsa_card.platform-fef00700.hdmi>' the hdmi audio.

[w-u-2-o]

The CM4 does not include any audio onboard. If you want CM4 audio output you would need to provision a USB audio interface of some kind.

[ct1iqi]

@wu2o
Thank you; starting to get it. Looked at the block diagrams and although they are not very consistent, it appears to be the case that the audio codec interfaces to the FPGA.
One block diagram (G2 Manual, architecture 1.2) shows both Raspberry and codec circuitry being interfaced to PCIe. In another diagram ('Saturn SDR') the codec is interfaced to the FPGA while the compute module interfaces to the FPGA via PCIe 2.0.
Not sure what the added value is of having the FPGA in between; pihdsdr could send what wdsp has cooked up straight into the codec using a standard audio driver, like pihdsdr does when choosing 'local audio', be it that now there is no local audio, other than the hdmi, because it is hidden behind the FPGA, it seems.

[laurencebarker]

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.

[K6JR]

I am using the slowest sample rate and only one receiver. Increasing the sample rate makes the choppy audio worse but lowering the sample does not get rid of the choppy audio just makes it a little better.

[ct1iqi]

@laurencebarker
tnx for the clarifications.
First a correction on my behalf, related to the relay clicks that I reported earlier. I thought that had been resolved by the FPGA update but now found that was not the case.
What causes a problem in the tx chain is the concurrent operation of embedded pihpsdr and p2app.
When both are running, and even without transmitting, you see on the mike level gauge in a 1 s. rhythm a signal coming up and going back to zero, even with no sound whatsoever in the room and into the microphone.
When transmitting the relay clicks appear.
Killing p2app stops this strange behaviour. It seems that via p2app a sort of feedback loop is created from/to embedded pihpsdr with this instability as result.

On the chopping: with 2 receivers active the chopping is present here at all sample rates and even without receiving a signal. 48k is even a bit worse than 192k. Here the chopping is almost gone with '1 receiver' selected in embedded pihpsdr. But it is still audible on the peaks of audio. With weak signals & 1 receiver setting I only hear the chopping effect at the highest sample rate.

[w-u-2-o]

Not sure what the added value is of having the FPGA in between; pihdsdr could send what wdsp has cooked up straight into the codec using a standard audio driver, like pihdsdr does when choosing 'local audio', be it that now there is no local audio, other than the hdmi, because it is hidden behind the FPGA, it seems.

I agree.

I was not involved in the community when the openHPSDR project was first started. However my understanding is that the desire to have the CODEC as part of the design, and it's location within the hardware portion of the SDR, was precipitated by two design drivers:

1. A concern that the audio hardware needed to exist within the same clock domain as the ADC and DAC. We know now that this is not necessary, of course, but it was probably considered a risk mitigation during the early days of the design evolution.

2. An esthetic desire to make the hardware component of the SDR look and feel more like a traditional radio rather than a black box.

Neither of these things is necessary and both bring with them design complexities of their own. Other designs such as the Hermes Lite 2 and the TRX Duo rely wholly on computer audio.

[Trucker]

I was under the impression that you could not run PiHPSDR and P2app at the same time. The manual states it's one or the other, not both at the same time.
Maybe, that is the source of the problem.
James
WD5GWY

[ct1iqi]

to prevent misunderstanding. The chopping is also there with only the embedded pihpsdr active. The other problem I had was an issue in tx mode with relay 'K5' clicking. That turned out to be p2app interfering with embedded pihpsdr. Had not started p2app manually but it was running because auto-started (ex-factory) with a command in /etc/xdg/lxsession/LXDE-pi/autostart. Have now commented that out.
The manual mentions the auto-start of pihpsdr in case of a unit with control panel, and of p2app for the units without. That p2app, essentially a server, has to be killed before using embedded pihpsdr is not clear. On the contrary; when you see chapter 3.4 of the manual it shows a menu of 4 choices at startup of embedded pihpsdr. But the 4 options only are there when p2app server is running .... With p2app killed only the xdma option will appear since p2app makes protocol2 communication over ethernet possible.

[ct1iqi]

G2/100W/no-display
added a virtual sink to pulseaudio and chose that as 'local audio' output in the RX menu. Pulseaudio than automatically also creates a monitor source. Have made ffmpeg use that monitor source as input and create a stream that I can listen to on my PC.

The headphone output remains active though as well. The chopping on the headphone is heard on the PC as 'clean' silent interrupts in the audio. ffmpeg produces error messages; rtp throws 'Non-monotonous DTS in output stream 0:0'. The encoder used by ffmpeg, i chose mp3lame, apparently does not receive a monotonous supply of audio samples. In any case the audio as it leaves pihpsdr, having been processed by wdsp, already has a problem. The audio stream quickly accumulates serious delay. libmp3lame also throws the error 'Queue input is backward in time'.

[ct1iqi]

To give an idea of the chopping effect I observe, using the embedded pihpsdr as receiver and with p2app not running.
Attached 6 mp3 recordings of the G2 headphone output, digitized on a separate Linux PC using line-in and Audacity.
Created a carrier, using my Icom ic-7100, and the G2 is tuned in USB mode, 1 kHz filtering, to hear the carrier as a tone.
S meter: S9 +20dB. 3 recordings in 1 receiver mode, 48/192/384 kHz sample rate, and the same for 2 receivers.
(typo in the filenames: 196 is 192)

[w-u-2-o]

It seems like the CM4 processor just doesn't have the processing power to allow piHPSDR to deliver a continuous stream of audio, and that the quiet portions are the buffer running out and having to catch up.

I counted 5 separate reports of this issue in this topic, so it's not just one person having the problem.

It would be interesting to know if everyone that uses piHPSDR on the G2 hardware is having this problem.

[n1gp]

How does it sound if you run p2app AND run pihpsdr, but choose Network
instead of XDMA in the discovery box?

Same test with 1 rx, 48/192/384 kHz, then 2 rx...

[ct1iqi]

@w-u-2-o
actually experimented with CPU loading but did not notice a real influence. What I did is breaking the VNC link to the active desktop where pihpsdr shows its GUI.
That removes some 40% CPU load, according to what 'top' shows, but does not reduce the chopping.

@n1gp
just tried with p2app active and choosing the eth0 option. The chopping is there as well, and also less with just 1 receiver.

[n1gp]

OK, I tried to replicate your results, if I do 2 rx @ 768k I can get breaks in the audio
using XDMA.

But, then I decide to do it from a VNC connection. With it connected and running
pihpsdr in the VNC client window, it only takes 1 rx @ 48k and there are lots of
audio breakups/glitches.

It doesn't look like there is a very big CPU load using htop so I'm not sure what
about VNC is causing this to happen much more often.

Have you tried running pihpsdr native to the CM4 without using VNC?

[n1gp]

Another thing to check is the CPU frequency. We found that the CM4 CPUs run fine @ 2 Ghz

To see what it's current max is:

pi@raspberrypi:~ $ cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq
2000000

If not 2000000, check /boot/config.txt file and add the following lines:

over_voltage=6
arm_freq=2000