Question

Hello,
my Audiobox1818VSL worked fine in the past even with an old Windows XP and with ubuntu Linux, all out of the box, and on different computers, and with different versions of ubuntu (12.04, 14.04, 14.10). More than one year ago, the problems started. Switching the Samplerate kicked the Audiobox out of the system (not available anymore as USB device), and it wasn't synced anymore (LED red). Switch off the Audiobox, wait a quarter or more, switch on again, box is syncing and is available, but works only on 48000 Hz, switching Samplerate kicking out the box again. I tried many different distributions of Linux (opensuse, Fedora, Debian), which sometimes worked with the box only on 44100 Hz, but switching Samplerate produced always the same: box kicked out of the system, switch off, wait, switch on. Now installed an old Windows XP which worked with the box fine in the past in a Virtual machine on Linux, installed Studio One there, and get the same: switching Samplerates kicks the Box out of the system.

So I tried to Upgrade Firmware downloading Audiobox VSL 1.2 (with the box I got VSL 1.1), installing in Windows, starting, and the program upgraded firmware. Still the Audiobox only works on 48000 Hz, and switching Samplerate kicks out the Audiobox. But the procedure became shorter: I only have to wait 3 or 4 minutes after switching off the box until it is syncing again (blue LED) when I switch it on. So now I know that this issue is NOT really a problem of the hardware, and NOT of the software, but it likes to be a firmware problem - firmware upgrade changed things.

What can I do now? I don't have a PC with Windows 7 or higher and I dont have a MAC. Is still anything possible?

I send this question to technical support too, awaiting an answer from any helpful person.

Answer 1

Using Windows 7 x86 or x64, install Universal Control 2.1 and update the firmware to 1.48 which is the latest version.

The firmware updater in AudioBox 1.2 / 1.3 had issues that put the firmware update into various states that included resetting it back to version 1.0 if the update didn't take correctly. This was all fixed with the release of UC 1.8 and later versions. At the time of this writing, UC 2.1 is the latest release. It will get your firmware updated correctly and as the 1818VSL is a class compliant device that works very well in OS X, you shouldn't have any further troubles in Linux after doing the update.

Answer 2

Hi,

I'm having the same problems! The box worked like a charm for years with windows 7 64 BIT. I was only using 44.1 kHz all this time. I tried to change the sample rate to 96 kHz a week ago and since then everything went mad. I tried every version of AudioBox and Universal control, the Firmware update didn't work and the Audiobox has been crashing every other minute since, making very loud noises while crashing.

I tried to update with windows 10 and on different computers, nothing worked...

HELP!

Answer 3

Hello,
now I tried Windows 7 SP1 64bit with actual version of Universal Control. Update Firmware worked well, but switching Samplerates kicked the Audiobox out of the System. LED red, no contact with the card possible. I have to swith Power off, wait 20 minutes or so, switch on again before the box is back in the system. but every time I try to switch Samplerate the same happens.
Are there any ideas what to do now?

Answer 4

You need to change it using the universal control. Uninstal everything (AISO, Audiobox soft, VSL soft etc)... reboot, then instal the universal control, reboot and you should be good to go. People recommend using the AISO all 4 one drivers, but I just use the presonus AISO and it works fine. Once you change the audio setting on the control panel, be sure to also change it in your DAW to match. That's what I had to do, works OK for me.

Answer 5

Some general thoughts on firmware handling (not presonus specific):

Those kind of problems are pretty usual. We'll have to keep in mind that firmware is also just software, and it can have bugs.
New versions always have a risk of introducing regressions, which might hide from testing and be very hard to track down.

Therefore, users/operators always should have the option to quickly roll back to older versions and even roll out approved
veresions (that they have tested well in *their* environment). Firmware should not be bundled into user applications or
hardware drivers, but separate entities, that are just called by drivers or applications. Linux already has a good subsystem
for firmware handling (never heared of Windows having something similar).

--mtx