Re: [FFADO-devel] saffire pro 26 report

[Jonathan W. <jw...@ph...>]

Hi Jorn

> thanks to divine intervention, i now have a shiny saffire pro 26 to play
> with :)

Nice.  You couldn't divert some of that divine intervention my way, could
you? :-)

> why does ffadomixer require a running jackd for most features to work?
> for instance, i can't toggle phantom power or inserts without it.
> it would be nice to get rid of this quirk, because people might want to
> use their hardware kind of standalone without having a jackd up.

I don't know about the Saffire, but many of the firewire interfaces use the
iso data stream to communicate device status back to the computer.  As a
result it is not possible to drive their onboard mixers and the like without
the iso stream running.  Now, the mixer application *could* start its
own iso stream, but what would then happen if the user wanted to start 
something requiring jackd?  They would have to exit the mixer application,
start jackd and then restart the mixer - assuming the mixer would be smart
enough to lock into a running jackd if it finds one.  All rather messy.

Jack apps can have jack autostart configured and this is probably the
longer-term solution to this.  There are however issues with that as well
which are still being worked through at the jack level.

> what buffer sizes do people use with comparable hardware (without
> xruns)? as it is now, i'm running jackd realtime at prio 70, but with a
> stock opensuse 10.3 kernel. i can easily cause xruns by wiggling a
> window on my desktop even at buffer sizes > 2048 (n=3).

I have found 4x1024 to be solid *BUT*: it seems you MUST use an RT kernel.
Without an RT kernel the userspace scheduling latencies seem to be too long
and xruns will occur.  As an example, with 2.6.24 with "low latency desktop"
preemption setting, jackd starts at 4x1024, but running "yes" to stdout in
an xterm immediately causes device sync loss.  Under 2.6.24.3-rt3 configured
with "complete preemption", device sync is retained under the same
conditions.  In fact device sync is retained even when "yes" is redirected
to /dev/null which effectively makes "yes" suck all the CPU it can.

I am yet to see whether "low latency desktop" with an RT kernel is
acceptable.  My tests are continuing.

> the ieee1394 chip shares an interrupt with a shoddy old tv card, though.
> my next step will be to rip it out.

Based on my findings this is unlikely to be an issue but by all means test
this theory.  Normally the shared interrupt thing would only become an issue
if the other device was actually in use at the same time.

> somewhere in the docs, i found a hint to "increase the IRQ priority" -
> how do i do that?

This is applicable to a kernel with threaded IRQs.  You need the RT patch
set to get this but I *think* the threaded IRQ component is destined for
mainline sometime soon.  With this patch you can then select "complete
preemption" which enables threaded IRQs so you can then set the priority of
the IRQ handlers.

The "low latency desktop" preemption setting has threaded IRQs as an option
which default off - enabling them in this case will also allow
prioritisation of IRQ handlers.  However, as mentioned above I don't know if
the scheduling latencies of the resulting kernel will be good enough.

> what set of low-latency patches are people using?

Currently I'm testing 2.6.24.3-rt3.

> since my laptop doesn't have firewire, i'm looking for a pc card. every
> single model i've looked at so far relies on an external power supply to
> feed bus-powered devices - i'd rather not have yet another cable and psu...
> is it possible in principle to build a pc card with bus power that draws
> its juice from the pc card slot (i.e. do the power ratings of cardbus
> and ieee1394 allow this at all)? has anyone seen such a thing in the wild?

I *think* cardbus etc could supply sufficient power this.  However, having
bus power also requires the use of a 6-pin firewire plug which is *much*
larger than the 4-pin variant.  Because manufactures like to keep
cardbus/expresscard cards as small as possible they are reluctant to put the
chunkier 6-pin plug on the card.  While I've bumped into the odd 6-pin
cardbus card claiming to support bus power in the past, they are certainly
quite rare.

So in principle it would be possible to build such a card.  Whether anyone
is at the moment is another question.

Regards
  jonathan