The ultimate vlogging mic

It dropped around 3 seconds of audio at one point.  Jack glitched & had feedback for a few minutes.  400mAh battery died after 90 minutes.  It definitely gives up a lot to have the convenience of a Linux system.  With the low power jumper on, there wasn't any wifi interference.

As suspected, it was the cable bunching up near the antenna which destroyed the last recording.  Further proved the noise went away if the txpower was reduced to 0dbm.  It was at 31dbm during the fateful day & there was a lot of confidence a commercially produced sound chip was immune to it.

After much procrastination, it was decided the best option was a jumper to lower the wifi power & a flag on the web app showing the current setting.  WIFI actually still works marginally at 0dbm, but you need 31dbm to transfer audio files & there's no way to set it without a physical interface.  Could have made it only lower the power during recording, but it would have been impossible to monitor without recording. 

A similar thing should be done to the 4 channel recorder, after some more procrastination.  Of course, this doesn't defeat interference from the phone.  

For 20 minutes, the lion kingdom sat there trying to get the cheap cell phone to connect to the PI.  It would connect to the access point, but the browser couldn't connect & it couldn't start recording without the browser.  The thought occurred that the static proof bag was impairing wifi.  Then there was the idea that the cheap phone was flogging it to download gigabytes of adware or there was a bug in the web server.  

Very dire thoughts came, as the lion kingdom began to write off the whole exercise.  It was to be expected, for an untested gadget in a very demanding application.  Then came a fleeting thought that 10.0.2.100 was the static address the home router gave it, but what if there was no home router?  Did it use 10.0.2.1, 10.0.3.100, 10.0.3.1 ... it came up & the Jack was giving a signal!

Another glitch was the debugging header was a mess, nearly contacting other solder joints on the PI.

After rebooting to download the recording, noted Jack once again failed & it wasn't sending data to the client at all.

Unfortunately, while it did record the entire show, it captured an extreme amount of WIFI interference & the maximum levels were down at -10dB because of the lack of gain in the Generalpro.  It was almost unintelligible & an ordinary cell phone would have done a better job.  Would almost recommend a 3rd audio project just for bootlegging.

Taping the microphone to the human body probably ground looped it.  After shifting position later in the recording, the noise went away.  It was a disappointing failure, but probably not enough to kill the Generalpro for its headset role.  In the historical context, the recording is still huge.  Can only imagine it would be like hearing Wernher Von Braun giving a lecture in any quality, today.  

https://cdn.hackaday.io/files/284961219172864/bootleg01.mp3

A bootlegging opportunity presented itself before the 4 ch recorder was ready, so it was time to reconfigure the vlogging mic for just a microphone.  Whacked some day job parts together to make a 4 hour battery.  It was now obvious that it needed a connector for interchanging microphones.  After many decades of suffering with TRS connectors, it's become obvious that all audio connectors would be better off as pin headers.  

In testing, Jack has issues initializing.  Didn't download the audio, but it normally requires restarting the client program to capture any audio.  The system becomes less reliable as the voltage drops below 5V.  At 3.5V, it sometimes can't initialize wifi but does eventually initialize.  The audio initialization seems to be less reliable below 4.2V.

Recorded a 3.5 hour file & the battery was dead at 3.4V.  There were another 10 minutes to transfer the file over wifi.  The battery was rated at 960mAh, but the charger said it only used 816mAh.  So it took roughly 230mA.

Of course, this gadget requires a phone to control it & the phone lasts much longer than 3 hours.  It makes more sense for a video, since the part on camera is much smaller than a phone.  For a bootleg, why bother carrying around a phone to control this gadget when you can just record on the phone?  Because theoretically the fixed gain is going to sound better.  The phone was designed to record a voice up close, rather than an auditorium.

The trick with jackd is it can't start from any init or systemd scripts.  It appeared to always shut down before initializing the dbus components or the audio driver.  Delaying the script to 2 minutes after starting up still didn't start it.  Although the cause will never be known, the evidence is dbus has a protection blocking access from certain non interactive commands.

Eventually rebuilt jackd on the pi, with most of its options disabled.  Dbus was one of the disabled options.  It finally started from /etc/rc.local.  Getting it to work without any dropouts required a period of 256.  It used 10% of the CPU.  Would say converting to floats & back is a negligible impact.  The starting command was:

/root/jack2-1.9.12/build/jackd -P70 -p16 -t2000 -dalsa -dhw:1 -p256 -n3 -r48000 -s

It definitely needs

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

to boost the speed to 1Ghz.  Any ssh or scp command made it drop.  Gave it a static address on the router with this addition to dhcpd.conf:

host usbmic {
        hardware ethernet    b8:27:eb:70:fa:bd;
        fixed-address        10.0.2.100;
        max-lease-time       84600; 
}

The power consumption when recording was now 200mA at 4V.

Sound quality was compromised, but the result was something that fit into the smallest arm  band, without a battery.  Shrinking the plastic bag should free up enough space to cram in a battery.

Soldering headsets is the modern technique.

Hot glued the BCM4343 to get it to last longer.  There are still chances the battery could become unplugged & the pi could overheat.  A larger arm band & bigger battery connector would still be smaller than a phone.

The mane thing Jack does to achieve low latency is set the optimum buffering parameters for full duplex.  The best parameters for a USB card came from 

https://wiki.linuxaudio.org/wiki/raspberrypi

OSS used the terms "fragment" & "sample" to define its buffering, with all the fragments combined to form a "buffer".  Audio programs read or wrote 1 fragment at a time.  ALSA uses the terms "period" & "frame" with audio being processed 1 period at a time & all the periods combined to still form a "buffer".  The unfortunate terms are probably because ALSA was designed by a Hungarian speaker.  

Unfortunately, a scratch built audio monitor using mmap is not as easy as Jack makes it look.  There are some gnarly buffer alignment problems.

jack_lsp shows the ports which can be passed to jack_connect

These commands route the microphone to the speakers through the DSP:

jack_connect system:capture_1 system:playback_1

jack_connect system:capture_1 system:playback_2

This disconnects a route:

jack_disconnect system:capture_1 system:playback_1

This command records from the microphone:

jack_rec -d -1 -f test.wav system:capture_1

jack_thru creates a dummy signal processor & 4 ports which are shown on jack_lsp which can then be connected.  You can see how a signal processor can be built up from the command line.

Developing jack programs requires 'apt-get install libjack-jackd2-dev'

The jack_thru example is in the jack2 source code.  Compiling thru_client.c requires merely 'gcc thru_client.c -ljack'  The source filenames have nothing to do with the executable names.

Unfortunately, it promotes all the samples to floats.  

Made another self monitoring headset board.  It only needed 1 bodge.  There were no 1 meg pots in the apartment.  They said 501 instead of 105.  So a more easily sourced 100k pot was put in place of the 10k & a fixed 1 meg resistor was put in place of the pot.  This too suffered from noise.  It would need an active regulator & some spacing from the antenna.  The generalpro has a lot going on to mitigate noise & it all has to be redone for anything else.  It gets about as bulky as the 24 bit ADC.  Fortunately, the new board can be used elsewhere.

So it went back to software monitoring.  After further review, Jack uses mmap for audio buffering, so it might achieve lower latency.  It came preinstalled on the pi.  Start the server using:

jackd -P70 -p16 -t2000 -dalsa -dhw:1 -p128 -n3 -r48000 -s &

The key parameters are -p128 & -n3.  -p128 creates 128 frames per period.  -n3 creates 3 periods per buffer.

Run the following to configure the gain settings:

amixer -c 1 set 'Mic' playback mute 0 capture 100 cap

amixer -c 1 set 'Speaker' unmute 100

Then, run qjackctl to connect the microphone to the 2 speakers.  The speakers successfully monitored the microphone using the software routing & the latency was low enough to be useful.  

It doesn't render any text at all, but enough of the interface worked to get into the patch bay, drag & drop the microphone onto the 2 speakers.  At least it proved a technique involving mmap could bring down the latency.   There aren't enough examples to integrate Jack into the web app as easily as just calling the mmap routines.  The only program which seems to use it is Ardour.  

Made a simple booster for the headphone output & the myth was busted.  No, you can't amplify the headphone output.  It's much too noisy.  The microphone "playback" is at microphone level when amixer says it's 100%.  Amixer still scales it when it's below 100%.  It needs 100x gain from the booster to be minimally audible for a middle aged, flat broke lion.  

The noise was what killed it.  Disconnected the booster input & most of the noise went away, so it's partially the virtual ground & partially the line output.  Haven't tested it, but if all inputs are constant, a high speed op-amp shouldn't amplify power supply noise.

The final way to save the Generalpro is to wack the self monitoring headset board in.  Its only downside is having to use a pot to adjust monitoring volume instead of the web app.  For the advantage it gives beyond a phone, the generalpro is proving much less worth it than the full 24 bit ADC.  It might even be worth stepping the 24 bitter back up to 96khz. Any kind of 96khz audio would require buying a TOSLINK DAC for the amplifier.  It's probably not worth hacking that, even though the parts are around.

The decision was made to make another audio recorder out of the Generalplus dongle, because there's no way of knowing which one is better without building 2 completely functional units.  

The Generalplus has a setting for monitoring the mic, but it's an inaudible level, so you have to make a software loopback.

Full duplex playback does work, because it's designed for a headset.

The Generalplus only takes stereo for playback.

Using aplay & arecord to monitor the microphone creates too much latency.

Using libasound directly creates less latency, but still an unacceptable delay.  Getting acceptable latency requires reducing the record buffersize.  At 512 samples, there are lots of playback underruns, but recording hasn't overrun yet. Making the playback buffer bigger than the recording buffer is unacceptable, since it would increase the latency. Latency was an unsolvable problem with the CP33 project.

Installing another board to monitor the mic in hardware is now the only option. If it only amplifies the General's output, it needs to be tested for the noise penalty & playing files would then always be noisier.  If it amplifies directly from the microphone input & mixes in the general's output, it's exactly what was done before for phone headsets.  It's a less compact board & requires turning a pot but is still far smaller than the AK4524.  That web interface may be overvalued & filled with buzzwords, but it's a lot more convenient than turning pots.

The 3rd option of boosting the mic signal enough to hear it from the general's monitoring path would add too much noise to the recording.

The USB audio dongles arrived.  They weren't CM109's, but showed as simply Generalplus.  They were probably the GPD8106B.  With the mic gain at 0, the audio editor clocked it at -75dB peak noise & -85dB RMS noise.  The worst case for the CM109 was rated at -76dB.  Moreover, the noise wasn't RF.

The Generalplusses were infinitely smaller than the custom solution & the noise would be undetectable, compared to the microphone noise.  The problem with the custom solution is many days passed without an enclosure emerging for it.  The gain control would probably be adjusted only once, but it was a pain to access.  The noise floor would never be reached, in the field, without shielding.

Setting gain with alsa requires 1st getting the card number with 

aplay -l

Then passing the card number to the -c option, along with a bunch of other options.  

amixer -c 2 set 'Mic' playback unmute 13 capture 24 cap

sets the microphone monitoring to 13 & gain to 24