Hi Drew,
I have been using a Focusrite Firewire Pro24 for a year now. Works like
a charm under Tango Studio (Jeremie Jongepier helped me to configure
some audio and priorities aspect) and the FFADO driver.
I note but this minor problem: I have to launch Jack twice, as it first
complains about a ressource to be busy (or something). Not too much of a
problem, I got used to it. Once launched, everything is OK.
HTH,
Yvonnick Noel
> Looks good to me, except for the two ohci_hcd and the nvidia threads.
I
> don't see those when you start rtirq but they are there when you
query
> rtirq's status. Weird. Same issue after a reboot? And this hdspm
device,
> is that an extension card (PCI, PCIe)? If so you might want to try
> another slot because having it to share the same IRQ as your GPU
isn't
> ideal. And maybe you could post or pastebin your complete
> /etc/default/rtirq file.
>
> Best,
>
> Jeremy
Jeremy, the bad is, that I don't have another PCIe x1 slot :(.
> In my experience, restarting the script tries to raise the priorities
> of the threads in RTIRQ_NAME_LIST, but the ones which are already
> raised aren't lowered even if you leave them out of the list.
>
> Try rebooting the computer.
>
> Cheers, Pablo
*reboot*
The reboot doesn't improve anything :(.
I'll build my own kernel within the next days.
Is there anything missing to work with boot option threadirqs?
Usually I use self build kernel-rt and the nv driver. Since the nv
driver is dropped, I'm using the proprietary and I have given up to edit
the nvidia drivers header or to fake the license, since both never
worked on my machine.
spinymouse@precise:~$ cat /boot/config-* | grep PREEMPT
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
# CONFIG_PREEMPT_TRACER is not set
spinymouse@precise:~$ cat /boot/config-* | grep
CONFIG_IRQ_FORCED_THREADING
CONFIG_IRQ_FORCED_THREADING=y
spinymouse@precise:~$ uname -a
Linux precise 3.2.0-23-lowlatency #31-Ubuntu SMP PREEMPT Wed Apr 11
02:24:03 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
There's another issue, I've got 4GB RAM, but only 3.8GB are accessible,
resp. shown. 256MB are missing. I've got this for another install too,
while a PAE 32-bit kernel has no issue with the 4GB. No framebuffer, the
graphics has got it's own RAM.
CONFIG_PREEMPT_COUNT ???
Thanks and regards,
Ralf
Doesn't came through the list again.
On Sat, 2012-05-05 at 02:08 +0200, Ralf Mardorf wrote:
> VERSION:
> $ wget --no-check-certificate
> https://www.rncbc.org/svn/rtirq/trunk/rtirq.conf
> https://www.rncbc.org/svn/rtirq/trunk/rtirq.sh
> --2012-05-05 01:52:06--
>
> ISSUE:
> $ sudo /etc/init.d/rtirq [snip]
> /etc/init.d/rtirq: line 129: syntax error near unexpected token `fi'
> /etc/init.d/rtirq: line 129: ` fi'
>
> I can't see the bug near line 129.
On Thu, 2012-05-03 at 23:24 +0200, somebody off-list wrote:
> Come on Ralf, do your homework. Nando create THE first linux-audio
> distro. his email address will give you a hint.
*chuckle* @ccrma.Stanford.EDU
Haven't noticed that.
On 05/03/2012 10:43 AM, Joel Roth wrote:
> On Thu, May 03, 2012 at 10:21:16AM +0200, Robin Gareus wrote:
>> Capture latency in above message is a wrong. It was reported a while
>> back: check jack-devel archive Dec 2010:
>
> Thanks
>
>> with jack2, there's also the difference of sync (jackd --sync .. -d alsa
>> ...) vs. async mode. The latter adds 1 period of output latency.
>
> I'll need to read about this. --sync is listed in --help,
> but not in the man page.
http://www.grame.fr/~letz/jackdmp.html
> I hope the difference shows up in get_jack_port_latency_range()!
It does. The output latency is one period longer in async mode.
>> see also:
>> http://wiki.linuxaudio.org/wiki/jack_latency_tests
>
> And again. This is very helpful.
>
This wiki-page is a bit outdated (it's from before the new latency API
was introduced) but item (2) under
http://wiki.linuxaudio.org/wiki/jack_latency_tests#interpretation_and_analy…
describes the same bug that you stumbled over.
(1) was actually solved: The additional latency for USB devices comes
from ALSA's USB driver implementation. Clemens explained the details in
the same thread on jack-devel "Re: Differences in latency between USB
and internal audio interfaces" December 9, 2010.
ciao,
robin
Greetings,
The world turns, the times change, and I get a new gig writing for the
Linux Weekly News. My first article is up, but it's for subcribers only :
http://lwn.net/Articles/495612/
And at the same time my article on Pd has been published by the Linux
Journal, also a subscriber-only selection. Bummer, I know, but IIRC I'll
be able to put the article on-line myself after a waiting period. I'll
check on that and let this list know about it.
Best,
dp