Close
0%
0%

The ultimate vlogging mic

Recording the best headset audio in a portable form factor

Similar projects worth following

Experiments in vlogging with a headset & robot cam showed it's worth the investment in a more portable solution for recording audio.  The need for VU meters, transport controls, & counters requires a wireless connection to a phone.  Phone recordings were horrible.  The AGC brought up the background noise & clipped the voice.  The phone & extra circuitry for monitoring was bulky.

The lion kingdom long dreamed of a wireless headset just to capture audio & monitor it.  A small FM transmitter would be able to record the microphone but not send audio from the phone back to the headset. Despite every effort, there is no easy way to record from a bluetooth headset. The Goog has blocked recording from a protocol designed to make phone calls because of wiretapping laws.  Commercially available, wireless headsets with full duplex audio are obscenely expensive, bulky, & have lousy sound quality.  The only easily accessible ones have 1 speaker.

The most compact solution is a raspberry pi zero W reading from an ADC & writing data to an SD card.  The same board sends monitoring output back to the headset.  It's really hard to justify anything besides a raspberry pi zero W for every single project, nowadays.  That board only uses 200mA & is the cheapest solution for everything.

A microcontroller is only necessary for converting the ADC's output to an SPI slave. An analog pot is the easiest way to adjust microphone gain. The ADC/microcontroller board would be dedicated just to the headset & interchangeable with a 4 channel version for less portable use. The 4 channel version would have digital pots for line level inputs, another section for monitoring, maybe mic preamps for 2 channels, lots of transistors for a patchbay.

It's important to use a CODEC or ADC specifically designed for recording audio rather than a bare ADC.  Audio codecs have the lowpass filtering & DC offset correction you need to avoid aliases.  What is the point, when a tiny soundcard for a raspberry pi is virtually free? It's about getting the best possible sound quality from the headset microphone.  Past experiences with microphone inputs on computer soundcards were horrible.

The recording system could be implemented entirely in the headset if money was unlimited, but we're financially limited to an external board.  This also allows the highest sound quality.

bootleg01.mp3

Segment of the 1st bootleg, with interference left intact.

mp3 - 608.83 kB - 01/13/2018 at 05:27

Download

usbmic.c

What does the magic in the final version. Records 16 bit 48khz from a USB card, using jack.

x-csrc - 16.21 kB - 01/09/2018 at 05:24

Download

first_recording.flac

The 1st recording in 24 bit 48khz.

flac - 3.27 MB - 12/27/2017 at 02:24

Download

  • The wifi solution

    lion mclionhead2 days ago 0 comments

    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.  

  • Bootleg #1 results

    lion mclionhead01/13/2018 at 05:27 0 comments

    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

  • Bootleg #1 begins

    lion mclionhead01/12/2018 at 03:21 0 comments

    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.

  • Jack completion & final assembly

    lion mclionhead01/09/2018 at 05:21 0 comments

    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.

  • Jack basics & floating point

    lion mclionhead01/08/2018 at 01:25 0 comments

    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.  

  • Headset monitor busted

    lion mclionhead01/07/2018 at 06:30 0 comments

    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.  

  • Headphone output busted

    lion mclionhead01/06/2018 at 06:56 0 comments

    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.

  • There is no knowing before doing

    lion mclionhead12/31/2017 at 01:50 1 comment

    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.

  • USB dongle testing

    lion mclionhead12/30/2017 at 01:14 0 comments


    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


  • More grounding

    lion mclionhead12/29/2017 at 23:16 0 comments

    Decided to go over all the grounding on the circuit & separate any more digital grounds from the analog grounds.  Lions were previously good at separating motor ground & speaker ground from signal ground, but it seems there was never a notion of separating the signal ground into analog & digital grounds.  After much effort separating the 5V into analog & digital sections, the ground was assumed to be an infinite pool of electrons since it wasn't moving anything.

    Past ADCs were used for gyros, battery voltage, & photodiodes.  It was good enough to ground them to the digital ground.  The luck was over with 24 bit audio.  Even sharing 2cm of a wire with digital ground introduced noise.  All hifi gear has separate digital & analog grounds.  Despite flood filled ground planes, much effort is spent separating grounds, making sure the ground paths don't have any bottlenecks.

    There were a few places where a digital component had multiple grounds & shared an analog ground path on 1.  The STM32 had 1 more digital ground sharing an analog ground.  With these all moved to the star, the meter dropped right near -90.  The final problem was the wavy DC offset.  It was too low in frequency to ruin a datasheet, but it would greatly limit the amount of possible gain in software without clipping.

    1/262144 waveform:

    Suspected the op-amp ground was drifting away from the ADC ground, so put a 4.7uF in the audio wire.  It greatly reduced the DC drift.  The ADC datasheet says it already has a highpass filter in its audio input, but it's rated at a 1Hz cutoff.

    Anyways, the audio editor has an ancient tool for measuring sound level.  It showed the ADC having -85dB noise peaks & -99dB RMS noise.  13.8 bits & 16 bits based on the ENOB equation.  To be sure, 2 channels are averaged & only sampled at 48khz to get those figures.

    The formal calculation isn't as warm & fuzzy as counting the pixels in the waveform.  If the noise spans 12 pixels in the 1/262144 waveform, just divide 262144/12 & convert to binary to get the number of bits it can resolve.  It can resolve 14 bits + some fraction of a 15th bit.  The problem is the ENOB equation takes away 1.76bits for a quantization handicap.

View all 27 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates