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

[Pieter Palmers]

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 at 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