Hi, if you do "risk" it, be sure to let us know, especially if there are problems ;) I've been looking at buying one of these myself (possibly one of the bigger devices but hopefully they are the same). Rgds, Robert 2009/2/3 pete shorthose <zenadsl6252(a)zen.co.uk>

That would be a good deed. Probably Pete has more pressing needs than me, but still. The things I'd like to know of the top of my head are basically: - if it's relatively stable. - no artifacts in the sound, clicks etc, recording for a while with lowish latency should prove "something" - What kind of latency to expect, this might be a bit of work to determine. Not sure myself how to do it other than tuning a complete system and bringing the buffers down to the lowest that are usable. I had an Edirol FA101 a few years back but to me it fell short of the mark. - Freebob had a built in latency issue back then (the latency could vary), I hear this should be much improved in ffado. - Lowest buffer settings I could get was something along the lines of 3x192. But there were clicks. Besides 3x192 is not good enough for me, my brain can't keep up with that kind of latency. ;) I think I read somewhere that the first gen firewire audio interfaces had built in latency that has since been improved. Not sure which gen the Phonic hw relates to... or if this is all a hoax :) Regards, Robert 2009/2/4 Simon W. Fielding <s.fielding(a)wmcce.org>

-----Original Message----- From: linux-audio-user-bounces(a)lists.linuxaudio.org on behalf of Simon W. Fielding Sent: Thu 2/5/2009 12:33 To: linux-audio-user(a)lists.linuxaudio.org Subject: Re: [LAU] Phonic Helix Board 12 FireWireMKIIcompatibility(linux/ffado) MKIIcompatibility(linux/ffado) I'd like to lowish latency should prove "something" determine. Not sure myself how to do it the lowest that are usable. OK - I now have a working basic FC10 system - relevant details are :- Hardware: Toshiba Tecra M3 Kernel: 2.6.26.8-1.rt15.1.fc10.ccrma.i686.rt Jackd: jackdmp 1.9.1 ffado: 2.0-0.6.rc1.fc10.ccrma (libffado 1.999.40) Initial cursory testing shows (no recording load, just an idle mixer with nothing connected) :- jackd -R -dfirewire -r96000 -p16 -n3 ... jackd won't even start - uses too much CPU jackd -R -dfirewire -r96000 -p32 -n3 ... jackd won't even start - uses too much CPU Both of the above seem to sometimes leave the 1394 bus in a strange state. A forced bus reset using gscanbus seems to fix it. jackd -R -dfirewire -r96000 -p64 -n3 ... jackd starts - uses approx 70% CPU with xruns every 10-20 seconds jackd -R -dfirewire -r96000 -p128 -n3 ... jackd starts - uses approx 50% CPU - no xruns jackd -R -dfirewire -r96000 -p256 -n3 ... jackd starts - uses approx 45% CPU - no xruns jackd -R -dfirewire -r96000 -p512 -n3 ... jackd starts - uses approx 25% CPU - no xruns This is all I have time for today - I'll try and do more later this week. If I've missed any useful details, please ask and I'll try to get them posted. Cheers, Simon

05:0b.2 FireWire (IEEE 1394): Texas Instruments OHCI Compliant IEEE 1394 Host Controller from modinfo ohci1394: filename: /lib/modules/2.6.26.8-1.rt15.1.fc10.ccrma.i686.rt/kernel/drivers/ieee1394/ohci1394.ko license: GPL description: Driver for PCI OHCI IEEE-1394 controllers author: Sebastien Rougeaux <sebastien.rougeaux(a)anu.edu.au> srcversion: F669E8BD5067B58BCE801E7 alias: pci:v*d*sv*sd*bc0Csc00i10* depends: vermagic: 2.6.26.8-1.rt15.1.fc10.ccrma.i686.rt SMP preempt mod_unload 686 parm: phys_dma:Enable physical DMA (default = 1). (int) dmesg|grep 1394: ohci1394 0000:05:0b.2: enabling device (0000 -> 0002) ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[20] MMIO=[cdc05000-cdc057ff] Max Packet=[2048] IR/IT contexts=[4/8] ieee1394: The root node is not cycle master capable; selecting a new root node and resetting... ieee1394: Host added: ID:BUS[0-01:1023] GUID[0000390000785790] If that's not what you wanted to know, please tell me and I'll do my best to find out. Cheers, Simon

On Mon, 09 Feb 2009 18:04:40 +0100 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de> wrote: Meh. If you ask me, negative latency is the future. pete.

On Mon, Feb 9, 2009 at 4:19 PM, Eric Steinberg <eric.steinberg(a)gmail.com>wrote;wrote: Yeah, we could even skip recording... ;-) -- Christopher Stamper Email: christopherstamper(a)gmail.com Web: http://tinyurl.com/2ooncg gTalk: http://tinyurl.com/6e359r Skype: cdstamper

I'm aware of that. I have no particular intention to even use this piece of kit, let alone at those settings but I did volunteer to take a look at it so I may as well try to be reasonably comprehensive where possible. If the info is remotely useful to somebody, I don't feel I've wasted my time. I'm using stupidly excessive settings to see what breaks and where, given that this is all running on an underpowered spare laptop I've got lying round the office which is not really up to the job. Sorry - all that sounded a bit more pompous than I intended. Please try not to read anything in to that. Cheers, Simon imnsho, -p128 should be perfectly fine for 96k. don't waste your time "tuning" your system for latencies below that. there are good reasons to perform audio computations in chunks. i don't know why people seem to get warm fuzzy feelings from invalidating their cache lines for every new sample :)

This is a fairly gutless and underpowered machine for this sort of thing. It's also completely untuned for audio work - just an out of the box FC10 and CCRMA build, gnome etc. I would normally only use it for running soft synths etc, not to try anything like this with. FWIW, without the Phonic, but with the built in ICH6, jackd -R -dalsa -dhw:0,0 -r96000 -p256 -n3 uses between 1% and 3% CPU, idling under the same conditions as before. Cheers, Simon

I guess that appears to be the case - unless someone more expert has any better opinions. Simon

In the interests of fairness, following Pieter's reply I've done a little more testing. I downloaded the ffado source and rebuilt it with DEBUG=no and ENABLE_OPTIMIZATIONS=yes. This gave me a bit of a problem because of a bug in scons so I needed to remove the scons version I had and install scons 1.2 from source. That worked although the ffado scons script now throws a few warnings for deprecated functionality in the new version of scons. /usr/bin/jackd -R -dfirewire -r96000 -p256 -n3 :- now runs at 25-30% CPU with occasional jumps to about 35% for 20 seconds or so and occasional drops to 17-18% for a similar amount of time. /usr/bin/jackd -R -dfirewire -r96000 -p256 -n3 -i2 -o2 :- for a slightly fairer comparison with my ICH6/your HDA - this made very little difference (maybe 1 or 2% CPU less) and indeed, qjackctl still showed 10+2 channels in its connections window. Cheers, Simon

On Sat, Feb 14, 2009 at 12:20 PM, pete shorthose <zenadsl6252(a)zen.co.uk> wrote: Are these modules part of the kernel? If they are - and sorry that I don't remember what real-time kernel you are using - but if the modules are part of a normal kernel.org package you believe they are causing the problem then we should report this to Ingo & the crew. They would certainly want to know what the errors look like in case it's an issue with the rt-kernel design. Most of the time it's the driver that needs some small mode to make it real-time safe. As for the multiple ports it's just so you can build a network I think. 1 cable to your PC - another to a disk drive or something else 1394-based. - Mark

pete shorthose wrote: You can connect a second Helix and double your channel count. Theoretically you should be able to connect any other FFADO supported firewire audio device and use them as one combined device... Unfortunately reality is a bit different and hence YMMV. But in general this works for identical devices, and for devices based upon the same chipset. Greets, Pieter