Re: [LAU] Hardware latency of firewire controller

Ismael Valladolid Torres wrote:
> My colleague bought a Presonus FP10 firewire audio interface, which
> reports working nice in Linux. Moreover he owns a firewire controller
> made by Sunix with a Texas Instruments chipset. He tells us that for
> having jackd working without xrun and no other artifacts he needs to
> use 512 frame/periods, then latency is 34ms, which could be considered
> awful as this card is able to work with 2ms latency using other
> operating systems.
>
> He checked IRQ and saw that the firewire controller shared IRQ with
> the network interface. Check out output of lspci -v .
>
> 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
> Subsystem: Giga-byte Technology Unknown device e000
> Flags: bus master, fast devsel, latency 0, IRQ 17
> I/O ports at a000 [size=256]
> Memory at eb000000 (64-bit, non-prefetchable) [size=4K]
> [virtual] Expansion ROM at 50000000 [disabled] [size=64K]
> Capabilities: <access denied>
>
> 04:01.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23
> IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI])
> Flags: bus master, medium devsel, latency 32, IRQ 17
> Memory at ec004000 (32-bit, non-prefetchable) [size=2K]
> Memory at ec000000 (32-bit, non-prefetchable) [size=16K]
> Capabilities: <access denied>
>
> lspci lists 18 devices and every one of then reports 0 latency except
> the firewire controller. And hardware latency is 32ms, very near the
> 34ms of audio latency reported by jackd. So one could think that if
> the firewire controller added no latency, audio latency could be as
> low as 2ms. Strange, isn't it?
>
> So it looks that audio latency achievable by jackd is limited by
> hardware latency achievable by the firewire controller.
PCI latency is a completely different thing. The 32 is not in
milliseconds. For PCI devices that need good latency performance, one
should set the PCI latency as high as possible.

>
> He even tried locating a PCI slot that doesn't share IRQ and running
> the kernel with the noapic and nolapic options so the system ends
> reporting the sound card in the IRQ 11, which is nice. No change,
> hardware latency is 32ms in any case.
IRQ sharing is not a good thing, so avoid it as you can. Again the "32"
is not easy to interpret correctly. Read the following page to
understand it: http://www.reric.net/linux/pci_latency.html

>
> marcel@email-addr-hidden:~$ uname -a
> Linux ubuntu 2.6.22-14-rt #1 SMP PREEMPT RT Tue Feb 12 09:57:10 UTC
> 2008 i686 GNU/Linux
>
> Anything else can be tested? Or should he put back the PCI firewire
> controller and buy another? Which one? Any ideas welcome. Personal
> answers not to the list also welcome.
The FireWire controller is OK, don't ditch it.

Can you please provide the following information:
1) the output of the attached script (python listirqinfo.py)
2) the full output of lspci -v
3) the jack command line used (if you use qjackctl you can run the
following command in a terminal to get the last command line used: "cat
~/.jackdrc"
4) the versions of jack and freebob (assuming you're not using ffado)

That will probably help me fix your issues.

Greets,

Pieter

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user