Audio input device 0 error: Broken pipe

Some of my packets don't get decoded because of the above error. Or they do get decoded, but are missing parts. The larger the packet, the higher the chance of an error. I'm using Alsa with a SoundBlaster PCI sound card.

[na7q]

This is the #1 most common issue on Raspberry Pi's. I imagine it could be similar on other machines.
Here's the fix. There is none. Sorta. My fix for the Pi was buying the sound card most don't recommend and making sure an Ethernet connection is there and connected when using direwolf. It's the only thing that solves the issue for me. And it's a sad one.

[wb2osz]

I don't understand why lack of an Ethernet connection would cause the sound system to be less reliable.
You mentioned the Raspberry Pi. Which model? Which operating system version?
"SoundBlaster PCI" doesn't make sense because PCI refers to the motherboard connector in a desktop computer.
What does your configuration file look like?
Try running the "top" command in another window while direwolf is running. What are the numbers for amount of cpu time being used and idle?

[na7q]

I don't understand why a lack of Ethernet connection would make it less reliable either. Yet it works.
I posted over here with the "fix". https://groups.yahoo.com/neo/groups/direwolf_packet/conversations/topics/2577
With this card, I never get any errors, input output or descriptor errors, as long as the Ethernet connection is present. Any other cards it doesn't work, Ethernet or not.
https://www.amazon.com/Virtual-Channel-Audio-Adapter-Notebook/dp/B00M3UWE3Q/

I've recently purchased a Fe-Pi in hopes using I2S for audio will work.

[na7q]

Here's the real fix for those using a Raspberry Pi. It showed up early at my doorstep. It's nearly plug n play with some boot config edits and a certain minimum kernel version needed for ease.
https://www.ebay.com/itm/Fe-Pi-Raspberry-Pi-Zero-2-3-B-Audio-Sound-Card-Module-I2S/252986341757

After running it on a high rate tx over night, it hasn't suffered any errors of any kind, when normally any USB card would fail in minutes to just an hour or two. So this tells me it works, since it never errored out.
So if you have the usual input output and descriptor errors on a Pi, this will guarantee fix your issues.

[f6bvp]

My test with Raspberry Pi 3 quadcore show that this message can occur when CPU is overloaded.
See my ticket message about 100% CPU occupancy.
This is related to the Raspberry model and depend on the speed of CHANNEL you select.
On another quadcore RPi 3 I can run two CHANNEL(s) at 9600 with CPU% peaking at "only" 91%
and without any audio broken pipe warning.
Bernard

[na7q]

My average CPU has always been at 10% or less. It's only higher when I'm compiling or using multiple applications at once. Regardless of the the CPU usage, it still does it. But good to know that high CPU usage could lead to the same issue.

So far the Fe-Pi is working great and produces no issues with a proper setup. Running an HT with the stock antenna an inch from the card does create a broken pipe issue. But I'm not surprised, since some things don't tolerate RF feeding right into it like that.

[craigerl]

Pi ZeroW gets this now and then, maybe once an hour, almost nothing to worry about, plus it seems to happen after I get an [ig>tx] line from the aprs server. This is with an Fe-Pi audio hat. Observed with ethernet or wifi. CPU 79% idle...

Digipeater K7FED-1 audio level = 45(29/19)   [NONE]   _||||||__
[0.3] N7NJO-14>SX0VYV,K7FED-1*,WIDE2-1:`14 m5Iu/]"3s}=<0x0d>

[ig>tx] KK6TND-10>APRX29,TCPIP*,qAC,T2CAEAST:!3840.50NI12110.50W&aprx TNC-Pi iGate Folsom
Audio input device 0 error code -32: Broken pipe
This is most likely caused by the CPU being too slow to keep up with the audio stream.
Use the "top" command, in another command window, to look at CPU usage.
This might be a temporary condition so we will attempt to recover a few times before giving up.

[ig>tx] KO6KL-11>APWW10,TCPIP*,qAC,T2GREECE:T#144,100,048,002,500,000,10000000
Audio input device 0 error code -32: Broken pipe
This is most likely caused by the CPU being too slow to keep up with the audio stream.
Use the "top" command, in another command window, to look at CPU usage.
This might be a temporary condition so we will attempt to recover a few times before giving up.

N6VV-2 audio level = 98(48/25)   [SINGLE]   ______:__
[0.6] N6VV-2>APMI06,WIDE2-2:@072113z3757.13NI12205.63W&Contra Costa IGATE

[dranch]

As the output from Direwolf tells you to do, what's the output of "top" when Direwolf throws this error? You say the CPU is 79% idle but is that according to "top", "vmstat 5", or something else? The Raspberry Pi ZeroW is a low performance system and it might be getting overwhelmed at that moment with other tasks like cron jobs, etc.

[craigerl]

I'm referring to the average cpu utilization from top... which correlates a bit with uptime/load averages.

[NCommander]

Possibly some insight to this. I've been doing APRS digipeating work with a Pi. When I was using rig control with a FT-857D managed through Direwolf, it worked reliably with USB audio devices.

However, after I switched to using VOX as a test, this issue bit me. I have noticed fiddling with DWAIT seems to help somewhat, but I think there's a problem with rapidly switching between record and playback on the same ALSA node that comes out on slower machines. I could also resolve the problem by moving audio input to the USB device, and audio out to the port on the side of the Pi.

Hope this helps the next guy.

[wb2osz]

This is from 7 years ago.
The early Raspberry Pi audio system had some issues.
It is better now.
Open a new case if this is still a problem.