More Unreasonable Podcast Stuff

I was hit pretty hard the last few weeks with the standard issue winter cold. I was quite surprised to see how little energy I had for working on anything after work. I certainly see the value in taking time of work even if it just means more energy for side projects.

Yakamo and I have continued to push out our podcast , with another episode appearing today. Our audio is getting better though you won't hear it in the most recent show as I did all of the editing with my backup audio.

Editing the backup audio showed some of the issues with mumbles recorder. It was a lot of trouble to keep my levels balanced, there seems to be gain correction on the mumble feed so my starting audio is super loud and it just tampers off.

Unreasonable Podcast Episode 0x03

So yakamo and I have been managed to do it again, the most recent episode of the unreasonable podcast , episode 0x03 appeared yesterday.

This episode should now be missing large chunks of silence and features a much deeper sexier voice for me. Turns out there were some config issues with my microphone. There were also some observation issues, I didn't actually listen to the whole show or check the waveform before doing the renders.

Should all be fixed now and it will sound silky smooth.

Or something.

Fixing rate issues with audio on FreeBSD

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

Unreasonable Podcast Episode 0x02

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.

Command line notifications

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"