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


HTML file for usbmic2

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



Records dual USB dongles 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



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



The 1st recording in 24 bit 48khz.

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


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

  • 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

    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.

View all 29 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