Linux/Open and open source software...

About once every 12 months I take one of my machines and install various Linux/BSD distributions, mostly because I have a soft spot for UNIX like OS's. Pretty much every time I go through the same set of things that end up with me turning the machine off and leaving it off. It's usually a combination of hardware incompatibilities and poor development tools.

This time however I had an agenda, I wanted to re purpose the machine in question as a media player, the original plan was to install XBMC and be done with it.

OK so I go grab the latest Ubuntu disks, install it, which I have to say was extremely pain free. I install the xbmc package, and play a video, unfortunately it doesn't appear to respect the timer and plays the video very quickly with skipping audio. Hmmmmmm, so I dig around on various boards, the general consensus is it's a pulse audio issue, what's odd is that mplayer doesn't display the issue. OK I remove pulse from my system and try again, same thing. Hmmmmm, I decide to try it with the NULL sound driver to verify it's actually audio and the video plays at the correct speed.

I figure maybe it's a fixed issue, so I pull down the latest build via svn, rebuild XBMC, same issue.

In a fit of frustration I install Fedora and have more or less the same issues. I start looking at the video player inside XBMC, discover what a massive app it actually is. All I want is something basic that lets me browse videos from my server and play them.

So I decide screw it, I wonder what it actually takes to write a video player using some of the open source components all the others seem to leverage. the answer turns out to be not very much the ffmpeg libraries provide most of the infrastructure, and it's relatively easy to get something up and running in a day or so. I did have some issues with the libswscale library, it has a bug where by it incorrectly swaps pixels when it's doing a 1:1 scale and isn't using the MMX routines, but I could patch that locally (I'd submit a fix, but it looks to me like the original author very much intended it to do what it's doing, and I have no idea why).

OK so all's well that ends well?

Not really at some point I decided to take my basic video player and use OpenGL to put the pixels on the screen, all of a sudden I have this issue where I get repeating sound fragments, and since I'm syncing video to the audio clock choppy video.

My first thought was the audio thread starving, but for that to happen the app would have to be eating all the CPU and it's not.

I discover that as I make the target widow smaller it stops being an issue, I know it's not a rendering related issue though, because if I remove the clocksync and just let the video run, it runs faster, so I'm not limited by drawing pixels. So I waste a lot of time looking at various aspects of my code ruling them all out.

So I come up with a new theory, the audio driver is missing interrupts when the onboard video is busy for extended periods. To test my theory I try subdividing the single large polygon I'm using for display into 1024 small polygons and miraculously the issue goes away. Even doing a glClear is sufficient for the issue to return.

So now I'm at a loss, I can't easily establish if this is a hardware issue, or a driver issue, and if it's a driver issue, if it's a video driver or an audio driver problem, or even a chipset driver issue.

FWIW I believe it's an audio driver issue, I've tried the code with both an A2DP sound driver and I've put in an external sound card, and as long as I'm not using the internal sound card (NVidia MCP51) the issue doesn't present. I've tried setting various driver options with modprobe without success.

So I'm left with ignore the issue and just leave the sound card in there (which irritates me because it should work). Or start digging through the ALSA driver code which I really don't want to do.

Ugh!

Minor DX1App update

Updated DX1 programming App

I made a small change to the way multikey macros are processed to fix an issue I was seeing with my own use in WOW. It turned out to be an issue with the plugin I was using, but the fix is the right thing to do.

Added support for 64bit App switching, I've had to use the process name instead of the app name for the switching code. You need to create a ".pgm" file in the Macro directory (not the app's directory) named processName.pgm where process name should be the name of the process. Usually the process name is the same as the app name.

I've tested this with the 64 bit version of media player, by creating a file called wmplayer.pgm in the Macro directory.

The issue is that a 32 bit app (which the programmer is) can't look at the process info for a 64 bit app. It's not trivial to build a native 64 bit version of the programming app because of the data marshaling for the native windows calls, so I've added the work around.

DX1 App update

I've updated the driver and source code drop.
This drop only affects the app and the source code, no changes to the driver.

I've fixed the problem when mapping the 9 and Z keys from the main keyboard. The code that built the table that converted the windows key code to driver HID codes had a couple of typos.

New 32 and 64 Bit Ergodex DX1 drivers

As promised a 64 bit version of the DX1 Driver and app.
This drop also includes support for multikey macros and various fixes.
Also included is the source code for the programming App, hopefully someone with more desire can build something a bit more user friendly.

This was more work than I expected, the code was easy enough to fix, but I had a somewhat subtle error in my ".inf" file that was only causing an issue on my 64 bit machine. It's also possible it was causing issues in the 32 bit version so you might want to grab the new drop.

At some point I renamed a number of classes in the application, and I don't remember if it was pre or post the last drop, that invalidated saved macros and key bindings, so you might want to delete any if you have a problem running the App.

http://www.polygonhell.com/DX1Release3264Bit.zip

Bah Humbug

The delivery of my stuff was delayed by the inclement weather, so it'll be the new year before I can get an updated drop of the driver out.

Quick Update

I've had a number of requests over the last week or so for 64 bit binary versions of the Ergodex driver, and the possibility of a source code drop.

I'm currently in the midst of relocating to the Seattle area, and I don't have access to the computer with the driver source code on it. I should have access after the 22nd.

Once I have access to the computer I'll build and release a 64 bit version along with an updated programming app, as I've made several fixes since the release here.
I will also release the source code for the programming app at that time.
I will not release the source code to the driver itself until I've had a chance to poor over the licensing restrictions and figured out exactly what license I can release it under.

Ergodex DX1 Driver Vista

You can download a binary release of my Vista 32 DX1 driver below

DX1 Driver

If there is any demand I guess I can compile a version for Vista 64 but I have no way to test it currently.