[AudioI] Zero card stopped working -- will order new hardware to troubleshoot

Tue Mar 9 02:17:14 UTC 2021

After many weird issues I finally have the  project working.  (The only
thing left to do is to automate the startup and make sure it comes back
after power failures).

A pi zero with audioinjector installed takes nature sounds from a
(preamplified) stereo mic and sends digital audio over wifi to a raspberry
pi 2 with ethernet that with the help of soundcard outputs the audio to a
sonos "Connect" and from there it is available for playing in the house
whenever/wherever desired.  This pi 2 is also equipped with a several
terabyte hard drive that can store a week of stereo audio for excerpting
later if wanted.  (i  ended up using  ROTTER for this, which requires JACK
(in this case JACK2).)

For a while after giving up on simple arecord/aplay/ssh I was trying to use
Jack2 and tried zita-njbridge for transport across  the lan but was never
able to get this to work.   Jack's  32 bit floating point internal
processing and synchronization capabilities are overkill for my purposes
anyway

I found the trx package which solved my problems.
http://www.pogo.org.uk/~mark/trx/streaming-desktop-audio.html.   Note that
this requires compiling on your pi but this isn't hard.

This worked for me (over wifi on the transmitting end)  without making any
efforts to tailor the Pis for real time operation -- but they are not doing
anything else.   (I did shut down hdmi to reduce power draw, as I am
running headless)

Regarding the instructions for using the trx package, since I am using the
audioinjector as a capture card on the transmitting pi, snd-aloop is not
needed.  No arecord/aplay or rec/play is needed -- just the tx and rx
functions from the trx package.

The ticking that I couldn't get rid of when using arecord/aplay via ssh
(or even just arecord monitored on the Audioinjector earphone) is
completely gone.  I never did figure out exactly where it was coming from.
For a while I thought it was periodic surge in power use by the PI
associated with wifi or something feeding back through the various
opamps but separate supercapacitors  on the overall 12v in, the pi/audio
injector supply, and the microphone and preamp supplies did not fix the
problem.  I never did figure out the cause but am glad it is working now.

The lack of a "mapping ok" report in dmesg with the latest update/upgrade
of RaspiOS Buster seems to have been a complete distraction and non-issue.

Another weird thing that I discovered is that the PI Zero W went  crazy
when it was too near to a Unifi Wifi Access Point...  this actually was the
problem that made me think the project had died last week.

I also overcame the problems I had been having in using sox -- i needed  to
explicitly use the -d alsa  option and set the AUDIODEV and
AUDIODRIVER=alsa  environment variables.

Also it took me a while to figure out that when alsamixer wouldn't open it
was because of problems in my asound.conf file (I had a device = 0
statement in a ctl device, which seems to clobber it) , and that you  can't
use an alsa pcm named jack because there is one in the distro somewhere.

Thanks for putting the audioinjector zero out there -- it's just about
perfect for this project.

On Wed, Mar 3, 2021 at 8:01 PM Tom Garwin <tom.garwin at gmail.com> wrote:

> Thanks, Matt --
>
> First regarding your helpful comments and questions:
>
> 1) I am running RaspiOS lite on the pi zero.  It doesn't seem  to have
> pulseaudio, unless it's installed under some other name.  ("sudo apt-get
> remove pulseaudio" reports it's not installed)
> 2) the alsamixer settings were correct and had worked before.
> 3) I had tried the line bypass but couldn't know whether the board audio
> chain was at fault or whether it was not being set by the software via the
> pi.
>
> I had fastened on the dmesg not including the "mapping ok" line as an easy
> diagnostic for whether things were working.   But in fact this seems to
> have been introduced by some update (via sudo apt-get update/upgrade) after
> the 1/21/2021 OS release -- a clean install showed success by this criteria
> with the new card and I think also the old one but a clean install followed
> by update/upgrade reverted to the previous behavior with the new card...
> This was true on a Pi Zero and a previously lightly used model 2B that I
> had around.  I'll attach the dmesg results from the two software versions.
>  I don't know enough to decipher them.
>
> Once I got over the distraction of the software and the dmesg reports, I
> found that in fact the audioinjector zero card had been damaged -- the old
> pi zero records audio with the new card with either version of the OS, but
> the old card doesn't work.
>
> I am not out of the woods yet.  I have a new problem and have narrowed
> down the current version of a previous one.
>
> Both problems relate to using  an approach I found somewhere on the
> internet for setting up a remote mic.  I am using it to send ambient
> (nature) sound from a remote outside location to my room audio system so we
> can hear outside noises without opening the window when it's 20 below.
> This requires a high dynamic range and low noise floor to hear distant
> birds, coyotes, etc. I use a stereo powered condenser mic intended  for a
> camera and a 2 stage opamp preamp  (Rod Elliott  p88 )
>
> This is what I was using for the sound transport over wifi and ethernet:
>
> arecord -c 2 -f dat -t raw - | ssh pi@[local ip address]  aplay -c 2 -f
> dat -t raw -Dhw:sndrpihifiberry -
>
> The new problem is that somehow there is more than a one second delay in
> the transported sound compared to what is being recorded. Presumably it's
> made a large fifo buffer for some reason.     Perhaps this has to do with
> changes on the receiving pi that I made when trying to diagnose the earlier
> problem.
>
> The persistent problem that I thought I had licked is that there is a
> tickatickaticka noise in the sound.     I thought this was from the
> wireless and by separating the mic and preamp from the Pi and
> audioinjector i did seem to get the noise down to zero -- based on what I
> was hearing via the audioinjector headphone jack and the line bypass.  But
> the noise reappeared when using arecord  (and was even worse when I tried
> "arecord  ... - " without piping it anywhere.  I could hear the noise in
> the audioinjector headphone output as well as in the transported sound.
>  Putting the audioinjector several inches away from the pi with a piece of
> grounded aluminum between the two did not reduce the noise.   Clearly I
> need to investigate further but this seems to be either some sort of
> digital artifact or rf feedback from the PI's digital operations back into
> the audioinjector card.
>
> I may try the sox equivalents instead of  aplay and arecord -- but I
> haven't had great luck getting sox to run yet.
>
> On Wed, Mar 3, 2021 at 2:03 AM Matt <matt at audioinjector.net> wrote:
>
>>
>> On 1/3/21 12:51 pm, Tom Garwin via People wrote:
>>
>> I had finally declared victory over extraneous noise in my remote
>> microphone prototype set-up and was prettying up the power and signal
>> wiring allowing a powered stereo microphone and opamp preamp to be
>> separated from the pi/AI zeros -(-wifi or clock cycles may have been
>> causing interference in the powered mic)   -- but then  the AudioInjector
>> zero card stopped processing sound.
>>
>> Its failure was accompanied by very strange things so it may be the Pi
>> Zero that failed (or both) rather than the AudioInjector.  I may have not
>> taken adequate precautions against electrostatic shock to the boards.
>>
>> I feel for you, electrostatics and unknown failures are terrible.
>>
>>
>> Specifically a set of commands to record the sound on one pi and send it
>> via SSH and aplay it on another stopped working.   I could SSH (by wifi)
>> into the first pi and could ping the second pi and even ssh from the first
>> pi into the second pi so this was strange.  They are both on the same
>> network with a unifi edgerouter with no intervening firewall so that wasn't
>> the problem.
>>
>> After several reboots ssh was working normally again but the sound on the
>> pi zero was not..   dmesg shows a set of errors that seem to  relate to
>> voltages not being present --using default regulator (or something like
>> that) and there is no final  message saying the mapping is ok.  I cannot
>> capture a sound file that has anything but silence in it even though I know
>> the AI Zero board is getting appropriate input.   I also cannot get it to
>> play anything to its output.  Nevertheless the aplay -l and arecord -l show
>> entries for the audioinjector and it is the only soundcard in the system.
>> Alsa settings are what they were before.    Of course I did not look at the
>> dmesg output when things were working so I don't know if this is really
>> different.
>>
>> Are you sure you've setup the mixer settings as required to select the
>> line input ?
>>
>> Normally Linux doesn't have a huge set of monitoring tools for the
>> standard LDO regulators on soundcards - some of the power chips have i2c
>> ports which are more sophisticated.
>>
>> One idea which may be helpful is to enable the "line Bypass switch" in
>> the alsamixer settings. This will route audio input directly through to
>> audio output - at least then you can double check the input signal is
>> coming through as expected.
>>
>>
>>
>> So either I did something to fry the pi or the board or the both, or in
>> trying to fix the problem I updated the OS to a configuration that no
>> longer works.,
>>
>> I suppose I could start over with a fresh os install and see if that
>> works but at this point I am guessing it is a hardware issue and the pi
>> zero and the AI zero are inexpensive enough relative to my time (and my
>> inadequae software skills)  that it's best to just try a fresh AI zero with
>> a different raspberry pi before trying a new software install.
>>
>> Remember with the latest Raspbian OS they have a non-robust pulse audio
>> setup. Some people remove pulse audio entirely. You can also make sure you
>> select the audio injector sound card using the
>>
>> aplay -D hw:0
>>
>> type of direct device naming methodology.
>>
>>
>>
>> Will keep this list posted on the results -- Only posting this now on the
>> off chance someone else has had the same symptoms.
>>
>> please do.
>>
>>
>> --
>> Tom Garwin
>>
>> --
>> Checkout the community email list :https://lists.audioinjector.net/mailman/listinfo/people
>>
>>
>
> --
> Tom Garwin
>
> (202) 669-4228 (cell)
>
> PO Box 5359
> Whitefish, MT 59937
>
> tom.garwin at gmail.com
>

-- 
Tom Garwin

(202) 669-4228 (cell)

PO Box 5359
Whitefish, MT 59937

tom.garwin at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.audioinjector.net/pipermail/people/attachments/20210308/2a0f4260/attachment-0001.htm>