Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Delay between PTT assertion and audio packet - Causes dead air for seconds #194

Closed
ve7ltd opened this issue Feb 7, 2019 · 37 comments
Closed

Delay between PTT assertion and audio packet - Causes dead air for seconds #194

ve7ltd opened this issue Feb 7, 2019 · 37 comments

Comments

@ve7ltd
Copy link

ve7ltd commented Feb 7, 2019

I looked through the issues, and was surprised not to see this anywhere. I had the same problem the last time I tried Direwolf a few years ago.

What happens is on SOME digipeated and beacon transmissions, there is a long delay between when the PTT is asserted and when the audio comes out of the sound card. Yet most transmission are very quick (no obvious delay). I have played around with the DWAIT, TXDELAY, and TXTAIL, and they don't seem to affect the issue. The delay can be anywhere from two seconds to about 15. It just sends dead air before the packet is sent. This obviously ties up the channel and is not good practice.

One thing I did notice seemed to be that DCD was sometimes being triggered WHILE the PTT was active. I would see:

PTT 0 = 1
[0H] VE7WOL-9>TY0SWP,CHURCH,VA7IP-10*,WIDE2-1:`2,]l!8>/
DCD 0 = 1
DCD 0 = 0
PTT 0 = 0

The radio is sending unsquelched discriminator audio to the sound card. The levels are within normal range. I can not hear the transmitted packet in the incoming audio.

My setup is a Raspberry Pi3B+ with a SYBA CM-UAUD USB sound card, running 48000 Hz (native rate). Radio is a Motorola Spectra, modified for headless operation.

Any help or suggestions on the issue are appreciated. Thanks.
@wb2osz
Copy link
Owner

wb2osz commented Feb 7, 2019

A couple people have run into this and the cause remains elusive. One report indicated that it happened only when there was no Ethernet cable connected. Do you have an Ethernet cable connected?

@ve7ltd
Copy link
Author

ve7ltd commented Feb 7, 2019

It is connected to the internet via Ethernet cable. I have tried it standalone too without any connection to the internet without the igate turned on. I will try via wireless later today also.

I have also tried various sampling rates and rate divisions while watching the processor load. I was thinking the problem may be that the program that generates the tones was being blocked by processor overload but that doesn't seem to be it either. It is below 30% and no buffer issues are present.

I'll play around with it more today and see if I can get it to behave.

Thanks

@wa7nwp
Copy link

wa7nwp commented Feb 7, 2019 via email

@ve7ltd
Copy link
Author

ve7ltd commented Feb 8, 2019 •
edited
Loading

There is nothing else running on the Pi, besides consoles running SSH sessions to control it.

I have done the following tests to see if I could recreate the issue, or at least direct what the system could be doing that could affect the symptoms:

  1. I have turned off the igate portion, but the problem persisted.
  2. I changed the DNS servers to a number of them, from my ISP, from the local university, one that I run on Toronto, Google's, and OpenDNS. No difference
  3. With Igate off, I used the serial console on the Pi, and blacklisted the Ethernet and wireless chips. The local loopback is the only TCP/IP device that is recognized. Still does it.
  4. I loaded the processor by logging in and running the stress command "stress -c 4 -t 600s" which loads the CPU to max for 10 minutes - no effect, not even complaints about underrun.
  5. Ran TCPDUMP to watch network activity while direwolf runs. All I see is the initial DNS request for the APRS server and nothing else outgoing.
  6. Redid all of the above after switching to a Pi Zero W - no difference.

My stats over 10 minutes:
No of packets TX'd = 48
No of packets send without delay = 31
No of packets sent with delay = 17
Max delay = 11 sec
Min Delay = 4 sec

I think the next thing I will do is insert some debug in the source code once I figure out what function calls the PTT, and what function plays the audio, and see if there is some sort of race condition I can find. I have a lot of experience coding real-time sound application in Linux and troubleshooting delays.

Dave

@wb2osz
Copy link
Owner

wb2osz commented Feb 8, 2019

Can we continue this on e-mail? I can fill you in on what I have tried. theories, and possible experiments. Too lengthy for here. wb2osz \ comcast \ net

@dranch
Copy link
Collaborator

dranch commented Feb 8, 2019

Actually, could this discussion be put on the public Yahoo list? Several random pockets of smart people seem to be experiencing this and by including everyone, I hope/assume the issue could be narrowed down more quickly. Just my $0.02

@SmithChart
Copy link

SmithChart commented Feb 10, 2019 •
edited
Loading

Hi @ve7ltd,

this issue sounds a little like what I and meinja have been discussing here:
#170

I have posted a patch that enables more debug output here:
#170 (comment)

But with this patch I wasn't able to reproduce the issue anymore.
Maybe you have more luck?

@wb2osz

Can we continue this on e-mail? I can fill you in on what I have tried. theories, and possible experiments. Too lengthy for here. wb2osz \ comcast \ net

I am with @dranch: Can't we have a public discussion? I would really like to help solving this issue.

Regards
Chris, DB1FI

@wb2osz
Copy link
Owner

wb2osz commented Feb 16, 2019

This has been isolated to a small test case.
https://github.com/wb2osz/rpi-usb-audio-bug

@SmithChart
Copy link

@wb2osz Thank you for the test case. I don't have my development setup ready at the moment. But I can add another datapoint:
I am using direwolf with a non-raspbian-based distribution (actually PTXdist ( https://www.ptxdist.org/ )). My last tests were done with:

  • 4.19 mainline kernel
  • alsa-lib-1.1.7
  • alsa-utils-1.1.7 and
  • direwolf-1.5

I will integrate your test case into my system and try to reproduce the problem.

DB1FI

@craigerl
Copy link

craigerl commented Mar 2, 2019

just a data point, i randomly observe dead air before audio, but never more than half a second, on pi3, raspbian stretch (installed version February '19).

@SQ9MDD
Copy link

SQ9MDD commented Mar 18, 2019

I have same strange behavior.
Raspberry pi zero without internet connection USB soundkard dongle. PTT from GPIO.

https://www.youtube.com/watch?v=OBRMSZwGOho

@wb2osz
Copy link
Owner

wb2osz commented Mar 18, 2019

Based on my research, I have to conclude that it is an operating system problem.
It was reported here: https://bugs.launchpad.net/raspbian/+bug/1819560

@wb2osz
Copy link
Owner

wb2osz commented Apr 1, 2019

Still no response to Raspbian bug report.

@SQ9MDD
Copy link

SQ9MDD commented Apr 1, 2019

Raspberry PI 3 A+ also affected :( This bug list is dead?

Btw. more people can fire this bug UP. Just login and follow instruction:

"Launchpad helps you to appraise a bug by giving you a calculated measure — called bug heat — of its likely significance. You can see bug heat in bug listings, and also on individual bug pages, as a number next to a flame icon. Attribute Calculation
Private Adds 150 points
Security issue Adds 250 points
Duplicates Adds 6 points per duplicate bug
Affected users Adds 4 points per affected user
Subscribers (incl. subscribers to duplicates) Adds 2 points per subscriber
"

@craigerl
Copy link

craigerl commented Apr 1, 2019

Seems to be isolated to USB audio. I switched to an Fe-Pi audio "hat" and it works as expected.

@dranch
Copy link
Collaborator

dranch commented Apr 1, 2019

@craigerl Thanks for the report and this test was on my to-do list as well. One other test needed is if this can be reproduced on vanilla Debian running on Raspberry Pi vs. Raspbian. If seen on Debian, another bug report should be filed there too.

@va7acq
Copy link

va7acq commented Apr 1, 2019 via email

@wb2osz
Copy link
Owner

wb2osz commented Apr 22, 2019

This was reported over a month ago and still hasn't received any attention.

https://bugs.launchpad.net/raspbian/+bug/1819560

@dranch
Copy link
Collaborator

dranch commented Apr 23, 2019

Has this been reported to the Alsa people? They would probably know more about this than the Raspberry Pi community. Maybe it's an ARM thing?

--David

@dj1an
Copy link

dj1an commented May 27, 2019

Hi
Nothing new on this topic?
I am also experiencing this bug with Raspi3 and a cheap C-Media USB Audio card.

@wb2osz
Copy link
Owner

wb2osz commented May 27, 2019 via email

@SmithChart
Copy link

SmithChart commented Jun 10, 2019 •
edited
Loading

I still cannot reproduce on my RaspberryPi Zero W anymore.
But I stumbled across USB Power-Management today and had to think about this issue:
https://www.kernel.org/doc/html/v5.1/driver-api/usb/power-management.html#the-user-interface-for-dynamic-pm

Could someone try to disable power management for all connected USB-devices and see if it changes the behavior of @wb2osz Test-Tool?

Disabling power management for all should be possible with the following command:
for i in /sys/bus/usb/devices/*; do echo $i; echo on > $i/power/control; done

I am interested if this changes the behavior on affected systems.

Cheers
Chris

@mpannen1979
Copy link

I am experiencing this 'dead air' extra delay at times.

I appended usbcore.autosuspend=-1 to the end of my cmdline.txt file in /boot/cmdline.txt

I verfied that usbcore has autosuspend off (-1) now by checking:

 /sys/module/usbcore/parameters/autosuspend

now contains -1. Before it had 2.

Nothing is 'broke' for me that I can tell, I will see if this has any affect and report back myself.

@mpannen1979
Copy link

Both autosuspend and autosuspend_delay_ms for my usb soundcard were 2 and 2000 prior.
I verified that they are now both -1 and -1000 with the cmdline.txt modification.

@mpannen1979
Copy link

mpannen1979 commented Jun 17, 2019 •
edited
Loading

Linux 4.9.35-v7+ armv7l

Made no difference for the test program.

Here are my typical results.

Weird that the 'odd' number of seconds shows no delays?
------ spacing of 8 seconds ------

0
255
0
709
Delayed extra 459 mSec
0
1163
Delayed extra 913 mSec
0
257
0
711
Delayed extra 461 mSec
0
1165
Delayed extra 915 mSec
0
257
0
711
Delayed extra 461 mSec
0
1165
Delayed extra 915 mSec
0
257

------ spacing of 9 seconds ------

0
256
0
257
0
257
0
256
0
256
0
256
0
257
0
256
0
256
0
256

------ spacing of 10 seconds ------

0
662
Delayed extra 412 mSec
0
1164
Delayed extra 914 mSec
0
256
0
758
Delayed extra 508 mSec
0
1260
Delayed extra 1010 mSec
0
256
0
758
Delayed extra 508 mSec
0
1261
Delayed extra 1011 mSec
0
257
0
759
Delayed extra 509 mSec

------ spacing of 11 seconds ------

0
261
0
257
0
257
0
257
0
257
0
257
0
257
0
257
0
257
0
256

@mpannen1979
Copy link

Debian 10 Buster show no changes with the test program for me. Still indicates the delays.

@va7acq
Copy link

va7acq commented Jul 12, 2019 via email

@wb2osz
Copy link
Owner

wb2osz commented Nov 24, 2019

The problem was reported here but no one seems interested.
https://bugs.launchpad.net/bugs/1819560
It was confirmed as being a problem but it hasn't been assigned to anyone.
Maybe if more people piled on to the comment section it would get some attention.

@wb2osz
Copy link
Owner

wb2osz commented Nov 24, 2019

Same as #170

@wb2osz wb2osz mentioned this issue Nov 24, 2019
Closed
@caseyjamesdavis
Copy link

caseyjamesdavis commented Jan 19, 2020 •
edited
Loading

Another data point.

I noticed this issue after switching my IGate setup from a desktop to Ubuntu Server 18.04.3 LTS on a Raspberry Pi 3B. The pi is headless, on wifi, and connected to the radio via a RIM-Alinco.

Yesterday, I tried switching to Arch Linux ARMv7 on the same hardware and the delay issue has not appeared.

Cheers,
KC1JHV

update:

  • I'm using Dire Wolf v 1.5
  • I added a comment on launchpad per wb2osz

@wb2osz
Copy link
Owner

wb2osz commented Jan 19, 2020

The problem was reported here but no one seems interested.
https://bugs.launchpad.net/bugs/1819560
It was confirmed as being a problem but it hasn't been assigned to anyone.
Maybe if more people piled on to the comment section it would get some attention.

@mpannen1979
Copy link

mpannen1979 commented Jan 20, 2020 •
edited
Loading

I installed Arch Linux ARMv8 for rpi3, the AArch64 version, and built the dev version 1.6 of direwolf.

I do not hear a delay anymore. I did compile and use the 'bug' program, and the output is clean, too.

@craigerl
Copy link

great info on aarch64!

fwiw, I've given up, and use a gpio hat for audio now (not usb), multiple digi's operating using this hardware

https://fe-pi.com/products/fe-pi-audio-z-v2

arguably sounds better too, and it's US$14. There's no reasonable case for it, but then, neither is there for a usb dongle.

@dranch dranch mentioned this issue Oct 5, 2020
Closed
@wb2osz
Copy link
Owner

wb2osz commented Apr 10, 2023

I believe the problem was fixed in a later Raspberry Pi OS version.
Does anyone think this needs to stay open?

@mpannen1979
Copy link

mpannen1979 commented Apr 10, 2023 via email

@ve7ltd
Copy link
Author

ve7ltd commented Apr 11, 2023 via email

@wb2osz
Copy link
Owner

wb2osz commented Oct 20, 2023

I believe this issue was fixed in a later Raspberry Pi OS release.
Please reopen this if the issue is observed again.

@wb2osz wb2osz closed this as completed Oct 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests