Audio Input Timeout Timer is Too Low

[jeromegoddard2]

Thanks so much for all the work you've done with direwolf--it's a great program. My issue is that there is an audio timeout timer for input that is set by default as 25ms. Several members of our local ham radio club have been using direwolf as a part of an iGATE/digipeater system and have encountered direwolf crashing unexpectedly. After many hours of debugging, we found that our rigs have small gaps in the input audio stream of anywhere from 5ms up to 500ms or so. These are gaps are unpredictable and distributed sometimes as quickly as minutes apart and sometimes as far apart as days.

Thus, I would request that you move this timer setting to a higher default value (say, 1000ms at least) or, even better, allow this timer value to be set in the configuration file. I edited the source myself and hard coded the timer value to be 10000ms and have not had any more issues. However, I would rather not have to make this edit every time y'all come up with new features!

Respectfully,
Jerome
W4IJG

[dranch]

Could you paste in a patch or better yet, create a Git merge request that shows your proposed change?

[jeromegoddard2]

Thanks for the quick response.

Here is what I changed:

In audio_win.c
Around line 789: In case AUDIO_IN_TYPE_SOUNDCARD: I changed "int timeout = 25;" to "int timeout = 10000;"

25ms is just too small for our systems.

This small change works well for me. However, as I suggested, it is probably better to let this be a user defined variable from the config file. I will let you decide.

Please let me know if you need any more information.

Thanks,

Jerome
W4IJG

[dranch]

Can you tell us about the computer hardware (CPU/RAM/etc), operating system and version, sound device (make/model, is it a real vendor offering or clone), and how the sound device is connected to the computer as well and if it's a direct connection or it goes through say passive/passive USB hubs? All this detail matters as 25ms is a LONG time and while this change might improve reliability with Direwolf, this might be masking a far larger issue with your specific setup.

[wb2osz]

I'm not against making the timeout time longer. Better to keep retrying longer instead of giving up too soon. Like David, I'm wondering what sort of situation produces this issue. I've never seen it, even with a Raspberry Pi model 1 while doing other things on it.

Oh, I see it is on Windows. "audio_win.c" What sort of audio interface is it using? Is there a USB hub between the computer and a USB audio adapter? Is the computer doing something else very demanding at the time?

John

[jeromegoddard2]

John,   Thanks again for your help and quick response to my request. There are one or two other stations in addition to mine that are having this exact issue. I believe that mine and one other is using Windows 10. My setup is a FTM-6000 connected on the data port to a digirig classic which is connected with a digirig-made usb cable to a usb hub which is then fed to a usb 3.0 port on an older custom built PC (it’s got 128gb of ram, an intel 8-core processor, and an integrated sound and video card).  I don’t have the exact specs of anything beyond that with me currently.    Here is my thought, I agree that the issue is on my end and there is probably something going on with my particular setup that is causing this issue. In fact, I listened to the audio input from the digirig through the Windows sound control panel and could clearly hear the normal radio input go silent sporadically at random intervals that span minutes to days. Philosophically, I agree that Direwolf should give a warning that audio input has been interrupted when a 25ms threshold has been reached. This informs the user that there is an issue with their setup. However, to end the program after such an event doesn’t make sense to me.  What is the harm in there being some interference in the audio input that causes a gap in the input stream?  I would love to hear your original thoughts as to why this such a timer was employed.  In my case, it made Direwolf unusable. Until I found this issue, I was constantly having to restart Direwolf to keep my IGate going—sometimes every 5 minutes.Perhaps a compromise would be to:1) use two timers, the original one for 25ms would simply print a warning message in the console that the audio input signal was interrupted and the second would kill the program after the input has been off for a prolonged period of time, say 10sec.OR2) keep the one timer at 25ms, warn the user when it’s breached, but don’t kill the program over such an issue.Thanks,JeromeW4IJGSent from my iPhoneOn Sep 6, 2024, at 11:14 AM, wb2osz ***@***.***> wrote: I'm not against making the timeout time longer. Better to keep retrying longer instead of giving up too soon. Like David, I'm wondering what sort of situation produces this issue. I've never seen it, even with a Raspberry Pi model 1 while doing other things on it. Oh, I see it is on Windows. "audio_win.c" What sort of audio interface is it using? Is there a USB hub between the computer and a USB audio adapter? Is the computer doing something else very demanding at the time? John —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[wb2osz]

25 is not milliseconds.
25 is the maximum number of times it will wait for ONE_BUF_TIME (10 milliseconds) so the total is a quarter of a second.
I suppose I could increase 25 to 200 which would be 2 seconds.
Something is SERIOUSLY wrong if there is a 2 second gap in the input audio samples being delivered.

You observed: "I listened to the audio input from the digirig through the Windows sound control panel and could clearly hear the normal radio input go silent sporadically at random intervals..."

Can you eliminate the USB hub between the USB audio device and the computer?
I've seen USB hubs causing audio problems before.
Does it receive reliably if the transmitter is disabled or turned to low power?
Often transmitter RF will get into the USB device and cause it to malfunction.
Did you try adding ferrite beads around all your cables?

If something is really messed up, I think it is better to abort the program and have it restart automatically rather than sitting there hung.

73,
John WB2OSZ