mea wrote:
Pieter Palmers wrote:
mea wrote:
Hello from Prague,
I bought the firewire soundcard Edirol FA-66. Yesterday morning I
compiled freebob, recompiled jack and within half an hour I already
saw all 6 inputs and outputs in qjackctl. What? Recording on linux is
hard? Pha! I thought but unfortunately my moment of victory didn't
last long. On all recordings there is a strange cracking sound, not
all the time, but every couple of seconds. No xruns though. Before I
bought this device I used to record through the internal soundcard of
my thinkpad R40, running all programs as root and this 'sort of'
worked. So I thought I should first of all make sure all my apps can
run as user. After a lot of reading (I spent all day on this
yesterday before I decided to consult this list) I figured the best
approach for me would be to use set_rlimits, because slackware
doesn't have PAM, and I never patched a kernel before. As I
understand these are the 3 possibilities for programs to run in
realtime right? Well, in short I can now run qjackctl, jack and
ardour as user without xruns, but this weird cracking is still on the
recordings. To make sure it was not an ardour issue I tried
sooperlooper, and the noise is still there. I suspect the trouble is
probably freebob, because I didn't have this issue before and maybe I
should have written on their list, but I am not completely sure and I
found very useful information here before, so here I am, asking for
any advice, because I don't know what to do anymore. Here is some
more information about my setup>
The crackles you hear are due to libfreebob not being able to process
the firewire packets fast enough. This means lost packets and hence
lost audio data. You would expect xruns when this happens, but
freebob-1.0 doesn't report dropped packets as xruns, this could be
called a bug. We'll fix this in the next version.
In order to use FreeBoB, it is really recommended to use a realtime
patched kernel. We are doing in userspace what is normally done in
kernel space, and hence we need to meet very strict deadlines to be
able to. When using a realtime patched kernel that is configured
correctly (see
http://freebob.sourceforge.net/index.php/System_Configuration_Hints),
no packets are dropped and this problem does not occur.
Having said this, you can probably improve things on a standard kernel
if you allow user processes to request SCHED_FIFO scheduling (realtime
scheduling). As a test you can run jackd+freebob as root and see if
the problem persists. Remember to start jackd in realtime mode:
e.g.
jackd -R -p60 -d freebob -p512
Thinkpad R40, Pentium4, 512MbRAM
You should check the brand of the firewire controller that you are
using. (some) Thinkpads have a Ricoh firewire controller built in, and
that is a very buggy piece of hardware. It will never work properly
with freebob because it fails on isochronous traffic. (check this
using lspci -v)
The solution for that is to use a cardbus firewire controller.
Chipsets from Via, Texas Instruments and Nec are working fine for me.
Slackware 10.2
uname -r 2.6.13
Should it be possible, maybe consider switching to a more audio
friendly distro...
Greets,
Pieter Palmers
FreeBoB developer
Thank you for the quick and informative answer. I start qjackctl first,
with server "set_rlimits jackd -R". I also tried just "set_rlimits jackd
-R -d freebob etc. from a terminal, no difference.
/etc/set_rlimits.conf looks like this:
@audio /usr/local/bin/jackd nice=-1 rtprio=85 memlock=59000
@audio /usr/local/bin/qjackctl nice=-1 rtprio=84 memlock=59000
@audio /usr/bin/ardour nice=-1 rtprio=83 memlock=25000
lspci -v :
2:07.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000
Controller (PHY/Link) (prog-if 10 [OHCI])
Lucky there!
cat /proc/interrupts
CPU0
0: 11707467 XT-PIC timer
1: 48 XT-PIC i8042
2: 0 XT-PIC cascade
8: 1 XT-PIC rtc
9: 32729 XT-PIC acpi
11: 16353479 XT-PIC yenta, eth0, ohci1394, Intel
82801DB-ICH4, ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3,
uhci_hcd:usb4, radeon@pci:0000:01:00.0
It's really ashame that almost every device on your system uses IRQ11.
That cannot be good for performance, especially the radeon might cause
problems.
12: 33 XT-PIC i8042
14: 82318 XT-PIC ide0
15: 271529 XT-PIC ide1
ups!
I will have to patch the kernel to be able to use rcirq right?
AFAIK yes. I would really recommend using a -rt patched kernel.
Pieter
