On 16/09/12 00:45, david wrote:
> On 09/15/2012 12:19 AM, Sebastian Rose wrote:
>> On 14/09/12 21:07, david wrote:
>>> On 09/14/2012 07:14 AM, Sebastian Rose wrote:
>>>> Hello,
>>>>
>>>> I'm quite a bit puzzled and so I'm hoping to find something I haven't
>>>> considered yet. I'm using a FireWire Saffire LE Audio Interface,
>>>> connected to the following PCI card: NEC Corporation uPD72873
>>>> [Firewarden] IEEE1394a OHCI 1.1 Link/2-port PHY Controller (rev 01).
>>>>
>>>> Software information: ffado built from svn, jack 1.9.8, kernel 3.5.3
>>>> PREEMT (no realtime patch) or 3.4.9-rt17 (with realtime patch), libraw
>>>> 2.1.0.
>>>>
>>>> No matter what I configure jack to run with, I get regular xruns every
>>>> few seconds whilst doing nothing. The last settings I tried were:
>>>>
>>>> Frames/Period: 4096
>>>> Sample Rate: 96000
>>>> Periods/Buffer: 3
>>>> (Latency: 128ms)
>>>>
>>>> And still no avail, results are like this, just after starting, without
>>>> actually doing anything:
>>>> 19:02:48.093 XRUN callback (1).
>>>> 19:03:03.002 XRUN callback (2).
>>>> 19:03:05.713 XRUN callback (3).
>>>> 19:03:08.257 XRUN callback (4).
>>>> 19:03:12.160 XRUN callback (5).
>>>>
>>>> Interrupt information:
>>>> 21: 0 1 1 33 1087 339542 IO-APIC-fasteoi firewire_ohci
>>>>
>>>> Things I tried:
>>>> Basically everything suggested by the realTimeConfigQuickScan tool,
>>>> like
>>>> changing CPU governor to "performance" or decreasing swappiness.
>>>> I am member of the "audio" groups, which has the following permissions,
>>>> as per limits.conf:
>>>>
>>>> @audio - rtprio 99
>>>> @audio - memlock 8388608
>>>> @audio - nice -5
>>>>
>>>> /dev/rtc and /dev/hpet are both read- and writeable by group "audio".
>>>>
>>>> # /etc/init.d/rtirq status
>>>> PID CLS RTPRIO NI PRI %CPU STAT COMMAND
>>>> 1075 FF 90 - 130 0.0 S irq/8-rtc0
>>>> 1407 FF 85 - 125 0.4 S irq/21-firewire
>>>> 1063 FF 80 - 120 0.0 S irq/1-i8042
>>>> [...]
>>>>
>>>> Any advice on what I could be missing? The same system was working some
>>>> time ago, so I really don't know what I did wrong this time. For even
>>>> further information, below is the output of ffado-diag:
>>>>
>>>> many thanks,
>>>> Sebastian
>>>>
>>>
>>> Try disabling network devices?
>>>
>>> On a laptop, wireless drivers typically scan regularly for connections,
>>> causing extended interrupt handling problems ... of course, don't know
>>> if your desktop machine has any kind of wireless connection built in
>>> (Bluetooth?) but maybe?
>>
>> The desktop machine has no wireless hardware.
>
> Didn't really think it did, just wondered. Debian on my laptop loads a
> Bluetooth driver even though the laptop has no Bluetooth hardware. But
> my laptop installation has been migrated from machine to machine, so
> it's possibly just a remnant from earlier hardware.
Well it looks like I found the problem. I'm running 256 frames/period @
96kHz and 3 periods/buffer (8ms latency) now without xruns.
Turns out it was libffado's fault (or rather: the way I was building
it). I suspected as much since the xrun behaviour was consistent no
matter what Jack settings I was using. I'm using the pro-audio overlay
for Gentoo to build libffado from svn source. The package system was
building libffado with debugging information and without optimizations
(a bug in the ebuild file). Once I changed that, it _seems_ to be
running quite fine. Thanks everybody for your help.
best,
Sebastian
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Sun Sep 16 16:15:01 2012
This archive was generated by hypermail 2.1.8 : Sun Sep 16 2012 - 16:15:02 EEST