Gateware 20200712_72p1 Released

[Steve Haynal]

Hi Group,

This is experimental gateware to see the effect of a larger TX buffer on wifi connections, and also a couple of cases of relay chatter. Please see the release page for more details:

https://github.com/softerhardware/Hermes-Lite2/tree/master/gateware/bitfiles/testing/20200712_72p1

73,

Steve

kf7o

[Matthew]

Hi Steve,

Over the last few months when doing some casual CW contesting at weekends I have noticed a strange issue with my HL2+linHPSDR (using CWX). It is very hard to replicate and I've been trying to find a way to repeat it. The PC sent CW becomes very "choppy" (I listen to sent CW using duplex feature in linHPSDR). Looking at the underflow/overflow buffer flags sent from the HL2 shows this is a HL2 TX buffer issue. The HL2 stays in this state of sending choppy cw (I don't mean it is stuck in TX, just that when CW is sent from PC, it is always sent choppy). I can quickly clear the fault by changing the sample rate in linHPSDR. I've tried a few times to properly find a way to raise this fault condition, but I can't find one. I have observed a few times; I have a QSO, leave my PC for maybe 15 mins, come back and the HL2 has gone into this condition. I managed to observe a fault last night and record the MSBs of the buffer (this was sending "R 599 27" at 25 wpm), I have the buffer size set at 0xA. The following is the reported MSBs from the HL2 before, during and after TX of CW message:

128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128, 128,
128, 128, 128, 128, 143, 28, 28, 28, 28, 28, 28, 28, 28, 28, 28, 13, 128, 128, 128, 128,
128, 128, 128, 128, 245, 229, 214, 198, 182, 166, 158, 30, 30, 30, 30, 30, 30, 30, 30, 30,
30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 15, 128, 128, 128, 128, 128,
128, 128, 187, 243, 228, 212, 196, 180, 165, 157, 13, 128, 128, 128, 128, 128, 128, 128, 128, 245,
229, 213, 197, 182, 166, 158, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, ,30 ,30 ,22, 128,
128, 128, 128, 128, 128, 128, 128, 244, 228, 212, 197, 181, 165, 157, 29, 13 ,128, 128, 128, 128, 128,
128, 128, 251, 235, 219, 204, 188, 172, 156, 156, 13, 128, 128, 128, 128, 128, 128, 128, 128, 177, 33,
255, 239, 224, 208, 192, 176, 161, 153, 25, 25, , 25, 25,25 ,54 ,54 ,54 ,54 ,54, 54, 54, 54, 54, 54,
54 , 54, 54, 54, 54, 54, 54, 54, 54, 54, 54, 54, 54, 54, 38, 22, 7, 128, 128, 128, 128, 128, 254, 239,
223, 207, 191, 176, 160, 160, 16, 0, 128, 128, 128, 128, 128, 128, 128, 247, 231, 215, 200, 184, 147,
23, 39, 47, 47, 47, 47, 47, 47, 47, 39, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47,
47, 47, 47, 47, 47, 31, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47,
31, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 47, 39, 47, 47, 47, ,47 ,47 ,47 ,47, 47, 47, 47, 47, 47, 47, 47, 47

I have seen this with the maximum buffer size in stock gateware (69p4 or beyond). With the HL2 in this condition, I then tried switching to SSB, and I do hear random relay clicks in and out when TXing.

I then changed the sample rate, observed the MSBs reported by the HL2 looked sensible/normal and set about TXing some AM into a dummy load. I am still hearing occasional relay clicks, say one every 2 or 3 mins? Back in February, I spent hours doing this same thing (AM TX into dummy load) testing for tx audio drop outs after I implemented scheduled packets from linHPSDR to the HL2. I am fairly confident I didn't hear any relay clicks doing this. I also spent a lot of time looking at large numbers of TX packets from the PC to the HL2 using wireshark. I did some histogram plots to look at timestamps from Wireshark captures, I think the maximum jitter I observed was 6 ms.

My setup remains the same throughout with:

** What software are you using? -> linHPSDR

** How much compute power does your host have: low, medium, high? -> Medium/High

** Describe your network HL2 to PC connection. Is it 100Mbs or 1000Mbs? Are there router/switch hops between your PC and the HL2? If so, how many? Are there any wifi hops? -> Wired direct PC to HL2 1000 MBs.

** What is the idle status of the 4 LEDs on the front of the HL2? -> LED nearest mag jack on

** Is your relay chatter a consistent buzz, or a low rate of clicks? Does it vary? -> random chatter

** What is your power supply voltage during TX? -> stable bench supply @13.8 V

** Do you hear the chatter with the N2ADR board removed? -> not tested yet, but I'm fairly confident it is K2 on the HL2 board.

** Does using the new testing gateware (72p1) have any effect? Does adjusting TX buffer latency and PTT latency have any effect. -> Will try new gateware tomorrow. Adjusting TX buffer latency in stock gateware doesn't seem to have removed the problem.

I do not know if the CWX issue I have observed and these random relay clicks I describe when TXing in AM into a dummy load are the same issue. I will try to devise some more tests. I would like to capture a Wireshark log when I hear the relays chatter.

73 Matthew M5EVT.

[Ronald Nicholson]

More questions for everybody (re the HL2 relay stutter issue):
What type of computer are you using? ( Intel desktop, laptop, Mac, Raspberry Pi, Android, iPad, or ?? )
What speed grade of CPU?
How busy is the CPU? (via performance or process manager readout)
What OS is it running? ( Windows XYZ, Linux Ubuntu, macOS, Raspbian, or ??? )
Does the computer or OS have a power-saving or sleep mode? If so, how is it currently configured?
Is the Ethernet port NIC built-in, or on an IO card, or on a USB dongle, etc.?

If using a router, what brand or model?

If on WiFi, does the problem change depending on your computers distance from the WiFi access point?

Does the problem go away, or get worse, after stopping and restarting the connection to the HL2?

Does the problem go away after quitting and relaunching your SDR software?

Does the problem go away, or get worse, after rebooting your computer?

If you use the same computer for Skype, Zoom, VoIP, etc., does that work smoothly? Or with dropouts or other degradations?

Thanks, Ron, n6ywu

[Matthew]

I have run out of time tonight to try the new gateware because I got distracted by examining wireshark traces.

I managed to capture a wireshark trace when I was getting relay chatter. A numpy histogram of the times between packets show the vast majority scheduled to the correct order of 2-3 ms. From the capture of around 4000 packets sent from the HL2 the following times are above 10 ms (my TX buffer size is set at 10 ms):

13.746  14.072  14.103  14.927  14.214  14.944  16.023  20.805

If these delays between packets were compounded by a poor wifi connection or grouped dumping of packets by network hardware, I could see regular problems.

The logic of my code in linHPSDR is such that at 48000 (with 1 rx), it simply sends a packet to the HL2 every time it receives one. I can see in the wireshark trace that I am receiving packets but the response isn't sent in a timely fashion for these outliers above. This tells me it is something downstream of linHPSDR code.

I gave SparkSDR a very good long test (my standard AM music into dummy load). Not relay problems at all.

I went digging in the linHPSDR source and did some setsockopt reading.

I have set the following for the linHPSDR socket:

      optval = 6;
      if(setsockopt(data_socket, SOL_SOCKET, SO_PRIORITY, &optval, sizeof(optval))<0) {
        perror("data_socket: SO_PRIORITY");
      }

and after around 25 mins of continuous AM TX I have heard not relay chatter.

It would be very interesting to hear if anyone is having these issues with SparkSDR. I suspect Alan has the priorities set high enough that it might not be affected? Jim, do you set SO_PRIORITY in Quisk?

73 Matthew M5EVT.

[Steve Haynal]

Hi Matthew,

Good catch with SO_PRIORITY. Any realtime or priorities given to the HL2 UDP send should help. A quick scan of the Quisk code makes me think it is not currently applied in Quisk.

I have never experienced unexpected relay disengage/engage in Quisk. I use Quisk with WSJT-X for FT-8 and at most 1 out of 10 transmissions I might see a TX hiccup in the full-duplex view. It doesn't appear to affect my transmission. I'm not sure if it is RX, TX or a pulseaudio glitch. 

For you earlier post, what exactly do you not like in the TX buffer statistics data you shared? That is stays at 47 for a long time? How long was that?

73,

Steve

kf7o

[Alan Hopper]

Hi Matthew,

that is very interesting, I'm not setting those priorities so will look into that. I've never got around to logging/displaying the tx buffer level as no one has ever mentioned a problem but I'm begining to think that many issues go unreported .  Just to check, are those timings for delays in packets sent by the HL2? i.e. the delay is either on the network or the os network stack up to the point wireshark grabs it.

I have a couple of linux issues to sort out in my code that both appear to need extra rights, setting high thread priorities and increasing the udp buffer size.  One thing I do in spark that maybe helping is the entire realtime part of the code is lockfree (unless there are locks hidden in libs) once running.

73 Alan M0NNB

[Matthew]

Hi Steve,

I've spent ages writing Python scripts to analyse and interpret wireshark traces/packets and conclude the fault here lies with linHPSDR with the CWX glitches. Much more debugging required to figure out how/why.

73 Matthew M5EVT.

[Ronald Nicholson]

It might be good to gather a few stats, say by logging the inter-arrival times of UDP packets from the HL2 to the SDR app, and monitoring the Tx buffer level in the HL2, which seems to be a good proxy of UDP latency variation from the SDR app to the HL2.  I'm thinking of putting some sort of indicators (green light, red light, etc.?) in my SDR app to help diagnose these network issues, as I find lots of issues (signal gaps, stutters, relay chatter) using the HL2 over WiFi under various conditions.  But none (so far) when directly wired (no router).

73, Ron, n6ywu

------

[Steve Haynal]

Hi Matthew and Ron,

I think you can infer quite a bit of information regarding UDP latency with the existing TX IQ FIFO Count MSBs plus the under/overflow flags. You can vary the buffer latency and then send UDPs at varying times and see the effect on these HL2 statistics.

Regarding the CWX glitches, I did review the Verilog and thought of a couple of probably rare corner cases to guard against. I will try to make those changes in the next gateware release.

73,

Steve

kf7o

[Matthew]

After recent comments about WiFi I have set up an experiment. My HL2 is always on the desk, top open and connected by wired ethernet to my laptop. After I changed something in my linHPSDR code recently, I hear no relay clicks with this configuration now. So I can be confident I have a good baseline for the test.

I moved my HL2 to be plugged into my router and connected a dummy load to my HL2. This allows me to connect to my HL2 over WiFi. I use enterprise grade WiFi gear at home. I was transmitting music and listening to the transmitted signal using the duplex feature, with this I can easily hear if there are problems (even if I am too far away from the HL2 to hear the relay click). All tests with 1 RX @ 48000.

With non large buffer gateware, I hear very regular relay clicking with linHPSDR (I was trying a number of different buffer sizes using linHPSDR) and SparkSDR. I changed to this experimental gateware. The relay clicks become less regular. I set the buffer size to 60 ms with linHPSDR and the relay clicks are infrequent.

My WiFi AP has a bewildering amount of configuration options. I spent some time going through these to understand them, I was unable to remove the problem by changing options that I hoped could improve things. My total traffic reported at the time was around 7 Mbps tx, 3.2 Mbps rx for all WiFi users.

I captured 100 seconds of data in Wireshark for data from the HL2 to my laptop. 16 packets from the HL2 arrived at my laptop with a gap of greater than 70 ms. I have linHPSDR configured to be synchronised to receipt of a packet, so the resulting TX IQ packet sent to the HL2 will have been of similar delay.

My WiFi supports 5 GHz, but my laptop doesn't. I'm reluctant to start buying new kit in a vauge hope of improvement. There is always a chance it is my laptop WiFi that is the fault here.

Google searches suggest that packet bursting is common for WiFi. Perhaps there is some kit that can control this, but I imagine it is bursting for a good reason and without this, a UDP packet will be a likely candidate to get lost.

73 Matthew M5EVT.

[J P Watters]

Alan, Matthew and Steve,

My HL2 physically sits next to my router, the HL2 is configured for DHCP, had the last two hex characters in the mac address changed to 1 1, and the Router has a reservation set for it. The Lease is good for 12 hours. 

After 12 hours if I open Spark, it reports that it has a self assigned ip address.

 If I power off the HL2 for 15 seconds and then back on again, the HL2 powers up and requests a address and the router grants it renewing the lease.

However, If I click on the discover icon in spark, spark does not report the address change.

Closing Spark and restarting it, Spark reports the updated address. 

Since Spark knows the mac address of the HL2, when it has a self assigned address, you can click on it, enable a receiver, ie power on to get the first one. And it works. 

As a test, I set the lease time to 10 minutes, and cleared all the arp caches.

after the first 10 min, I noticed that it renewed by checking the router status page. When I checked the arp cache it showed incomplete. 

jpwatters@Js-MacBook-Pro-15 ~ % arp -a

? (10.0.1.81) at c8:69:cd:32:4a:90 on en0 ifscope [ethernet]

? (10.0.1.92) at (incomplete) on en0 ifscope [ethernet]

At that time Spark reported that it still had the 10.0.1.92 address.

Again I cleared the arp cache. and waited until the next lease expiration. 

Still it maintained the lease and Spark reported the address was maintained.

I am still perplexed. I will return the router to 12 hour leases and see if tomorrow it fails. 

I wonder if the 12 hour lease is too long for the HL2.

..jpw J P Watters

KC9KKO

[Alan Hopper]

Hi jpw,

I can see what is happening from the spark side, once it gets a discovery response from a given mac it ignores further ones from the same mac, this was done as multiple discovery requests can be sent out. I have not allowed for the ip changing and I'm not sure if I should, I shall ponder, I certainly don't want to try and make it cope whilst running.  The ip never seems to change on my network and I've just got standard dhcp with no reservations or other special settings.  From the network side I'm afraid I'm not well versed in what could be wrong, hopefully there are some network experts floating arround here.

73 Alan M0NNB

[Steve Haynal]

Hi Matthew,

Thanks for trying the large buffer gateware. It appears that it can help. It is interesting that the packet jitter on the HL2->PC path also influences timing on the PC->HL2 if you are synchronizing TX/RX packets. Maybe software should anticipate some jitter and have a timeout to send a packet even if the expected RX packet hasn't arrived. Maybe this is why PowerSDR batches TX UDPs already.

73,

Steve

kf7o

[Steve Haynal]

Hi JP,

The HL2 can support a lease time of up to 6 days. The HL2 takes the lease time suggested by the server and divides by 2. So if offered a least of 6 days, it will renew in 3 days. 72 hours is the maximum the internal counter can handle.

At one point the DHCP renewal was tested and working. I haven't touched that code since so assume it is still working.

I need to review the ARP given recent comments.

73,

Steve

kf7o

[J P Watters]

To All,

This morning I found the HL2 with a self assigned address.

The results of the ARP Cache

jpwatters@Js-MacBook-Pro-15 ~ % arp -a

? (10.0.1.170) at c4:b3:1:c4:c:a5 on en0 ifscope permanent [ethernet]
? (10.0.1.251) at 2a:30:44:19:52:d5 on en0 ifscope [ethernet]
? (10.0.1.255) at ff:ff:ff:ff:ff:ff on en0 ifscope [ethernet]
2wire707-airport-express.local (169.254.42.1) at 68:a8:6d:5a:38:b7 on
en0 [ethernet]
? (224.0.0.251) at 1:0:5e:0:0:fb on en0 ifscope permanent [ethernet]
? (239.255.255.250) at 1:0:5e:7f:ff:fa on en0 ifscope permanent [ethernet]
broadcasthost (255.255.255.255) at ff:ff:ff:ff:ff:ff on en0 ifscope [ethernet]
jpwatters@Js-MacBook-Pro-15 ~ %

In SparkSDR I pressed the discover icon, still no change.
Interestingly enough, I can turn on the HL2 and operate it.
Ran Quisk, it does not see the HL2.
Powered off the HL2 and back on, Both Quisk and Spark display the
correct ip address and operate the HL2 on the DCHP reserved address.

The good news is that the issue that the HL2 loses it's IP address
each night. is simply restored with a power on and off.
But I don't understand why.

..jpw J P Watters
KC9KKO

Morris, IL 60450 USA

> --
> You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/34f9ee6f-eb9f-40f0-a7ab-d411c466a2e7o%40googlegroups.com.

[Matthew]

I have spent a very long time getting to the bottom of this. The resulting fix probably is relevant to any Linux SDR users using Pulseaudio. After a period of time (around 40 - 60 minutes), the blocking call to do the audio write (pa_simple_write) was getting blocked for a long time (sometimes up to 100 mS). It was as if Pulseaudio was changing mode. This will cause many problems with linHPSDR and very likely relay clicks when it enters this state (setting a timeout to send a packet to the HL2 is on my to do list).

After a lot of gdb, profiling, strace etc. I tracked it down to the following setting in default.pa (either in your home dir or /etc/pulse/default.pa). Comment out the following to fix this:

### Automatically suspend sinks/sources that become idle for too long
#load-module module-suspend-on-idle

73 Matthew M5EVT.

[Steve Haynal]

Hi Matthew,

Thanks for this tip. I have made the changes to my default.pa. This along with your SO_PRIORITY tip are things I don't want to lose track of. I will try to add at least links in the wiki.

73,

Steve

kf7o

[Graeme Jury]

 Hi Matthew,

It seems that the change kills audio on devices using plughw. On piHPSDR it won't even allow the checkbox to be ticked for this audio if you uncheck it. I have not tried Quisk yet as I only use alsa or Pulse there but did have an SSB qso with Quisk this morning and used Pulse (with the mod) with excellent results.

73, Graeme ZL2APV

[Matthew]

This is odd. I am guessing from your description you aren't using "real" alsa (i.e. no Pulseaudio daemon running) and you are still using the PulseAudio daemon to transport the audio (in some form)?

73 Matthew M5EVT.

[Graeme Jury]

Yes you are correct Matthew. I am using a new install of Linux Mint with its stock standard sound setup. When I can get to my computer I will try running piHPSDR with pasuspender and see what that does and report back.

73, Graeme ZL2APV

--

You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/9862d337-d113-461e-a700-efb1665a46e7o%40googlegroups.com.

[Graeme Jury]

Hi Matthew,

Tested with "pasuspender ./piHPSDR" and it runs perfectly. All other sound seems unaffected although they will almost certainly be running through pulse. I don't have any Jackd apps to test on.

gvj@gvj-M92p:~$ uname -a
Linux gvj-M92p 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Linux Mint 20 Cinnamon

It would be good if others using a non Ubuntu Linux could try your edit to default.pa as some Linux's may not exhibit this problem although it seems that pulse has become the de facto installation for most and very few will be using portaudio or Jack.

73, Graeme ZL2APV

On Monday, August 3, 2020 at 7:48:42 AM UTC+12, Graeme Jury wrote:

Yes you are correct Matthew. I am using a new install of Linux Mint with its stock standard sound setup. When I can get to my computer I will try running piHPSDR with pasuspender and see what that does and report back.

73, Graeme ZL2APV

On Mon, 3 Aug 2020, 5:09 AM Matthew, <bal...@gmail.com> wrote:

This is odd. I am guessing from your description you aren't using "real" alsa (i.e. no Pulseaudio daemon running) and you are still using the PulseAudio daemon to transport the audio (in some form)?

73 Matthew M5EVT.

On Saturday, 1 August 2020 23:11:38 UTC+1, Graeme Jury wrote:

 Hi Matthew,

It seems that the change kills audio on devices using plughw. On piHPSDR it won't even allow the checkbox to be ticked for this audio if you uncheck it. I have not tried Quisk yet as I only use alsa or Pulse there but did have an SSB qso with Quisk this morning and used Pulse (with the mod) with excellent results.

73, Graeme ZL2APV

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite+unsubscribe@googlegroups.com.

[Sid Boyce]

Hi all,
I on rare occasions still see reports of problems.
The last version of pulseaudio I had problems with was version 1.x,
needing to use pasuspender.
Ubuntu is now at version 12, Fedora and openSUSE are at version 13, all
working flawlessly.
73 ... Sid.

On 03/08/2020 02:09, Graeme Jury wrote:
> Hi Matthew,
>

>  Hi Matthew,

>
> It seems that the change kills audio on devices using
> plughw. On piHPSDR it won't even allow the checkbox to be
> ticked for this audio if you uncheck it. I have not tried
> Quisk yet as I only use alsa or Pulse there but did have
> an SSB qso with Quisk this morning and used Pulse (with
> the mod) with excellent results.
>
> 73, Graeme ZL2APV
>
> --
> You received this message because you are subscribed to the
> Google Groups "Hermes-Lite" group.
> To unsubscribe from this group and stop receiving emails from

> it, send an email to hermes-lite...@googlegroups.com
> <mailto:hermes-lite...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/hermes-lite/9862d337-d113-461e-a700-efb1665a46e7o%40googlegroups.com

> <https://groups.google.com/d/msgid/hermes-lite/9862d337-d113-461e-a700-efb1665a46e7o%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "Hermes-Lite" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to hermes-lite...@googlegroups.com
> <mailto:hermes-lite...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/hermes-lite/6ca98883-ddb8-4e0d-9981-edc3e8ce4998o%40googlegroups.com
> <https://groups.google.com/d/msgid/hermes-lite/6ca98883-ddb8-4e0d-9981-edc3e8ce4998o%40googlegroups.com?utm_medium=email&utm_source=footer>.


--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

[Matthew]

I'm hoping for the overdue option to upgrade to 20.04 this later week. This has PulseAudio 13 packaged in it, I will test for different behaviour.

I suspect this behaviour is classed as a "feature" rather than a bug. I imagine there must be a way to keep the PulseAudio sink alive in code without this mode kicking in, but I haven't figured it.

73 Matthew M5EVT.

[Graeme Jury]

Hi Matthew, Sid et al,

Linux Mint 20 has pulseaudio at version 13

gvj@gvj-M92p:~$ pulseaudio --version
pulseaudio 13.99.1

I am not sure if you are upgrading Ubuntu or Linux Mint to 20 Matthew
but I will be interested to know if the issue shows for you after the
upgrade. I suspect that the problem is with pulseaudio ver 13 although
for now pasuspender works fine. I have exactly the same problem with
Quisk on alsa so it looks like any plughw/alsa applications will need to
be started this way.

73, Graeme ZL2APV

[Sid Boyce]

Hi Graeme,
Sorry, likewise Ubuntu 20.04 is at pulseaudio 1:13.99.1-1ubuntu3.5. I
had been looking at SBC's with 18.04.
73 ... Sid.

>>>     Yes you are correct Matthew. I am using a new install of Linux
>>>     Mint with its stock standard sound setup. When I can get to my
>>>     computer I will try running piHPSDR with pasuspender and see
>>> what
>>>     that does and report back.
>>>
>>>     73, Graeme ZL2APV
>>>
>>>     On Mon, 3 Aug 2020, 5:09 AM Matthew, <bal...@gmail.com
>>>     <mailto:bal...@gmail.com>> wrote:
>>>
>>>         This is odd. I am guessing from your description you
>>> aren't
>>>         using "real" alsa (i.e. no Pulseaudio daemon running)
>>> and you
>>>         are still using the PulseAudio daemon to transport
>>> the audio
>>>         (in some form)?
>>>
>>>         73 Matthew M5EVT.
>>>
>>>         On Saturday, 1 August 2020 23:11:38 UTC+1, Graeme
>>> Jury wrote:
>>>
>>>              Hi Matthew,
>>>
>>>             It seems that the change kills audio on
>>> devices using
>>>             plughw. On piHPSDR it won't even allow the
>>> checkbox to be
>>>             ticked for this audio if you uncheck it. I
>>> have not tried
>>>             Quisk yet as I only use alsa or Pulse there
>>> but did have
>>>             an SSB qso with Quisk this morning and used
>>> Pulse (with
>>>             the mod) with excellent results.
>>>
>>>             73, Graeme ZL2APV
>>>
>>>         --         You received this message because

>>> you are subscribed to the

>>>         Google Groups "Hermes-Lite" group.
>>>         To unsubscribe from this group and stop receiving
>>> emails from
>>>         it, send an email to
>>> hermes-lite...@googlegroups.com
>>>        <mailto:hermes-lite...@googlegroups.com>.
>>>         To view this discussion on the web visit

>>> https://groups.google.com/d/msgid/hermes-lite/9862d337-d113-461e-a700-efb1665a46e7o%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/hermes-lite/9862d337-d113-461e-a700-efb1665a46e7o%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Hermes-Lite" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to hermes-lite...@googlegroups.com
>>> <mailto:hermes-lite...@googlegroups.com>.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/hermes-lite/6ca98883-ddb8-4e0d-9981-edc3e8ce4998o%40googlegroups.com
>>> <https://groups.google.com/d/msgid/hermes-lite/6ca98883-ddb8-4e0d-9981-edc3e8ce4998o%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>>
>>
>>
>