[arm-allstar] Distorted audio (sampling?)

David McGough kb4fxc at inttek.net
Sun Sep 15 18:58:31 EDT 2019


Okay, seeing those messages, likely ground noise or power issues.

On a FAT filesystem, the "Volume was not properly unmounted. Some data may 
be corrupt. Please run fsck" message is scarier sounding than it 
realistically it is. That's the boot filesystem and it rarely is written 
to.


73, David KB4FXC


On Mon, 16 Sep 2019, Alessio Sacchi wrote:

> David,  will replace the power supply on my next visit with a traditional
> regulator getting 5V out of the 12V where everything else is connected to,
> that's for sure.
> 
> Regarding ground loops and RF noise, I am quite lucky the location has no
> high power TV or FM broadcast but just a number of other PMR repeaters on
> 160-175 Mhz and 460 MHz, fire station system links at 70Mhz (this is very
> Italian) and then us. However you bring up a good point I always thought
> about: the URI have no opto coupling for PTT and COS, and audio is also
> directly coupled. I did put two radioshack audio transoformers on the audio
> lines for the 1200 MHz port before taking it up to the hill. I was lazy for
> the oters, my bad. I guess every one of you do that on top of the URI
> instead of plugging it as it is to a radio? BTW, when the distortion
> occurred, it was affecting also 1200 users who were isolated at least on
> the audio line. Could still have been a ground loop from the common ground
> of PTT and COS though.
> 
> dmesg - thanks I didn't think about it. I looked at dmesg since the last
> reboot and found a few things I don't like:
> 
> [    6.204436] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some
> data may be corrupt. Please run fsck.
> [...]
> [13436.127396] Transfer to device 5 endpoint 0x2 frame 980 failed - FIQ
> reported NYET. Data may have been lost.
> [13436.127698] Transfer to device 4 endpoint 0x2 frame 980 failed - FIQ
> reported NYET. Data may have been lost.
> [14513.031406] Transfer to device 7 endpoint 0x2 frame 636 failed - FIQ
> reported NYET. Data may have been lost.
> [14513.031717] Transfer to device 5 endpoint 0x2 frame 636 failed - FIQ
> reported NYET. Data may have been lost.
> [82883.543637] Transfer to device 7 endpoint 0x2 frame 716 failed - FIQ
> reported NYET. Data may have been lost.
> [82883.543947] Transfer to device 5 endpoint 0x2 frame 716 failed - FIQ
> reported NYET. Data may have been lost.
> [95631.951656] Transfer to device 4 endpoint 0x2 frame 324 failed - FIQ
> reported NYET. Data may have been lost.
> [95631.951949] Transfer to device 7 endpoint 0x2 frame 324 failed - FIQ
> reported NYET. Data may have been lost.
> [107403.807689] Transfer to device 7 endpoint 0x2 frame 276 failed - FIQ
> reported NYET. Data may have been lost.
> [107403.807996] Transfer to device 4 endpoint 0x2 frame 276 failed - FIQ
> reported NYET. Data may have been lost.
> [132821.807783] Transfer to device 4 endpoint 0x2 frame 548 failed - FIQ
> reported NYET. Data may have been lost.
> [132821.808094] Transfer to device 7 endpoint 0x2 frame 548 failed - FIQ
> reported NYET. Data may have been lost.
> [134794.135780] Transfer to device 5 endpoint 0x2 frame 652 failed - FIQ
> reported NYET. Data may have been lost.
> [134794.148734] Transfer to device 4 endpoint 0x2 frame 665 failed - FIQ
> reported NYET. Data may have been lost.
> [154885.673839] Transfer to device 5 endpoint 0x2 frame 1310 failed - FIQ
> reported NYET. Data may have been lost.
> [154885.686353] Transfer to device 4 endpoint 0x2 frame 1323 failed - FIQ
> reported NYET. Data may have been lost.
> 
> Alessio IZ4EFN
> 
> On Mon, Sep 16, 2019 at 12:00 AM David McGough <kb4fxc at inttek.net> wrote:
> 
> >
> > This is very strange behavior. When the audio issues are occurring, do you
> > see any kernel error messages?  From a bash command prompt, use the
> > "dmesg" command to see the kernel/console messages.
> >
> > A marginal or faulty 5V power supply would be my #1 suspect. A reboot
> > radically changes the power supply load, which might temporarily snap it
> > back to proper operation (I have experienced this with a wall wart
> > supply)...OR, perhaps some type of ground loop or RF/noise getting into
> > the low-level analog audio.....I have experienced ground loop noise that
> > comes and goes.
> >
> >
> > 73, David KB4FXC
> >
> >
> >
> > On Sun, 15 Sep 2019, Alessio Sacchi wrote:
> >
> > > Thanks David. Got some samples converted.
> > >
> > > Restarting asterisk did not solve the proble. Rebooting the PI fixed it
> > > twice - after the first reboot I described above, it started degrading
> > > again and I had to restart the RPi again after about 24 hrs. We are now
> > > running since 3 days from that restart and audio is still good. But most
> > > importantly no - stopping and starting asterisk was not helping at all.
> > >
> > > Alessio
> > >
> > > On Sat, Sep 14, 2019 at 2:05 AM David McGough <kb4fxc at inttek.net> wrote:
> > >
> > > >
> > > > Alessio,
> > > >
> > > > Interesting that rebooting the RPi3B fixes the issue. Does stopping and
> > > > starting Asterisk also fix the issue?
> > > >
> > > > To convert uLAW (pcm) files to wav files, one way is with the sox
> > > > software, like:
> > > >
> > > > sox -t ul -c 1 -r 8000 allstar_audio_file.pcm  output_file.wav
> > > >
> > > >
> > > > 73, David KB4FXC
> > > >
> > > >
> > > > On Fri, 13 Sep 2019, "Alessio Sacchi via ARM-allstar" wrote:
> > > >
> > > > > Danny, David
> > > > >
> > > > > I could certainly take a generator up to the site on my next trip.
> > > > Speaking
> > > > > of adding a tone, I remember I used a "generate continuous tone" in
> > ASL
> > > > > usb-tune tool. That helped me at quantifying the distortion back in
> > my
> > > > ASL
> > > > > testing days.YOu kept it running for seconds and the tone broke up
> > > > > intermittently eventually.
> > > > >
> > > > > There's a quite important update on the degraded audio issue. I
> > continued
> > > > > my controlled manner testing by disabling things one by one.
> > > > Specifically I
> > > > > had a script checking gpio to sense loss of mains power - killing it
> > > > > doesn't change anything. I eventually tried a reboot which fixed the
> > > > > problem immediately. But the issue come back in the same form less
> > than
> > > > 24
> > > > > hours later. Users reported this thing gets worse over time. Another
> > > > reboot
> > > > > fixed it again. I am back doubtful of my power supply, unless you
> > have
> > > > > other ideas. Am I wrong thinking 3 ports could be too many for a
> > single
> > > > PI
> > > > > 3B?
> > > > >
> > > > > I'll procure some uLAW recordings as soon as I can listen to them.
> > What
> > > > do
> > > > > you reckon to play the uLAW files with? I tried  importing them as
> > raw
> > > > > files with audacity with no luck.Maybe I am configuring it wrongly
> > during
> > > > > the import.
> > > > >
> > > > > Thanks,
> > > > > Alessio
> > > > >
> > > > > On Thu, Sep 12, 2019 at 5:46 PM "Danny K5CG via ARM-allstar" <
> > > > > arm-allstar at hamvoip.org> wrote:
> > > > >
> > > > > > Alessio,
> > > > > >
> > > > > > It sounds like you need to do some testing in a controlled manner
> > to
> > > > > > eliminate as many unknowns as possible.
> > > > > >
> > > > > > Do you have a service monitor? Generate input RF, add a tone,
> > record
> > > > it.
> > > > > > Is the distortion still there?
> > > > > >
> > > > > > Danny
> > > > > > K5CG
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "ARM Allstar" <arm-allstar at hamvoip.org>
> > > > > > To: "ARM Allstar" <arm-allstar at hamvoip.org>
> > > > > > Cc: "Alessio Sacchi" <iz4efn at gmail.com>
> > > > > > Sent: Thursday, September 12, 2019 9:55:51 AM
> > > > > > Subject: Re: [arm-allstar] Distorted audio (sampling?)
> > > > > >
> > > > > > Hi David, thanks. I will immediately begin recording with uLAW and
> > > > find a
> > > > > > few samples to share.
> > > > > >
> > > > > > >>is the same noise heard on all your AllStar connected receivers
> > or
> > > > just
> > > > > > one?
> > > > > > All connected receivers. To clarify:
> > > > > > - A distorsion over a signal coming from the 50MHz port is heard on
> > > > > > echolink, on 70cm and on 23cm
> > > > > > - Distorsion can happen regardless of the input ports - except for
> > > > audio
> > > > > > coming from echolink. Meaning that signals coming from each of the
> > > > radio
> > > > > > ports can be affected by distorsion. Audio from echolink seems to
> > be
> > > > pushed
> > > > > > out clean at all times.
> > > > > >
> > > > > > Alessio
> > > > > >
> > > > > > On Thu, Sep 12, 2019 at 4:01 PM "David McGough via ARM-allstar" <
> > > > > > arm-allstar at hamvoip.org> wrote:
> > > > > >
> > > > > > >
> > > > > > > BTW, I noticed that the dropbox .wav files are in the GSM CODEC
> > > > format.
> > > > > > > For diagnosing audio issues, I recommed saving the files using
> > the
> > > > much
> > > > > > > higher audio quality uLAW CODEC, rather than GSM. The negative
> > > > drawback
> > > > > > is
> > > > > > > that the files will be bigger, of course.
> > > > > > >
> > > > > > > To enable saving uLAW formatted files, in your
> > /etc/asterisk/rpt.conf
> > > > > > file
> > > > > > > node stanzas, add:
> > > > > > >
> > > > > > > archivetype=pcm
> > > > > > >
> > > > > > >
> > > > > > > 73, David KB4FXC
> > > > > > >
> > > > > > >
> > > > > > > On Thu, 12 Sep 2019, "David McGough via ARM-allstar" wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > Hi Alessio,
> > > > > > > >
> > > > > > > > To me, the distortion heard in your recordings doesn't sound
> > it's
> > > > > > coming
> > > > > > > > from the HamVoIP/AllStar software. My first suspicion is noise
> > on
> > > > the
> > > > > > > > receiver audio, which leads me to a question: is the same noise
> > > > heard
> > > > > > > > on all your AllStar connected receivers or just one?
> > > > > > > >
> > > > > > > >
> > > > > > > > 73, David KB4FXC
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > >
> > > > > > > ARM-allstar mailing list
> > > > > > > ARM-allstar at hamvoip.org
> > > > > > > http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
> > > > > > >
> > > > > > > Visit the BBB and RPi2/3 web page - http://hamvoip.org
> > > > > > >
> > > > > > _______________________________________________
> > > > > >
> > > > > > ARM-allstar mailing list
> > > > > > ARM-allstar at hamvoip.org
> > > > > > http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
> > > > > >
> > > > > > Visit the BBB and RPi2/3 web page - http://hamvoip.org
> > > > > > _______________________________________________
> > > > > >
> > > > > > ARM-allstar mailing list
> > > > > > ARM-allstar at hamvoip.org
> > > > > > http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
> > > > > >
> > > > > > Visit the BBB and RPi2/3 web page - http://hamvoip.org
> > > > > >
> > > > > _______________________________________________
> > > > >
> > > > > ARM-allstar mailing list
> > > > > ARM-allstar at hamvoip.org
> > > > > http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
> > > > >
> > > > > Visit the BBB and RPi2/3 web page - http://hamvoip.org
> > > > >
> > > >
> > > >
> > >
> >
> >
> 



More information about the ARM-allstar mailing list