I just bought a MAudio Fasttrack Ultra 8R an use it on my Notebook with Ubuntu Studio 11.10 (3.0.16-generic Kernel)
I have big problems with the latency correction of Jack and Ardour.
To be safe from XRuns I set Jack to 1024 Frame/Period and 44100Hz, 3 Periods/Buffer giving me 67,7ms Latency as reported by QJackCtl.
When I route Ardours Click out to an Audio Track within Ardour and record that then afterwards play the track back with the Ardour-Own-Click still on, I get obvious flams.
Next I started to play the recorded Click-Track back and re-record it with a microphone over the speakers - again flaming (if I turne on the built in click again I even got a triple flam).
Then I started measuring the delay in Frames in Ardour, deviding that by two and used those value as In- and outputlatency in QJackCtl. After a bit of trial an error I figuerd out some values that got the two recoded tracks in Sync.
Without chaning those values I retried the same configuration, and again - flaming, the microfone recorded track was too late.
Really confused now I tried out jack_iodely simply over the speaker-mikrofone setup (Jdelay out to speaker, mirkofone to Jdelay in)
those results now completely confuse me: as I run the test for about 30sec the values shown by jdelay constantly increased: from 4339.363 to 4535.423 in the end.
As I can not control the DSP-Mixer in the Fasttrack Ultra 8r under Linux I don’t dare to directly connect an output to an input as I might get a feedback loop then - the DSP-Mixer in the device always connects the inputs to the outputs.
I hope somebody has an idea about what I can do… actualy I could still return the Fasttrack Ultra to my Dealer and get my money back but that would be the last option, because I could not find any other USB-Multichannell-Adio-Device at that price that is ALSA compatible.
I hope someone out there can help me. Thank you for you patients reading all this so far already.
I just did more "research" and found out, that the delay increases the longer Jack is running. When I stop and restart Jack the first take is in sync again, than the delay gets longer with every recording I make
Should not be happening. Sounds like an issue in Jack, of course coming from the Ubuntu repos I am not convinced something isn’t screwy there either.
I just did more “research” and found out, that the delay increases the longer Jack is running. When I stop and restart Jack the first take is in sync again, than the delay gets longer with every recording I make
And one more: I seem to be running Jack2 1.9.7 which seems to be the latest Verion in the Ubuntu repositories
Something like this used to happen for me with my Edirol UA-1000. In that case, it was because the kernel driver didn’t support the method of synchronising capture and playback streams used by that device.
What would happen was that the latency would gradually increase until it had grown by (period * buffers), at which point there would be an xrun, and it would jump back down again.
The problem was eventually fixed for me by Clemens Ladisch’s new kernel driver module for the UA-1000 and UA-101 (in kernel 2.6.34 on). Maybe the FastTrack Ultra 8R suffers from this same issue? Is there a specific driver for the FastTrack Ultra, or does it use the standard snd-usb-audio one?
I do not know if the Fast Track Ultra 8 R has a speciffic driver - it seems to be supported by ther 3.0 Kernel. Because I read that on the ALSA hardware list I bougt that device.
I tried the same testing setup on my desktop computer with Ubuntu Studio too but this time with the 3.0.16 realtime Kernel from Allesio Bogani’s “percise” repository. I got the same results Though I am not sure if I set up the realtime thing for Jack correctly.)
Though I am not sure if I set up the realtime thing for Jack correctly.)