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
Received on Thu Feb 1 04:15:02 2007
This archive was generated by hypermail 2.1.8 : Thu Feb 01 2007 - 04:15:02 EET