[linux-audio-user] FA-66, slackware, freebob, thinkpad R40 - cracks on recordings - Linux-audio-user

Pieter Palmers

30 Jan 30 Jan

12:54 p.m.

New subject: [linux-audio-user] FA-66, slackware, freebob, thinkpad R40 - cracks on recordings

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

Reply

mea

1:28 p.m.

New subject: [linux-audio-user] FA-66, slackware, freebob, thinkpad R40 - cracks on recordings

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 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? Distro switching on this computer doesn't come in question, but I will buy a desktop computer very soon and there I could use something more audio friendly. Freebob webpage suggests Fedora+CCRMA, is that still actual? Once again many thanks for the answers and mainly for the work you do with freebob! Martin Alacam

Reply

mea

6 Feb 6 Feb

8:51 p.m.

New subject: [linux-audio-user] FA-66, slackware, freebob, thinkpad R40 - cracks on recordings

Pieter Palmers wrote:

...

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

Hello, I managed to patch and install the 2.6.20-rc6 kernel with patch-2.6.20-rc6-rt6 following more or less the instructions from the links on http://freebob.sourceforge.net, system configuration. It boots almost without any errors. (This is a little off-topic, but I would appreciate any tips> The only thing I didn't manage to fix after many reconfigurations is that I don't see any boot messages and also the terminals (Ctrl-alt-F*) vanished.) I start qjackctl with set_rlimits qjackctl and then set_rlimits ardour Connecting to jack server causes many xruns and ardour soon gets disconnected. No difference if I run only jackd with command line options. What now? Like you can see in my prevoius post, almost every device uses IRQ11, Should I fix this in the BIOS? In BIOS there is a list like this> INTA PCI IRQ [11] where I can change the number INTB PCI IRQ [11] ...etc until INTH. No idea what letter is what. I also downloaded rtirq, but really, the information I could get about it is far too cryptical for my level of knowledge. Is it so, that /etc/rtirq.conf gives higher priorities to some chosen threads? Then I could give a higher priority to f.e. ohci1394? Thank you in advance for your time, Best Martin

Reply

Dmitry Baikov

31 Jan 31 Jan

1:36 p.m.

On 1/30/07, Pieter Palmers <pieterp(a)joow.be> wrote:

...

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)

I thought they screwed only their PCMCIA/CardBus controllers :) Rumors say for cardbus it became better in the latest chips revisions, though. Dmitry.

Reply