[PlanetCCRMA] usb audio interface performance

[Hector Centeno]

On 5/18/07, Fernando Lopez-Lezcano <nando@ccrma.stanford.edu> wrote:
> On Fri, 2007-05-18 at 12:55 -0400, Hector Centeno wrote:
> > Hi,
> >
> > I'm using a M-Audio Transit USB audio interface with a laptop and I
> > was wondering if the rtirq script is actually setting the right
> > priority for it. Would booting the laptop with the interface connected
> > or disconnected make a diference? Is there something that I should
> > tweak in the script to make it favor the USB port? Also I noticed that
> > using the stock Fedora kernel I get much better performance than with
> > the RT kernel, so that's why I was wondering about the priorities.
>
> Hmmm, don't really know about this.
> You can run "/etc/rc.d/init.d/rtirq status" to see what the current irq
> priority is. You could also stop and restart rtirq (as root) with the
> card connected and see if that reorders them differently.
>
> "Better performance" means what? Fewer xruns? Lower buffer sizes
> possible?

The way I'm measuring performance is by using Csound, which is what I
mainly use in Linux. Using the same Csound instruments in realtime
performances (specially using phase vocoder transformations and
synthesis which are very CPU intensive) and accumulating notes until I
start getting sound dropouts. Using the stock kernel in FC6 I can get
a decent polyphony without dropouts but with the realtime kernel I
start getting them at a lower number of voices. I tried the new
UbuntuStudio (which is basically the same as Ubuntu Feisty) and It was
pretty disappointing that both the lowlatency kernel and RT where
giving me dropouts with just one note playing! (with FC6 and stock
kernel I get more than 8) which I tried to fix by increasing the
buffer size but it got worst.


Thanks fot your help!

Hector



>
> > Also, is there any recommendation regarding buffer sizes in Jack for
> > using USB interfaces? I remember reading somewhere that the periods
> > should be 3, is this true?
>
> USB soundcards work best with 3 periods and sampling rate = 48000. This
> has to do with the fact that packets are send every millisecond
> regardless of sampling rate (bad design) and that does not mesh with,
> for example, a 44.1KHz sampling rate (not all periods return the same
> number of samples or something like that). I seem to remember that the
> problem has to do with the way alsa handles interrupts and is not
> something that can be easily fixed.
>
> -- Fernando
>
>
>


-- 
===============================
http://www.hcenteno.net