Hi !!!
I am using a jack_delay to measure the Fast Track Pro latency, but
something strange happens...It doesn't matter what configuration I am doing
on Jack that the latency value always is increase during the time... like
the result below:
ladeira@debian:~/Downloads/jack_delay$ ./jack_delay -E -O system:playback_1
-I system:capture_1
??? 412.673 frames 8.597 ms
??? 412.671 frames 8.597 ms
??? 412.671 frames 8.597 ms
??? 413.487 frames 8.614 ms
??? 413.657 frames 8.618 ms
??? 413.670 frames 8.618 ms
??? 413.671 frames 8.618 ms
??? 413.671 frames 8.618 ms
??? 413.671 frames 8.618 ms
??? 414.455 frames 8.634 ms
??? 414.654 frames 8.639 ms
??? 414.670 frames 8.639 ms
What am I doing wrong??
2012/11/26 Guillaume Pellerin <lists(a)parisson.com>
On 23/11/2012 20:01, rodrigo(a)angoera.com.br wrote:
Hi !!!!!
The Fast Track Pro is USB 1.0, the max bandwidth is 12Mb/s. The
TUSB3200 has
the isochronous USB transfer mode, that can
occupy about 90% of the USB
bandwidth... Using 4 channel (2 IN and 2 OUT) with right and left, and
24 bits
(3 bytes each, in total 4(channel) *
2(left,right) * 3(data) = 24 bytes
) The
max bandwidth that could communicate is about
12Mbits/s = 1.5 Mbytes/s
| 1.5
Mbytes/s * 0.9 = 1.2 MBytes/s --> 1.2MBytes/s
/ 24 bytes = 50Khz ... So
the
maximum USB 1.0 with 24 bits is 4 chanel in
48KHz...
You're absolutely right, the 24 bits 4 channels mode would be only
accessible in
48 kHz samplerate.
I would like to know how it works the interface
between USB AUDIO
CLASS device
driver and the USB-AUDIO Alsa Device driver. And
how does the isochronous
comunication works inside the kernel? Because I am using an RT Kernel
and I
would like to set with the high priority this
communication.
I don't really know how does the isochronous, but applying usual RT
security
audio rules seems sufficient to get high priority access and then very low
latency (got 3 ms here with few audio realtime processes..).
Further info here:
http://joegiampaoli.blogspot.fr/2011/06/m-audio-fast-track-pro-for-debian-l…
G