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

[mea]

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

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