Alesis Multimix 8 USB FX Timeout Error 0x0005

June 25, 2020 at 4:28 pm (computers, moan, music) (, , , )

This is another one of those “lots of people must have found this error but no-one seems to know the answer” queries…

We’ve acquired an Alesis Multimix 8 USB FX mixer with a USB interface to the PC.  If you just plug this in, it is found by Windows and all is good.  But there is a driver on the Alesis website which implies there is additional functionality.

However, when you try to install it you get a “Timeout Error 0x0005” half way through, and this seems pretty common on the Internet, but suggested fixes involve uninstalling, registry cleaners, and all sorts of mucking about which could easily lose you an afternoon.

Except no-one seems to mention that there are two Alesis Multimix 8 USB FX mixers – the USB FX and the USB 2.0 FX.  The former (that we have) does not require a driver, it seems to stream a single audio channel to the PC using the standard Windows drivers with no additional installation required.  The latter, does require a driver, as I think it can stream the different channels independently to the PC.  By the way, if you have the USB 2.0 FX it is strongly recommended that you don’t plug it in until you install the driver and it asks you to.

Now quite why the developers couldn’t have spotted this on installation and pop up a nice friendly “Hey, looks like you’ve plugged in the confusingly similarly named Multimix 8 USB FX which doesn’t need a driver” I don’t know.  Instead the installation is left looking for the USB 2.0 FX, which quite naturally doesn’t exist, so it simply times out.

So, if you get this error – make sure you are using an Alesis Multimix 8 USB 2.0 FX which needs a driver – and not the Alesis Multimix 8 USB FX which doesn’t.

I haven’t looked into the difference between the two in detail, so if you are planning on buying one, it would be worth having a look to see if you need the USB 2.0 FX or the USB FX.


Permalink Leave a Comment

Minimus usb and LUFA

May 21, 2012 at 7:20 pm (maker) (, , , )

Once I’d got the basics of programming the Minimus sorted out (see my last post), I was keen to see if I could get a USB stack compiled and running on it, so I could then actually think about talking to my code running on it from a PC.

Well it turns out that the LUFA stack “knows” about the minimus and it doesn’t take much to get the demo applications running.  LUFA is an excellent set of code, supporting both raw USB access and many common classes.

I downloaded and extracted the code base into my project area and sought out the sample keyboard class application (Demos/Device/ClassDriver/Keyboard).

There is a top-level project file (lufa.pnproj) for Programmers Notepad which gives you the full set of code – all demos, library, drivers, etc. Navigate to the demo application you wish to build and then you can “make all” in that directory and built the entire library and code.

Before that though, I had to configure the Makefile for the minimus. The documentation is very good once you know a little about what you are doing, but it took me a while to understand enough of the ‘getting started’ documentation to get the stage where I had running code.

The following had to be set to work for the minimus:

MCU = at90usb162
F_CPU = 16000000

Then I had to tailor the example a bit for the minimus.  Key things to do:

  • Keyboard.c: In SetupHardware() comment out Joystick_Init() – as there is no joystick on a minimus
  • Keyboard.c: Same in CALLBACK_HID_Device_CreateHIDReport() – comment out the line with the call to Joystick_GetStatus()
  • Keyboard.c: Then I commented out all the code examining JoyStatus_LCL in the same function and was left with a single test – the check for the switch
  • Keyboard.h: Comment out the #include <LUFA/Drivers/Board/Joystick.h> line

After some thought, I decided what I wanted was to generate a Windows-L key sequence (thinking it would be entertaining to force the ‘change user’ screen to show).  For what I had to lookup the USB modifier term for the Windows key, which had a peculiar name – it turns out it is the HID_KEYBOARD_MODIFIER_LEFTGUI modifier key …

My final CALLBACK_HID_Device_CreateHIDReport() function was thus as follows

  USB_KeyboardReport_Data_t* KeyboardReport =

  uint8_t ButtonStatus_LCL = Buttons_GetStatus();
  uint8_t UsedKeyCodes = 0;

  if (ButtonStatus_LCL & BUTTONS_BUTTON1)
    KeyboardReport->KeyCode[UsedKeyCodes++] = HID_KEYBOARD_SC_L;
    KeyboardReport->Modifier = HID_KEYBOARD_MODIFIER_LEFTGUI;

  *ReportSize = sizeof(USB_KeyboardReport_Data_t);
  return false;

Note that the sample code allows for up to 6 keys to be returned in one go. I’m only using one for this test.

At this point I was ready to compile everything and give it a go.

Unfortunately when configuring the Makefile, I had got distracted before changing F_CPU (I couldn’t remember the clock speed and was about to look it up when kids happened).  So for my first build, after loading and running, nothing happened at all.  It just so happens that nothing works when F_CPU is the default of 8000000.

After quite a bit of head scratching, I returned to the Makefile and remembered that I hadn’t looked up the clock setting.  Thankfully setting it correctly and another build (after a ‘make clean’ to be sure) sorted it all out.

There was some benefit to this problem though – I got to navigate a fair bit of the LUFA code and standard AVR definitions trying to decode macros for watchdogs, definitions for LEDs and so on.  Some key bits of information I learned:

  • The standard AVR definitions I’d need were installed with WinAVR in c:\WinAvr-version\avr\include\avr directory. Key files being io.h and wdt.h
  • The definitions for the minimus from the LUFA libraries were installed in <LUFA Root>\LUFA\Drivers\Board\AVR8\MINIMUS with the main (well, only actually) files being Buttons.h and LEDs.h
  • The key bits of LUFA I was using were in <LUFA Root>\LUFA\Drivers\USB\Class\Device

So once it was running my code, Windows obligingly went through its “detecting new device” routine and recognised the minimus as a USB HID keyboard device and at that point, pressing the button triggered the Windows-L response I’d been looking for.

And that was it.  I now have a successfully running USB stack on the minimus.  My very many thanks to Dean Camera at  The LUFA code is just great – so many possibilities!



Permalink 2 Comments

Odd USB Devices

June 3, 2008 at 9:05 pm (odds) (, , )

Someone pointed this out to me recently … and it got me wondering about weird USB gadgets. Well, as usual, the Internet provides.


Permalink Leave a Comment

Trade shows and USB keys

April 25, 2007 at 10:06 pm (computers, security) (, , )

I was at InfoSec Europe 2007 this week, and came away with the usual assortment of squidgy things, pens, toys and a couple of trees worth of leaflets, etc. One interesting extra was 2 USB keys and a USB hub.

It struck me that an interesting way to target companies that are likely to include people who recognise that they could be improving security, and that definately need to be improving their client-side security, would be to give out auto-running, ‘phone home’, USB keys at, say, a computer-security related trade show 🙂

(Of course CDs would work too, but USB keys are nicer for people to have, and more likely to be actually plugged into a PC!)

Maybe I’m just too paranoid for this business.

I got to see Bruce Schneier presenting though.


Permalink Leave a Comment