Re: [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@email-addr-hidden: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
Received on Wed Feb 7 04:15:02 2007