Learning Through Failure:: September 2014

September 8, 2014

How To Embed Code Into A Blog Post.

The code you will need:

This code needs to be copied and pasted just after the <head> in the template of your blog. When looking at the overview of your blog click on 'Template' then 'Edit HTML' then find the first <head> (you can use Ctrl+F to find it very easily).

As you can see from the code above the 'Brushes' Cpp, Css, and Java are included, however, you may add any of these as well: Other Brushes

Thanks to Alex Gorbatchev for making and hosting the files to make this work.
Some credit goes to Craftyfella as he has instructions however I was not able to copy and paste his code and get it to work (I needed to delete a line or two).

September 7, 2014

About Me:

Reginald A. Aryee

Electrical and Computer Engineer

Graduate of Norwich University

Linkedin Profile

Technical Interests:

Programming

GPU computation

Desktop and networking hardware

Tinkering with OS settings.

General Interests:

Baking cookies and desserts

Running

Podcasts

Economics

Logistics

Quote's and sayings that describe me:

Life is too short, so why can't we all just get along?

Perfection is impossible to achieve, but that doesn't mean we all can't strive for it.

"Higher standards!" - Something that I started as a joke to a friend who loved collecting old computer parts, but has now become a personal motto.

September 5, 2014

The Podside Project: The Inevitable Roadblocks

This ended up being a very long post (I was on a roll) so there is a TL;DR at the bottom. PS sorry for the word wrapping issues, I don't know what's going on.

I named this blog Learning Through Failure which can mean a couple different things depending on one's perspective. I always defined 'Failure' in this context as hitting a roadblock which usually, in my experience, happens preventing any and all progress for a project, not necessarily a design flaw which would mean the existing progress should literally all be scrapped, but instead a vital feature, function, or step in the design cannot be completed due to lack of information, experience, patient issues, etc.

Right now I am facing three key roadblocks which are: audio device selection, multiple audio device selection, and MP3 encoding.

The main feature of this project is suppose to be capturing the audio from a microphone and the PC audio output to combine them into one audio stream, however, the first problem I encountered was of course one of the things I would have thought to be the easiest, capturing the PC audio output (link). What is very interesting about Java's handling of audio is although you can very easily find and display all of the PC's audio input and outputs (VSJQueryMixer.java code), you can only capture a single generic device of a specific type. As Matthias Pfisterer puts it, “Asking for a line is a rather tricky thing...first, we have to say which kind of line we want. The possibilities are: SourceDataLine (for playback), Clip (for repeated playback) and TargetDataLine (for recording)” (Source). The next step is to grab the audio from the TargetDataLine by calling:

TargetDataLine line;
DataLine.Info info = new DataLine.Info(TargetDataLine.class, format);  // format is an AudioFormat object
if (!AudioSystem.isLineSupported(info)) {
   // Handle the error.
   }
// Obtain and open the line.
try {
    line = (TargetDataLine) AudioSystem.getLine(info);
    line.open(format);
    } catch (LineUnavailableException ex) {
            // Handle the error.
            }

Although this code came from Java's tutorial site and is indeed a simple implementation it is the same implementation I continually find while looking for how to record audio with Java.  The problem with this is there is no way to specify a specific audio input or output to listen to or record from (aka 'info' contains the information of all audio I/O and using 'info[2]' to specify a specific I/O to listen/record from did not work for me, more below). This implementation confuses the hell out of me especially when you can use the code:

for(Mixer.Info mixInfo: mixInfos) {
    Mixer mixer = AudioSystem.getMixer(mixInfo);
    support = “, supports “; 
    if (mixer.isLineSupported(sourceDLInfo))
       support += “SourceDataLine “;
    if (mixer.isLineSupported(clipInfo))
       support += “Clip “;
    if (mixer.isLineSupported(targetDLInfo))
       support += “TargetDataLine “;
    if (mixer.isLineSupported(portInfo))
       support += “Port “;
    System.out.println(“Mixer: “ + mixInfo.getName() + support + “, “ + mixInfo.getDescription());
    }

(Source)

to clearly show all of the devices which in turn means Java can see them and yet you cannot pick a specific one. This is not an issue at all for most or at least simple programs which just want the microphone audio (the default input device) or the speakers for example, but this issue leads to the enviable problem for those more complex programs which want access to multiple inputs (which is what I am trying to do) or multiple outputs, or to record a specific device like the PC's audio output (again what I am trying to do). (I did something no one else has, link)
The third roadblock of MP3 encoding is a first for me. The MP3 codec is patented and therefore requires permission (aka $$$, MP3 Licensing Site *Side note: This site is pretty sketchy looking like it's from the 1990's.) to incorporate in a complied program. As most people (who know anything about audio file formats) would say the MP3 format is not only the most used format but also very space efficient, especially when compared to the WAVE format. However, because of the rules put in place by the patent holder Oracle is not allowed to include native MP3 support into Java unless they pay some form of fee. This of course  is good for the owner but of course makes it harder for developers and also results in less  code being shared due to avoiding patent lawsuits and people leaning toward free alternatives.
So basically I have had a very hard time finding a way to encode audio to the MP3 format but also legally implement MP3 encoding into my program, but it can be done.

TL;DR

Roadblocks can not only be speed bumps but obstacles which make us realize fundamental flaws in our logic or code design. For this project I have encountered 3 so far: audio device selection, multiple audio device selection, and MP3 encoding. The first two I never dreamed would be any kind of issue and MP3 licensing is a pain because it means Java does not have native support for it thus there is barely any example code and if you wish to use MP3 encoding in a commercial program you have to be creative to avoid patent infringement.

Epilogue: Stuff I found while writing this post which might be helpful in the near future.

The Podside Project: The Design

I started my design the same way I always have (and how most of people my experience level would) by determining the different phases that the program would need to go through which meant my code was looking something like this:

import _____;
Main{
void Main(str() args()){
     // Find the audio I/O.
     .
     .
     // Select the audio inputs.
     .
     .
     // Record input streams.
     .
     .
     // Collate audio.
     .
     .
     // Convert to MP3.
     .
     .
     // Save to hard drive.
     .
     .
     // Close broadcast stream and shutdown.
     .
     .
     }
}

This is the way I was taught to code and there is not anything wrong with it, however, it is obvious once the code becomes long enough all of the sections start to appear to 'blend together' just because there is just so much code to look at.

During a recent trip I got to speak with a cousin of mine whom I rarely get to speak to and he, being a programmer himself, suggested an alternative method which blew my mind. He first stated programming would be much more simplified (in terms of readability for updating somebody else's code) if the code were to read like a English sentences in somewhat of a bullet-point format. To which of course I agreed. He then blew my mind when he said that it is actually possible and actually rather simple and easy to do. He then gave an example of a program/script he was writing to filter email which he described as:

English Main File Function Definition File(s)

Get mail. Get_mail(); Get_mail(){

Check mail for ____. Check_mail_for(____); _______;

Move to ____. Move_to(____); }

Check_mail_for(string a){

_______;

}

Move_to(string b){

_______;

}

In school of course I was taught how to make functions/methods but I never was I told you could use them to (1) simplify my code nor (2) by using them to simplify and and naming them in a clear way resembling a clear and concise thought or action (not just Check_mail for example) I could increase the readability of my code exponentially.

This of course inspired me to redesign the layout and functionality of my code to look like this:

 import ____;
 Main{
     Display and select I/O();
     Capture inputs(input1, input2);
     Collate audio(input1, input2);
     Convert to MP3(Collated audio);
     Save audio(Collated audio, filename);
     Push to server(Collated audio, web address);
     }

Each function is defined in its own separate file which helps with readability and what I did not realize at first was because all of the specific tasks are defined as functions I can fully test the code by simply commenting out any unwritten or unfinished functions! Of course if you just have everything in one large file to test specific parts you would need to comment out entire sections of code instead of just one line.