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

Long PTT delays when using the Fe-Pi and UDRC #273

Closed
n7ipb opened this issue May 11, 2017 · 17 comments
Closed

Long PTT delays when using the Fe-Pi and UDRC #273

n7ipb opened this issue May 11, 2017 · 17 comments
Labels
T: defect

Comments

@n7ipb
Copy link

n7ipb commented May 11, 2017 •
edited by sm0svx
Loading

Odd_PTT_delays.txt
I posted about this on the mailing list back in September of last year but never got a response and never found the time to troubleshoot it myself. I've moved on and designed my own card for the RPi with USB sound chip and gpio PTT/CSQ but since both cards are clearly being used with svxlink it would be nice to track this down.

In normal repeater or echolink configurations both seem to work fine, its when svxlink is configured to have one Repeater and one Simplex logic with local rx/tx on the same interface that the issue shows up and then only when not using USB for the audio.

I've attached a copy of my original posting including the config file.
@sm0svx
Copy link
Owner

sm0svx commented May 14, 2017

Seems like a tricky problem. I can see no obvious configuration error. I have a UDRC card here but I have not tested it yet. I'll need to find the time to test your configuration.

@n7ipb
Copy link
Author

n7ipb commented May 14, 2017 via email

@ghost
Copy link

ghost commented May 16, 2017

to use the fe-pi ypu have to set the sounds to 48000. this fixes the audio issues

@Dloranger
Copy link
Contributor

I ran into N7IPB at Seapac convention and we discussed what he was seeing and we are still observing this on the ICS platform as well. I filed the bug under the ORP tracker, but this appears to be the exact same issue.

We witnessed delays ranging from ~100ms to almost a second, the delay appears to be random.

@sm0svx
Copy link
Owner

sm0svx commented Dec 18, 2017

Is this still a suspected problem with SvxLink or is it a hardware problem? I'm a bit confused about if it's a problem with UDRC or Fe-Pi or when combining them.

What's the "ICS platform"? "ORP tracker"?

@Dloranger
Copy link
Contributor

I am no longer seeing this problem, I am still not sure why the delay was so random, but I suspect it has to do with the 1-wire GPIO on the raspberry pi which is used as a temp sensor. It seems to choke the system for about 1-3 seconds (proc = 100%).

The "ICS platform" is a commercial board, that was previously unnamed. link below for reference
http://www.ics-ctrl.com/PI-REPEATER

@n7ipb
Copy link
Author

n7ipb commented Dec 19, 2017 via email

@sm0svx
Copy link
Owner

sm0svx commented Dec 21, 2017

Ok. Thanks for the additional information. I'll keep the issue open for now so that it's not forgotten.

@Dloranger
Copy link
Contributor

Tobias,

I got an email from a customer last night that he is seeing frequent dropouts on his setup that sounds familiar to this. I am getting my station back on the air to help work through the details of what he is seeing.

Symptom #1
Operator 1 (Transmitter) keys up and begins transmitting, first 1-2 seconds are lost to operator #2 (receiving station) (need to confirm if SQL is active or not on operator #2 radio, I believe it is)
While operator #1 transmits, operator #2 hears intermittent dropouts that last ~1-3 seconds.

Symptom #2
During ID, the call sign playback is stopped for 1-2 seconds mid-stream

Attached is the basic configuration file
svxlink.conf.txt

If you send me your address I can send you one of the ICS hardware boards (fits on a raspberry pi 3) for a test bed.

@sm0svx
Copy link
Owner

sm0svx commented Jan 20, 2018

@Dloranger, thanks for the feed-back. My address is up to date on qrz.com. I don't own a pi3 at this moment but I have a pi2. Does the board work on that as well?

@Dloranger
Copy link
Contributor

Dloranger commented Jan 20, 2018 via email

@sm0svx
Copy link
Owner

sm0svx commented Jul 24, 2019 •
edited
Loading

Using the ICS controller board, for some reason the calls to the two functions snd_pcm_hw_params and snd_pcm_prepare in the Alsa API take approximately 420ms each. That is why it takes so long to open the audio device.

Changing the I2C bus clock frequency to 400kHz as suggested by @Dloranger does not seem to change anything so the communication speed to the audio chip does not seem to be the reason for the delay.

The same type of behaviour can be demonstrated using aplay. I first created an empty wav-file using sox.

sox -traw -esigned-integer -b16 -r48000 -c2 /dev/null /tmp/null.wav

Comparing the built in audio device with the ICS board give the following difference.

# ICS board
$ time aplay -Dhw:CARD=Audio /tmp/null.wav 
Playing WAVE '/tmp/null.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

real    0m0.441s
user    0m0.011s
sys     0m0.010s

# Built in audio device
$ time aplay -Dhw:CARD=ALSA /tmp/null.wav 
Playing WAVE '/tmp/null.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

real    0m0.024s
user    0m0.023s
sys     0m0.000s

I'd say there's something fishy with the Fe-Pi/RPi combination.

@sm0svx
Copy link
Owner

sm0svx commented Jul 24, 2019

I've implemented a workaround for this problem. It consists of two parts: not closing the audio device once opened and feeding the playback device with zeros when there's no audio to write. Will test it and commit tomorrow.

@Dloranger
Copy link
Contributor

It is possible this workaround may also fix #96 and #352 depending on how you implement it.

Also with your method of demonstrating the timing delay independent of the svxlink software, I will post to the rpi foundation a bug report, perhaps they can fix the bug at some point. Something that severe should be easy to chase down by the original driver authors I would hope.

@Dloranger Dloranger mentioned this issue Jul 25, 2019
Closed
@sm0svx
Copy link
Owner

sm0svx commented Jul 25, 2019

The workaround is in master now. Set AUDIO_DEV_KEEP_OPEN=1 in all local receiver RX and TX sections. Also set the environment variable ASYNC_AUDIO_ALSA_ZEROFILL=1 before starting SvxLink.

@sm0svx sm0svx closed this as completed Jul 25, 2019
@Dloranger
Copy link
Contributor

@sm0svx

Sorry to seem dense on this one, but how do we set the ASYNC_AUDIO_ALSA_ZEROFILL=1 environmental variable?

I am guessing we want to edit the svxlink.service file to set this variable, but this is not really my expertise area.

Can we get a solution here and/or specific guidance in the svxlink manual for how to utilize this feature?

@sm3sgp
Copy link
Collaborator

sm3sgp commented Oct 5, 2019

This was recently discussed on the groups.io list.
Here: https://groups.io/g/svxlink/message/221

If you use the systemd scripts you can edit the /etc/default/svxlink file.
The parameter is documented in the manual, "man svxlink"

Note, in latest git master the ASYNC_AUDIO_ALSA_ZEROFILL is set to 1 by default.

From the mailinglist:
Environment variables are inherited from the user who launch the application.

So, either:
Set the environment variable in /root/.bashrc
Set it in your start script like "export ASYNC_AUDIO_ALSA_ZEROFILL=1" (I'd say this is the preferred one)
Set it on the command line like
$ ASYNC_AUDIO_ALSA_ZEROFILL=1 svxlink --runasuser=svxlink

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
T: defect
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@sm0svx @sm3sgp @Dloranger @n7ipb