The ultimate vlogging mic

Recording the best headset audio in a portable form factor

Similar projects worth following
It's small size has made it primarily a bootlegging device.

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.  Recording directly on a phone was 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.


HTML file for usbmic2

x-xz - 2.92 kB - 08/28/2018 at 05:19



Stereo recorder without monitoring. Records from 2 USB dongles using raw alsa calls but can't play back.

x-csrc - 18.34 kB - 08/28/2018 at 05:18



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

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



Voice recorder with monitoring. Records 16 bit 48khz from a single USB card, using jack.

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



The 1st recording in 24 bit 48khz.

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


  • New microphone, ALSA calls, & O_DIRECT

    lion mclionhead02/23/2021 at 05:26 0 comments

    Using molex connectors for headsets has proven disastrous.  It may be they don't do well when they're frequently unplugged like audio connectors.  The TRS connector was invented over 100 years ago for telephone switchboards.  There was nothing special about the TRS connector's signal properties, so lions figured molex connectors would be more compact.  The molex connectors have been prone to dirty contacts & bad connections.

    There's nothing special about going back to a dual 3.5mm TRS connector for the microphone & speakers.  It would just involve money.  It would be bigger than the molex connector but not totally ruin the experience.  Dual TRS would allow monitoring stereo on a headset without microphones.

    There are other connectors besides molex, like SATA & USB.  

    The single channel vlog mic finally got ported away from jackd to its own ALSA mmap calls & the performance instantly improved.  The latency got a lot lower & it was less prone to losing buffer synchronization.  Jackd had a problem of too many buffer handovers above the basic ALSA mmap buffer & latency from its socket interface.  Socket interfaces are so bad at latency, it's amazing audio software has gone exclusively to socket interfaces like pulseaudio & jackd.  ALSA has long supported mixing multiple programs in the kernel, where it's not as prone to latency as a userspace mixer.  Meanwhile, old programs like X11/Xorg/Xwayland long ago abandoned socket interfaces to get lower latency.

    With direct ALSA mmap calls, the smallest buffer possible with the general pro's in full duplex mode dropped to 144 samples.  

    The microphone was upgraded to a microphone extracted from a Zoom H2.  The sound quality was spectacular for an electret condenser, rivaling Tucker Gott's microphone.  The Zoom recorders were definitely a high point in electret condensers.  It's disappointing such good microphones aren't available from digikey.  

    Finally, the file I/O got moved to O_DIRECT to reduce dropouts.

    Helas, the 1st vlog with this setup was a disaster.  There were a lot of buffer overruns, so the ALSA buffer size has to be stepped back up.  The wind noise was terrible.  Only a few ramblings about lions were audible.  The larger zoom microphone didn't allow as effective a wind screen.  It was a stock wind screen that looked like Tucker Gott's.  

    The next question is if the stereo version can monitor by fusing the 2 cards in userspace & if the 2 versions can reboot each other.

  • Zoom F2, Tentacle Sync Track E

    lion mclionhead02/17/2021 at 20:33 0 comments

    Around 3 years after lions started developing the vlogging mic, the industry finally introduced the same concept at over 10x the price.  The industry offerings don't have any software interface, just physical buttons & no VU meters.  They're a bit bulkier, using TRS connectors & AA batteries.

    The mane thing they started pushing was 32 bit floating point.  They're recording on simultaneous ADC's with different gain levels & fusing the output much like an HDR photo.  There's still a limit to dynamic range, imposed by the microphone's internal preamp & the bias voltage.  Only 20 more years until Japanese camera makers finally discover 32 bit floating point.

    The generalplus has only ever been useful at maximum gain, so 32 bit floating point wouldn't buy anything. A way to start recording & adjust headphone volume without a phone would be useful.  Pairing the phone over wifi, firing up the browser, & worrying if wifi is leaking into the audio is extremely slow.

  • New enclosure

    lion mclionhead02/17/2021 at 06:27 0 comments

    The confuser was slightly rewired & wrapped up more thoroughly.  Lions couldn't think of how a 3D printed enclosure would be any better than packing tape.  It has to be as compact as possible.  It's still going to go inside a good old arm band with a battery.

    Lions measure the CPU temperature with /sys/devices/virtual/thermal/thermal_zone0/temp

    It shows 51C when it's warmed up, even though it smells like magic smoke.

    Molex connectors have been disappointing as audio connectors.  Not sure why the ages old TRS connector does such a better job.  It takes a lot of fiddling to get a good microphone connection out of a molex.  This application doesn't have enough room for an XLR.

    Discovered the UART RX has to be floating for it to boot up, otherwise it gets stuck in the bootloader.  This is the opposite of the STM32 which needs UART RX to be grounded.

    The lion kingdom has had growing disappointment with raspberry pi's as audio recorders.  There's a lot to think about, to get them to boot, defeat wifi interference.  There's a long startup time while waiting to see if they work or need another reboot.  They always have buffer overruns.  They take up a lot of space & burn 300mA, even in the zero W size.  The wifi has never been as reliable as hoped.  Transferring files is super slow.

    There have been thoughts of going to a more expensive STM32, SD card, surplus LCD, audio codec chip, analog trimpots, USB file transfer, single record button, but lions just don't make enough recordings to go beyond the minimal raspberry pi.

  • Switching between mono & stereo

    lion mclionhead01/24/2021 at 08:45 0 comments

    The lion kingdom revisited this project after 3 years, to do single channel vlog recording again.  Apparently, there was no way for jack to play back while recording from 2 soundcards, so that's why monitoring was dropped for recording stereo.

    Using the same board as a voice recorder with monitoring & a stereo recorder without monitoring ended up requiring 2 different executables.  To record a single channel with monitoring, you have to run jackd & then usbmic.c

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


    This picks 1 of the 2 soundcards, as specified with the -dhw:1 option.  Jackd handles the full duplex I/O in what was deemed to be a very efficient loop.

    To record stereo from 2 soundcards without monitoring, you have to kill jackd & run usbmic2.c.  Jackd was abandoned for stereo in favor of using raw alsa calls.

    This requires a /root/.asoundrc file to merge the 2 soundcards.

    root@raspberrypi:~# cat .asoundrc
    pcm.merge {
        type multi;
        slaves.a.pcm hw:1
        slaves.a.channels 1;
        slaves.b.pcm hw:2
        slaves.b.channels 1;
        bindings.0.slave a; 0;
        bindings.1.slave b; 0;
    ctl.merge {
        type hw
        card 0

    It still may be possible to record stereo with monitoring, thereby allowing a single executable to be used for stereo & mono.  Some ideas are directing playback to the virtual merged device instead of a single soundcard or using raw alsa calls for playback instead of jackd.  Unfortunately, there's no reason to monitor stereo recordings.  That mode wouldn't be used for vlogging.

  • Upgrading to stereo

    lion mclionhead08/28/2018 at 05:20 0 comments

    For a good time, record stereo using a raspberry pi, dual USB sound cards, & a tiny 2 port USB hub. The USB hub was made of a 4 port stick, ground down to 2 ports.  Get alsa to fuse the 2 dongles into a single virtual device with a new .asoundrc file.  The 2 dongles are hw:1 & hw:2.

    pcm.merge {
        type multi;
        slaves.a.pcm hw:1
        slaves.a.channels 1;
        slaves.b.pcm hw:2
        slaves.b.channels 1;
        bindings.0.slave a; 0;
        bindings.1.slave b; 0;
    ctl.merge {
        type hw
        card 0

    Get jackd to record from the virtual device by passing the -Cmerge option after the -dalsa option.

    /root/jack2-1.9.12/build/jackd -P70 -p16 -t2000 -dalsa -Cmerge -p256 -n3 -r48000 -s &

    jackd also accepts a -P option after the -dalsa option which is supposed to redirect playback to either of the 2 dongles, but this causes it to crash.

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

    So there is no monitoring when recording from 2 cards.  The executable which does the magic is

    Portable stereo recording is not as easy as it was 30 years ago. The Zoom products are not as compact as a vintage recording walkman. Dongle sized sound cards only record a single channel.

    The lion kingdom briefly owned a Marantz PMD-430 costing $500. It fluttered but with a belt replacement & the best tape formulation was probably better than minidisc. The lion kingdom didn't know about belt replacement & was told anything was better than tape, so traded it for minidisc, which led to years of bad lasers, cracked gears, & ATRAC artifacts.

    The same Marantz still shows up on ebay for much lower prices, but there's absolutely no point in a professional tape recorder now. The raspberry pi is very slow when recording 2 soundcards, the SD card is prone to corruption, but it has wifi monitoring & 7 hours of storage.

  • The 1st vlog

    lion mclionhead05/20/2018 at 00:04 0 comments

    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.

  • The wifi solution

    lion mclionhead04/22/2018 at 01:41 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 was the static address the home router gave it, but what if there was no home router?  Did it use,, ... 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.

  • 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;
            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.

View all 33 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

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