image description

Forum Index » Profile for in2mu5ic » Messages posted by in2mu5ic
AudioBox VSL 1818 » My experience with the 1818 with Sonar X1d on a Dell Dimension E520 » Go to message
Just a follow-up to my original post regarding the lowest latency I could get with a buffer setting of 256. It's a non-issue.

I'm a guitarist first and foremost and do quite a bit of my guitar tracks these days line-in with my Line 6 HD POD -- sounds so good and is just so versatile for recording. I still love my Orange and Soldano for live playing though! Anyway, so I'm monitoring through the interface roundtrip through Sonar and back out through monitors and there's no weird feel or noteworthy delay of *any* sort when recording along with existing tracks(no effects on the recording track). My previous interface had hardware monitoring so I never had to even think about this before. Turns out I don't have to worry about it now either.

Thumbs up to PreSonus.
AudioBox VSL 1818 » 1818 VSL works with current versions of Ubuntu(Linux) and ALSA » Go to message
See my previous post for my experience in getting the 1818 to work with Sonar X1d Producer.

My workstation is a dual boot setup with one hard drive dedicated to Windows and my complete DAW running Windows 7 and another hard drive dedicated to running Ubuntu 12.04(Linux). I'm a software engineer by trade and musician by hobby so I need to have Linux. I've got a comfy workstation setup so I like to use the single machine for my DAW and other stuff like work, web browsing, etc. But... when I'm in Linux I also want to have sound through my main audio interface for listening to music, news, etc. through my monitors and not have to deal with additional hardware and speakers that will work with Linux.

When I recently switched to the Presonus interface it was because it was reported that it would work in Linux with newer versions of ALSA. So, I just wanted to report that it does in fact work with Linux, too -- with some minor tweaks and caveats.

It is recognized by ALSA in Ubuntu and you can go into alsamixer and control the muting of channels and volume. It is *not* recognized by the pulseaudio libraries so it won't appear in the volume control applet as a device to control on the menu bar at the top of screen -- but don't fear it's still recognized by ALSA. I won't go into details but the Linux audio subsystem world is kind of confusing to say the least and you need to dump pulseaudio.

To get things to work I disabled pulseaudio audio server from starting(you could also just uninstall it). This is essential since if pulseaudio is running it will not work. Browse Google for various ways to disable or uninstall it -- it's simple. Then I went into the alsa base conf file and set the USB audio device to occupy the 'default' position of 0. Basically changing every reference at the bottoms of:


so they're all 0 like:

<stuff before here>

options snd-usb-audio index=0
options snd-usb-caiaq index=0
options snd-usb-ua101 index=0
options snd-usb-us122l index=0
options snd-usb-usx2y index=0

<stuff in between here>

# Intentinoally loaded as first soundcard
options snd-usb-audio index=0

Then I rebooted and ran gstreamer-properties from the command line. This sets up the audio device for all things like playing mp3s, videos, etc.

When the gstreamer-properties UI comes up choose ALSA as the input and output and Default as the device for each also -- DON'T CHOOSE USB.

Press the test button for playback and you should hear a test tone. I was pleasantly surprised when I did!

Anyway, then I just control the volume from the hardware knob on the interface(which is close by underneath my display). Alternately you could go into alsamixer and control it there from the OS.

Now you can play mp3s, YouTube videos, etc. and hear the sound.

NOTE: If you ever reboot and for some reason you hear no sound and running 'aplay -l' doesn't list the AudioBox device, simply run the following command to reload ALSA and it'll pick up the interface:

sudo alsa force-reload

Then run 'aplay -l' and you should see it listed. You can then go about playing music and such again.

I've also heard that folks have got it working for recording using jack audio server and doing recording with applications like Ardour. I've not done any recording myself in Linux -- just playing back audio. So, I can't help there. I couldn't honestly recommned any interface for serious audio work in Linux. It's just too undocumented and unsupported.

Good luck!

AudioBox VSL 1818 » My experience with the 1818 with Sonar X1d on a Dell Dimension E520 » Go to message
*** PC Hardware ***

Dell Dimension E520 with Core 2 Duo E6700 processor @ 2.66Ghz
Windows 7 x64 Basic Home Edition
500GB Western Digital 7200 RPM HD with 16MB Cache
Dell 2407FP Display

*** Audio Interface ***

PreSonus 1818VSL

*** DAW ***

Sonar X1d Producer

The only upgrade is the OS which I upgraded some time ago from Vista to 7 and the hard drive which I replaced for a 500GB model about 2 years ago. Everything else is stock from Dell -- AND STILL RUNNING GREAT!

*** My Experience with the 1818 Set-Up ***

I started off by downloading and installing the upgraded V1.2 software and upgrading the firmware immediately -- I didn't even try the older version first. Everything went well and I rebooted. The 1818 was well recognized and all audio ins and outs were shown In Windows. I didn't even really adjust any of the ASIO settings in VSL at the time either -- didn't know they were buried in the VSL at the time actually.

I fired up Sonar and opened up a fairly complex completed project(for me anyway) with about 18 tracks, loads of track effects, busses, master bus effects, etc., and pressed play. It played -- and sounded great. So at this point I'm pretty excited.

Next I go into Preferences and check out the driver settings to check out the latency. It's high. Waaaaaaaaaaaay too high for any realtime monitoring work of any sort -- on the order of something like ~90ms round trip. So I click on the ASIO configuration button in the Sonar Preferences and nothing launches. Odd. So then I go to VSL and see that the ASIO bit depth and buffer settings are indeed there and set at 44.1 and 2048. So I bump the buffers down to 512 to start -- knowing I'll want to get to 256 or even 128 if I can -- but it's a good start. I shut down Sonar go back in and press play. I get about five seconds of audio and then a complete audio engine stop -- bad. Not a click or pop. The audio engine just stopped with a pop-up error message. So I scratch my head and then decide to fire up the Windows resource monitor and check out the CPUs. With no audio playing, CPU1 was absolutely spiking at 100% utiliziation for probably a solid second or more like clockwork every 8 seconds or so. The graph was literally up and down and up and down and up and down... well, you get the idea. So I move the ASIO buffer setting back to 2048 just to get a new CPU baseline, fire up Sonar, and play... again CPU1 hitting 100% every 8 seconds or so whether or not I'm even playing anything -- but at least with this many buffers it's clean. So I shut down Sonar and continue to observe the CPU metrics. Turns out they calm down and the spikes stop when I close Sonar. So I fire Sonar back up and try all sorts of different bit depths, ASIO buffer settings, turning various driver settings on and off in Sonar wrt to buffering and such -- all to no avail.

So, at this point I'm frustrated and hit the forums. I start seeing references to this 'Safe' and 'Normal' and 'Fastest' settings and thinking that my driver doesn't have that. So, I uninstall the 1.2 driver and install the legacy one. I reboot and fire things up and take a look at the default ASIO settings now. Hey! There's a new option for these settings! It's on Fastest by default so I figure I'll try it at the 2048 buffer setting just for kicks. I go into Sonar, same project, press play and same deal. There's clean playback. So I fire up the CPU meter and again, CPU1 is pegging every 8 seconds or so and there's no way I'm going to be able to go lower. Grrrrrrrr. I go back to the ASIO settings in VSL and change it to 'Normal' and try again -- I don't even bother trying to lower the buffer setting since I know it would only get worse. So I go back into Sonar and it plays OK on 'Normal' performance setting. Next, I check out the CPU performance in the Windows monitor and much to my surprise it's way down. There's still the same general curve of the up and down but the peaks on CPU1 are maybe at 55% on average and 70% at the highest(rare though). Not to mention, now CPU2 is showing more of a load as well. I'm not sure if that's a consequence of this change or not but it was observable. Anyway! So now I go back and start dropping down the buffer setting, 1024 works! No glitches or pops or engine stoppage. Yes! 512 works! Same deal! 256 works! I check the CPU performance in Windows and all is still well. No pegging on CPU1 and averaging peaks around 55%. Now I'm getting really excited as I've got the latency down to ~15ms round trip -- according to Sonar Preferences anyway. No pops whatsoever on this complex project at 256. So I try 128 -- which would give me ~10ms round trip according to Sonar -- and for a while it's going pretty well but then the occasional pop or click starts but no outright audio engine stoppage. At this point I'm pretty happy though and realize that's about the best I'm going to get -- especially with a project loaded like this. I've get to record with buffers at 256 to see how it really "feels" but I'm positive that if I plan things out correctly that I could certainly drop it down to 128(maybe even 64) to do some recording of more critical work with real-time monitoring of existing tracks early on when the track count and effects counts are low.

RE: CPU1 pegging. It's know that while most DAWs try to take advantage of multiprocessors, most still end up taxing one CPU much more than the other. I've always seen this with Sonar X1(even previous versions of Sonar) evern with my previous interface. So, that CPU pegging of CPU1 was basically a non-starter since Sonar really counts on it to be there for use.

Upgrade of video card(interesting):
After this was all said and done and working I decided to upgrade my video card to a very basic 1GB 8400GS series NVIDIA card -- to replace my now ~4 year old stock NVIDIA 256MB 7300LE. I saw one for 40 bucks at the store I was browsing and decided to give it a go. Should only help, right. Wrong! I installed the card and drivers and Windows is working great. I fire up Sonar and I got total audio engine stoppage again -- CPU1 was pegging every 8 seconds or so worse than I had ever seen it and even CPU2 was showing more activity. Not again! So I start thinking and decide to remove the video card and put the existing one back in. Perfect again. No CPU issues or audio issues. Wow. I was surprised that the change of the video card and video driver would make that much difference. Anyway, browsing some forums seems to indicate that PCIe video cards(especially newer ones) can try and hog resources to do their job as best they can -- and different cards and drivers can have drastically different effects on different motherboard chipsets. Apparently this takes away from USB performance and just general CPU performance too... among other things. I never had a major issue with the existing video so it's going to stay.

I've seen on some other forums where folks are bragging about their brand new i7 quad cores with 8 and 16MB RAM that won't run audio interfaces at low enough latency and now I know why. There's a *whole* lot more to it than raw processor power and memory.

New driver doesn't work for me on *my* system with Sonar X1d. Old driver does on the 'Normal' setting.

Upgrading something as innocuous as a video card can lead to problems.


Forum Index » Profile for in2mu5ic » Messages posted by in2mu5ic