Re: FA-66, slackware, freebob, thinkpad R40 - cracks on recordings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux