From: Stefan R. <st...@s5...> - 2010-07-24 15:42:08
|
Hi, as Arnold told me on IRC, Focusrite Saffire Pro24 does not work correctly yet on the newer kernel stack. Arnold saw this with different controllers. I did a few quick tests myself now, so far on a VT6306. Jackd seems to start up and keep running fine but I don't get any sounds on the outputs when I have a jack client playing. I can stop jackd, unload the drivers, load the other drivers, and start jackd again, and thus confirm that the "mute" issue only exists with the new drivers underneath while playback works fine with the old drivers. Of course I am running latest svn of ffado + latest kernel.org git of libraw1394 (with the ARM/FCP source node ID fix) + latest firewire drivers (with the ARM/FCP source node ID fix and with Clemens' Split_Timeout implementation; i.e. drivers like they will very likely be released in kernel 2.6.36-rc1). Attached are -v3 logs from the old and the new drivers. There are three differences, all of them look irrelevant: 1.) -dhw:4 vs. -dhw:0. This is jaut because enumeration of the buses is different in the libraw1394 kernel backends. The device was actually connected to the same controller all the time. 2.) The old Could not set SPLIT_TIMEOUT... message. This doesn't actually matter. The reason for it is that usually device file permission disallow access to /dev/fw* of local nodes. If I allow rw access to these files, these messages go away because ffado can increase Split_Timeout now. 3.) Three lines at the end of the new-stack log: got write request, offset=0xffffe0000000, length=4 got write request, offset=0xffffe0000000, length=4 got write request, offset=0xffffe0000000, length=4 These lines come from libraw1394, src/fw.c::handle_arm_request(). Apparently debug messages that somebody forgot to remove. "nosy-dump --view=stats" shows that there is plenty of isochronous traffic on the bus. (Well, I also could have triggered firewire-ohci's IRQ debug logging to confirm that.) I had a quick look at nosy-dump's packet logging during jackd's startup but saw nothing suspicious, just a bunch of read and write transactions that completed all fine. Maybe I should compare packet dumps from nosy on top of the old and the new drivers side by side next... -- Stefan Richter -=====-==-=- -=== ==--- http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2010-07-24 16:04:24
Attachments:
old-stack.txt
new-stack.txt
|
Stefan Richter wrote: > Attached are -v3 logs from the old and the new drivers. Almost. -- Stefan Richter -=====-==-=- -=== ==--- http://arcgraph.de/sr/ |
From: Arnold K. <ar...@ar...> - 2010-07-24 17:42:31
|
Hi, On Saturday 24 July 2010 17:41:38 Stefan Richter wrote: > as Arnold told me on IRC, Focusrite Saffire Pro24 does not work > correctly yet on the newer kernel stack. Arnold saw this with different > controllers. I did a few quick tests myself now, so far on a VT6306. > > Jackd seems to start up and keep running fine but I don't get any sounds > on the outputs when I have a jack client playing. > > I can stop jackd, unload the drivers, load the other drivers, and start > jackd again, and thus confirm that the "mute" issue only exists with the > new drivers underneath while playback works fine with the old drivers. <snip> > "nosy-dump --view=stats" shows that there is plenty of isochronous > traffic on the bus. (Well, I also could have triggered firewire-ohci's > IRQ debug logging to confirm that.) I had a quick look at nosy-dump's > packet logging during jackd's startup but saw nothing suspicious, just a > bunch of read and write transactions that completed all fine. > Maybe I should compare packet dumps from nosy on top of the old and the > new drivers side by side next... I used two computers and the saffire on one bus to confirm that the playback- streams are actually sent: When you start jackd normally on one machine and play back audio, you don't hear it on the saffire's outputs. Start jackd in snooping mode on the second computer and you can hear (or see with meterbridge) that the streams for playback are actually sent. I did try to check the register-writes for whether the result is as expected. Needless to say that that didn't result in errors. I have about 48 hours of flights in front of me the next days, I have the fw- and dice-specs on my laptop and will do some reading. And maybe when I am back I will create extended logs of all register writes on both stacks. Should be fun to compare them ;-) Thanks for looking into that, Stefan! Have fun, Arnold |
From: Stefan R. <st...@s5...> - 2010-08-02 12:33:51
|
BTW, the issue only concerns playback. Capture works, according to timemachine's level bars display. As Arnold mentioned on linux1394-devel, the playback issue is also seen with the DICE evaluation board. On the other hand, Adrian has successfully been using an Alesis iO|14 on the new stack for quite some time now. Is there any obvious difference concerning control or streaming between Alesis' DICE devices on one hand and the evaluation board and Focusrite's DICE devices on the other hand? -- Stefan Richter -=====-==-=- =--- ---=- http://arcgraph.de/sr/ |
From: Arnold K. <ar...@ar...> - 2010-08-03 02:46:53
|
On Monday 02 August 2010 14:33:38 Stefan Richter wrote: > BTW, the issue only concerns playback. Capture works, according to > timemachine's level bars display. > > As Arnold mentioned on linux1394-devel, the playback issue is also seen > with the DICE evaluation board. On the other hand, Adrian has > successfully been using an Alesis iO|14 on the new stack for quite some > time now. > > Is there any obvious difference concerning control or streaming between > Alesis' DICE devices on one hand and the evaluation board and > Focusrite's DICE devices on the other hand? Well, the alesis devices don't seem to have a EAP (Extended Application Protocol) to control the device. So the alesis is probably fixed to "playback whatever comes in", probably resulting in a nasty 'plop' when it start streaming. But the other devices get told when to un-mute playback through the EAP... I think the best way to diagnose is to make libraw log all the async writes done on the device and compare that from old to new stack... I tried to make ffado log that, at least for the register-writes where the read-back value was different from what it should be after the write but that didn't give anything unusual. Bye, Arnold |
From: Nils P. <ni...@ti...> - 2010-08-08 21:39:18
|
On Mon, 2010-08-02 at 14:33 +0200, Stefan Richter wrote: > As Arnold mentioned on linux1394-devel, the playback issue is also seen > with the DICE evaluation board. On the other hand, Adrian has > successfully been using an Alesis iO|14 on the new stack for quite some > time now. FWIW, after a while of dabbling around with the Saffire Pro40 -- from a user's (plus some looking at code and logs and being mostly stumped) point of view -- I tried out the realtime kernel from PlanetCCRMA. It apparently has the old FW stack inside instead of the new one (it took me some time to realize why the /dev/fw* nodes were missing ;-) and besides output working with it I found that jackd is running much more stable on it. I don't have an idea whether this is due to timing issues -- jackd being later (or more often late) on stock Fedora kernels than on the RT one, RT vs. non-RT kernel or incompatibilities in the new stack which show through despite having been abstracted with libraw1394. Anyway, while I previously could record only about 15-30 seconds without underruns and had to restart jackd after a few minutes of operation(*), I could now safely run jackd with only 128 frames per period (surely owed to the RT extensions) and had it running for some hours without crashing or getting stuck in some error state and had no underruns while recording. (*): on the non-RT kernel with the new FW stack, running jackd with 48kHz sample rate, default settings (1024 frames per period) I don't know if it helps, but I have a laptop with one FW socket -- is there anything I should test (Arnold mentioned snooping what happens on the bus with both stacks)? Can I even use the laptop for this (as I can't put it between my audio workstation and the Saffire -- AIUI the audio streams are broadcast to all devices on the bus, but not the asynchronous traffic)? The laptop has this FW adapter built-in: 03:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02) (prog-if 10 [OHCI]) Subsystem: Dell Device 01fe Flags: bus master, medium devsel, latency 64, IRQ 19 Memory at f68ff000 (32-bit, non-prefetchable) [size=4K] Memory at f68fe800 (32-bit, non-prefetchable) [size=2K] Capabilities: [60] Power Management version 2 Kernel driver in use: firewire_ohci Kernel modules: firewire-ohci I read that the FW chipset used has some influence on the matter, should I even bother using the laptop for testing? Can I check anything else? Nils -- Nils Philippsen / Wilhelmstraße 22 / D-71229 Leonberg ni...@ti... / ni...@re... PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 Ever noticed that common sense isn't really all that common? |
From: Stefan R. <st...@s5...> - 2010-08-08 22:46:49
|
Nils Philippsen wrote: > I don't have an idea whether this is due to timing issues -- jackd being > later (or more often late) on stock Fedora kernels than on the RT one, > RT vs. non-RT kernel or incompatibilities in the new stack which show > through despite having been abstracted with libraw1394. Anyway, while I > previously could record only about 15-30 seconds without underruns and > had to restart jackd after a few minutes of operation(*), I could now > safely run jackd with only 128 frames per period (surely owed to the RT > extensions) and had it running for some hours without crashing or > getting stuck in some error state and had no underruns while recording. That big of an effect is surely attributable to the RT kernel rather than a difference between the two driver stacks, unless there is a special issue with the particular controller and the new stack (which is much less likely). I run only vanilla kernels, and ffado runs flawless for many hours (with a BeBoB based device; or with that Dice based device but then with silent playback on the new stack...) with 2.6.34 and 2.6.35 on my present test PC with several different FireWire controllers. I don't see a difference between old and new stack in that regard anymore. Except that the old stack is unable to let ffado run on an Agere FW643 card. If a non-rt kernel works so badly for you, then its basic configuration might be unsuitable (don't know how Fedora's standard config looks like), or there is perhaps one or another driver in it that causes high latency. > I don't know if it helps, but I have a laptop with one FW socket -- is > there anything I should test (Arnold mentioned snooping what happens on > the bus with both stacks)? This is a matter of asynchronous communication into which you cannot listen in with a third OHCI based node. One could read device registers after the fact but (a) I don't know if this helps getting a pointer to the issue, (b) one doesn't need a third node for that. To listen to the asynchronous traffic, one can tap into the kernel drivers on the node that runs ffado or into ffado itself or can use a PCILynx card. -- Stefan Richter -=====-==-=- =--- -=--= http://arcgraph.de/sr/ |