It has been mentioned by a friend that my voice in the recent unreasonable podcast episodes is much higher than it is in reality. Of course for the first few episodes he just said 'your audio is fucked' which didn't help me resolve the issue at all.

With the detail that pitch was off I knew where to start looking, the pitch issue was present on both the audacity recording and the mumble back up. The audio rate for the microphone and audacity where both the same, 44.1kHz.

The last thing to check was the audio sub system on FreeBSD. I read the snd man page and it pointed me to a few sysctl knobs that I might be able to tweak. I also checked the man page for usb audio and found this little notice in the bugs section:

BUGS The PCM framework in FreeBSD only supports synchronous device detach. That means all mixer and DSP character devices belonging to a given USB audio device must be closed when receiving an error on a DSP read, a DSP write or a DSP IOCTL request. Else the USB audio driver will wait for this to happen, preventing enumeration of new devices on the parenting USB controller.

 Some USB audio devices might refuse to work properly unless the sample
 rate is configured the same for both recording and playback, even if only
 simplex is used.  See the dev.pcm.%d.[play|rec].vchanrate sysctls.

 The PCM framework in FreeBSD currently doesn't support the full set of
 USB audio mixer controls.  Some mixer controls are only available as
 dev.pcm.%d.mixer sysctls.

vchanrate is a per device sample rate that can be controlled by a sysctl, toggling the value showed me the problem. With the rate at the correct 44100 my deep voice poured out of my microphone and into a file.

$ sudo sysctl dev.pcm.4.rec.vchanrate=44100
dev.pcm.4.rec.vchanrate: 48000 -> 44100

So far yakamo and I have been consistently able to record our unreasonable podcast , the third episode, 0x02 came out on Monday.

Recording for the show has been okay so far, we have been using mumble to run our call while producing local recordings with audacity and a backup recording with mumble itself.

The back up recording has already been useful, I selected the wrong channel in audacity and didn't notice the flat waveform coming out of my mic. There has been a lot of trouble with the audio streams going out of sync making it bothersome to edit in audacity. I hope that is related to my own rate issues on my local recordings. I will see when I get to editing 0x03.

I think the show will probably get closer in structure to other shows as we go, I have already given in and you will hear intro noise in episode 0x02 . You will probably also hear us saying the name of the podcast a lot, that should remind people what they are listening to.

JCS was interviewed on the latest episode of Garbage , he spoke about his app pushover . Pushover is an Android, iOS and mac app that works with a service backend. You can send notifications to pushover via simple api (you can just use curl) and the notifications are delivered to your devices.

This is awesome, I can set up pushover on my phone, a client on my build machine and get alerts when builds are complete. No more checking while a build finishes, instead I can get notifications directly on my pebble via pushover and the pebble app.

Looking through the app directory I found the command line tool ntfy . ntfy is really easy to set up and use, for pushover you need a simple .ntfy.json (with a real user_key) like:

{
    "backends": ["pushover"],
    "pushover": { "user_key": "fjaudfaufjkjdufdaskufdaskfjads"}
}

You can then send messages with ntfy or send the result of a command:

$ ntfy -t "Test" send "This is a test message"
$ ntfy done false

By default ntfy will set the message title to the user@host, but the -t flag can override this. ntfy supports other backend services and a 'linux' backend. I though the linux backend would tie into the same thing as notify-send, but that wasn't the case. I need to figure out how those tie in.

I have to run FreeBSD builds with root privileges, I didn't want to give a tool like ntfy root access. I wrote a small alias to send the result of the previous command.

alias buildres="if [ $? -eq 0 ]; then ntfy send 'Build passed'; else ntfy send 'Build failed'; fi"

Via the ReverseEngineering subreddit I found that vim's built in :X encryption mode can be pretty easily broken. I didn't know that vim had anything built in to encrypt files, in hindsight I should have expected some functionality.

Looking into the vim documentation on on Encryption shows that most of these methods aren't recommended for use. It also looks really easy to accidentally destroy a file using vim. If you do not decrypt the correctly you get a vim buffer filed with encrypted noise, if you save that buffer you destroy the original file.

I have been using vimwiki in a git repo since August last year. Vimwiki is a really simple markdown style wiki, the features are really limited. There is some markup, links and that is all. It has been filling all of my needs perfectly. I would like to be able to encrypt the wiki files so I could have a little more peace of mind, but with a little searching I haven't found anything that has the utility I need.

I could write something myself that worked well with both git and vimwiki, but I don't really want to subject my personal files to my own bugs. If you know of a solution to encrypting files in git repo or integrating with vimwiki that would be really helpful.

For some reason I have been recording a lot of audio on my desktop recently. I also saw a conversation in irc about how to simply record audio from a microphone on FreeBSD.

I hoped I was going to find a super simple OpenBSD style solution to capturing samples, but I wasn't able to dig anything out. I did play with cat for a little while, but nothing useful came from it.

Audacity is the tool I have been using to record long sessions the most. Audacity is now probably the foss standard for doing audio editing/production and it has been really stable for me. On FreeBSD it has been rock solid so far if a little heavy weight.

ffmpeg is an audio and video swiss army knife and can be used to capture video from webcams and audio from capture devices. The only issue I have had with ffmpeg on FreeBSD is that lame support is not built into the default packages.

ffmpeg can be used to caputure audio from a source:

ffmpeg -f oss -i /dev/dsp -vn -ab 128k test.wav

Sox is the ultimate tool for handling audio, a long with the two front ends play and rec you can do most operations on an audio stream. Sox can built with codec support for a ton of formats. It is quite simple to use sox to convert different bit formats of sdr capture files with sox.

Rec can be used to caputure audio from a source:

rec -c 2 test.wav