17 Apr
2008
17 Apr
'08
7:20 a.m.
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.
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.
marcel@ubuntu:~$ 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.
Cordially, Ismael
--
Ismael Valladolid Torres GnuPG key: DE721AF4
SHS Polar (3.4.3) Google Talk/Jabber/MSN Messenger: ivalladt(a)gmail.com
C/ Emilio Vargas 1 Jaiku/Twitter/Skype/Yahoo!: ivalladt
Edif. Fiteni II AIM/ICQ: 264472328
28043 Madrid (Spain)
The opinions expressed here represent my own and not those of my employer.
Las opiniones expresadas representan las mías propias y no las de mi empresa.
17 Apr
17 Apr
7:52 a.m.
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@ubuntu:~$ 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
24 Apr
24 Apr
9:10 a.m.
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.
Rereading your mail regarding to check what device we're talking about,
I can't resist to comment on this. Please don't compare Linux latency
figures with those of other operating systems. At least not if you
didn't actually measure the latency. It's not because there is a setting
that says "2ms" that this is the latency you get. Not at all. Usually
there is a ASIO latency of e.g. 2ms/buffer times 2 buffers, then another
2ms ISO buffering at each side. The end result is that for a 'setting'
of 2ms you have 10ms in reality.
The numbers displayed in Linux are marketing-free, hence try to provide
a real number.
34ms is still too much though, that's for sure. Just don't buy the 2ms.
I know it's not true if you measure it the way we do.
Greets,
Pieter
6058
days inactive
6065
days old
linux-audio-user@lists.linuxaudio.org
2 comments
2 participants
participants (2)
-
Ismael Valladolid Torres -
Pieter Palmers