From: Christopher S. <the...@gm...> - 2011-04-22 01:39:42
|
Dear FFADO-devel: I have a "new-everything" setup which I am tying to use with a Presonus FP10, and am seeing XRuns when recording with Ardour. I sometimes experience a JACK shutdown because of an FFADO assert, and I sometimes see a runaway stream of errors which (even on a four-processor system) almost completely lock the system up. Here is my ffado-diag output: http://www.pastebay.com/121136 I do not see these XRuns when recording through an ALSA device (a USB-based Tascam US-122) or through the motherboard sound system. I have downloaded, compiled, and installed the current stable ffado library, and would be more than happy to cooperate with any investigation or debugging exercises that will help resolve this. Here is an example XRun (not one of the above two cases): xxxxx@yyyyy:~$ $SHELL -x .jackdrc 2>&1 | tee jackd.log + /usr/bin/jackd -P70 -dfirewire -r96000 -p128 -n3 no message buffer overruns no message buffer overruns jackdmp 1.9.6 Copyright 2001-2005 Paul Davis and others. Copyright 2004-2010 Grame. jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details JACK server starting in realtime mode with priority 70 00881323442: (ffado.cpp)[ 92] ffado_streaming_init: libffado 2.999.0-1983 built Apr 20 2011 22:16:30 Unknown destination port in attempted (dis)connection src_name [Hydrogen:out_L] dst_name [alsa_pcm:playback_1] JackEngine::XRun: client = Hydrogen was not run: state = 1 JackEngine::XRun: client Hydrogen finished after current callback JackPosixMutex::Unlock res = 1 JackAudioDriver::ProcessAsync Process error JackPosixMutex::Unlock res = 1 Given my hardware, I wouldn't expect to see any XRuns at all. Any help? Thanks in advance! Chris |
From: Stefan R. <st...@s5...> - 2011-04-22 08:03:40
|
On Apr 21 Christopher Shubert wrote: > + /usr/bin/jackd -P70 -dfirewire -r96000 -p128 -n3 128 frames per period times 3 periods per buffer divided by 96000 samples per second give merely 4.0 milliseconds coverage by buffers. Try a larger number of frames per period (or, if acceptable, a lower sample rate). > Given my hardware, I wouldn't expect to see any XRuns at all. You don't need lots and lots of bandwidth, you need - guaranteed minimum bandwidth, - guaranteed maximum latency. A commodity server/ desktop OS running on commodity PC hardware with a commodity PC BIOS doesn't give you any such guarantees. Check the BIOS settings hat anything that might involve NMIs (non-maskable interrupts, e.g health monitoring) is switched off. You are using kernel 2.6.35 which should be quite good; nevertheless, check if there is a newer kernel package available for your distribution. You could switch to the "performance" CPU frequency scaling governor, though I don't think the on-demand governor which you are perhaps currently using increases latency that much. (Maybe others can comment in detail on your ffado-diag and jack outputs; I am just an occasional FFADO user.) -- Stefan Richter -=====-==-== -=-- =-==- http://arcgraph.de/sr/ |
From: Arnold K. <ar...@ar...> - 2011-04-22 10:02:18
|
On Friday 22 April 2011 10:03:27 Stefan Richter wrote: > You could switch to the "performance" CPU frequency scaling governor, > though I don't think the on-demand governor which you are perhaps > currently using increases latency that much. Switching from ondemand/conservative to performance governours will not change anything in latency. It will however improve stability to a great concern. There are one or two places in ffado where timers/clocks are used that depend on the cpu-clock and therefor misbehave everytime the cpu-speed changes... Have fun, Arnold |
From: Christopher S. <the...@gm...> - 2011-04-23 04:02:14
|
Hi, Stefan, Thanks for your input. If you think about it, 4.0 milliseconds amounts to 3.2 million clock cycles (at 800 MHz), which amounts to somewhere in the neighborhood of (conservatively) 1 million processor instructions. And compared to the FSB bandwidth, that's one three millionth of what's available. Further, the total data stream of the FP10 (10 input ports at 96000 24-bit samples per second) is 23 megabits per second. That's about one fifth of what the PCI bus can do, about 1/4 of what a firewire interface can manage, and about one two-thousandth of the memory move rate of the computer (DDR2-800). ( http://en.wikipedia.org/wiki/List_of_device_bit_rates provides a handy chart for this sort of thing.) Given the fact that my machine has four independent cores and is running ONLY a single user and a fairly light mix at that, I just have a hard time imagining that I would ever see an XRun at all. There is just too much muscle in a modern computer for that - even in a single core machine. Your thought about NMIs sounds more plausible. I have suspected that there may be a problem related to the video interrupts. Still, this is a whole lot of hardware to not be able to handle this task fluidly. I've filed a ticket on the development site. I hope I can get some help with this. I would really like to just RECORD. Thanks again, Chris On Fri, Apr 22, 2011 at 3:03 AM, Stefan Richter <st...@s5...>wrote: > On Apr 21 Christopher Shubert wrote: > > + /usr/bin/jackd -P70 -dfirewire -r96000 -p128 -n3 > > 128 frames per period times 3 periods per buffer divided by 96000 samples > per second give merely 4.0 milliseconds coverage by buffers. Try a larger > number of frames per period (or, if acceptable, a lower sample rate). > > > Given my hardware, I wouldn't expect to see any XRuns at all. > > You don't need lots and lots of bandwidth, you need > - guaranteed minimum bandwidth, > - guaranteed maximum latency. > A commodity server/ desktop OS running on commodity PC hardware with a > commodity PC BIOS doesn't give you any such guarantees. > > Check the BIOS settings hat anything that might involve NMIs (non-maskable > interrupts, e.g health monitoring) is switched off. > > You are using kernel 2.6.35 which should be quite good; nevertheless, > check if there is a newer kernel package available for your distribution. > > You could switch to the "performance" CPU frequency scaling governor, > though I don't think the on-demand governor which you are perhaps > currently using increases latency that much. > > (Maybe others can comment in detail on your ffado-diag and jack outputs; > I am just an occasional FFADO user.) > -- > Stefan Richter > -=====-==-== -=-- =-==- > http://arcgraph.de/sr/ > |
From: Stefan R. <st...@s5...> - 2011-04-23 11:07:41
|
On Apr 22 Christopher Shubert wrote: > If you think about it, 4.0 milliseconds amounts to 3.2 million clock cycles > (at 800 MHz), which amounts to somewhere in the neighborhood of > (conservatively) 1 million processor instructions. Right, but how does software make use of it? The Linux kernel can be configured for 100, 250, 300, or 1000 Hz timer frequency, i.e. 1/10...1/1.0 milliseconds^-1. AFAIU timer frequency directly influences granularity of the CPU scheduler. The kernel that you are using was likely built with CONFIG_HZ_1000 --- check with "grep CONFIG_HZ_ /boot/config*" or wherever your distribution stores kernel configuration. Still, 1.0 ms scheduling granularity is in the same order of magnitude as the buffer setting of 4.0 ms in the jackd command line you posted. Also, I reiterate: From a certain point on it doesn't matter a lot how much excess bandwidth you have. You are running Linux, an operating system that does *not* guarantee minimum bandwidth/ maximum latency. > And compared to the FSB > bandwidth, that's one three millionth of what's available. Further, the > total data stream of the FP10 (10 input ports at 96000 24-bit samples per > second) is 23 megabits per second. You need to count output ports as well. Still, you don't have a bandwidth issue, you (apparently) have a latency issue. > That's about one fifth of what the PCI bus can do, PCI base rate is 133 MByte/s actually, i.e. 1 Gbit/s. But more important is the maximum latency of PCI. PCI is a shared bus. PCI bus master devices hand the bus over to other devices after their latency timer expires. This timer is in the ballpark of tens of microseconds if I understand the output of "lspci -vvv" correctly. But since PCI does not offer isochronous transaction modes and generally several devices need to share the bus, latency of the bus can be huge. High-bandwidth isochronous FireWire applications (i.e. video capture) frequently ran into limits of the PCI bus back in the days when PCs were PCI based. But in bad cases, even low-bandwidth isochronous FireWire applications could run into trouble if the controller's own FIFO management and program prefetch mechanisms did not deal optimally with host bus latencies. However, you have a PCI Express based PC. PCI Express provides a bunch of point-to-point connections between devices and host bridge. Your VT6307 FireWire controller is a PCI device, hence sits behind a PCIe--PCI bridge, either alone or together with other PCI devices. "lspci -tv" should show you whether more PCI devices are on the same bus as the VT6307. On a PCI Express based PC, you still have theoretically unbound maximum latencies AFAIU. However, I agree that actual occuring extreme values of PC hardware-related latencies should not be a problem for your application as an audio DAW. Your problem is most likely with software alone --- including firmware, operating system software, and application program software, and their interactions. (Of course hardware bandwidth must be a comfortable multiple of your audio bandwidth because FireWire controller, CPU, and HDD controller need to access the audio data buffers in addition to other memory which holds their respective programs.) Really high hardware latencies are only introduced by the HDD. However, sanely written (semi-)professional audio software should be able to cope with that, combined with the kernel's buffering of mass storage I/O. > about 1/4 of what a firewire interface can manage, FireWire 400 data rate is 393.216 Mbit/s, of which about 320 Mbit/s may be allocated to isochronous transactions. And here comes the important point: In contrast to PCI and PCI Express, FireWire actually provides isochronous transaction, alternatively to asynchronous transactions. Isochronous transaction capability means that FireWire offers guaranteed minimum bandwidth/ guaranteed maximum latency. This guaranteed maxim latency is at the same time also a quite low latency --- in the ballpark of 1/8 milliseconds which is the average duration of an isochronous cycle. Per data stream, one packet may be transmitted in each cycle. > and about one > two-thousandth of the memory move rate of the computer (DDR2-800). ( > http://en.wikipedia.org/wiki/List_of_device_bit_rates provides a handy chart > for this sort of thing.) Right, but keep in mind: - 1 b/s = 0.125 B/s, :-) - I/O bandwidths are less than bit rates ( = bus clock times bus width), - there is no mention of guaranteed bandwidths or latencies. > Given the fact that my machine has four independent cores and is running > ONLY a single user and a fairly light mix at that, I just have a hard time > imagining that I would ever see an XRun at all. There is just too much > muscle in a modern computer for that - even in a single core machine. > > Your thought about NMIs sounds more plausible. I have suspected that there > may be a problem related to the video interrupts. Still, this is a whole > lot of hardware to not be able to handle this task fluidly. > > I've filed a ticket on the development site. I hope I can get some help > with this. The comment on firmware sounded promising, pity that it didn't help you. The comment about trying ohci1394 + ieee1394 + raw1394 kernel drivers instead of firewire-ohci + firewire-core kernel drivers is definitely worth a try --- because it is quite simple for you to test since your distributor installed both sets of kernel drivers, not so much because I expect a big effect on the hardware/ software combination you are running. # killall jackd ffado-dbus-server # modprobe -r firewire-ohci # modprobe ohci1394 # grep -e firewire -e 1394 /proc/interrupts # modprobe raw1394 # chown :audio /dev/raw1394 # jackd .... If this improves the situation, modprobe and udev can be configured to automate this. Further notes on your ffado-diag log: - The /proc/interrupts table looks good to me --- at least I didn't spot device drivers that I remember to be notorious latency killers. - The 2.6.35 kernel should be OK AFAIR. Still, maybe I misremember and it wasn't such a good release. Plus, newer kernels tend to behave better and better WRT responsiveness. Hence, if you can find guidance on how to install a newer kernel on your distribution, give it a try. (The alternative ohci/ieee/raw1394 kernel drivers are no longer available in newer kernels, starting with 2.6.37.) - The libraw1394 version of yours, 2.0.5, should be good too. If you switch to ohci/ieee/raw1394, you can use any libraw1394 starting from 1.3.0 inclusive. But with firewire-ohci/core, newest libraw1394 is always the best; current is 2.0.7. The nature of changes that went into 2.0.6 and 2.0.7 does not look to me as if they could address problems like intermittent xruns. But I may be mistaken. So, if you have the means to install libraw1394 2.0.7 and ensure that libffado is dynamically linked against it, give it a try as well. - VIA VT630x controllers were occasionally reported by FFADO users as troublesome. I have a VT6306 and it works totally fine for me with a single FireWire audio device connected to it, though with fewer channels than your FP10. I did try the VT6306 card once with two devices attached and hence aggregated by FFADO, giving as many if not more channels as with your FP10. Device aggregation imposes the added difficulty on FFADO of having to manage 2+2 FireWire data streams instead of 1+1 streams (1 in and 1 out for each attached audio device). That session eventually ended in a runaway error loop, possibly of the same kind that you noted in your initial post. I haven't tested device aggregation systematically yet, hence cannot say if this was just a coincidence or if it would not have happened with a different controller, e.g. one from Texas Instruments. > I would really like to just RECORD. If you just want to /record/ (without life monitoring playback to performers), you should configure the buffers for considerably higher latency anyway. E.g. in the ballpark of 64 ms. But try a range of medium to large buffer sizes. Too large buffers will bring other problems to FFADO. If you need life playback, you still should try something more than 4 ms, say 8 ms or even 16 ms if that is still tolerable. In fact, if you haven't done so already, testing different buffer settings is the very first thing that you should try. The -n setting of 3 periods per buffer on the other hand is said to be optimal for FireWire. (Again a disclaimer: I am only an occasional FFADO user and know little about the FireWire audio domain, and almost nothing about the PC audio or Linux audio domain in general.) -- Stefan Richter -=====-==-== -=-- =-=== http://arcgraph.de/sr/ |
From: <the...@gm...> - 2011-04-24 02:54:24
|
Stefan, Thanks for a thorough technical discussion! My main point was that there is adequate headroom in the system to handle the whole data stream, unbuffered, several times over. But of course, with the probable exception of raw1394, none of the steps is actually unbuffered, so the least likely cause of XRuns was excessive bandwidth or responsiveness demand. (By the way, I am used to using the word "synchronous" as the antonym to asynchronous. Is there a particular reason that you have been using "isochronous"? Not complaining - it's a perfectly good word - just not what I'm used to.) As far as your suggested steps: I have run at buffer size 1024, and received the same results. Bear in mind that I see three different failures: (1) Runaway "wait status < 0 (= -1)" errors; (2) Irregular and occasional "JackPosixMutex::Unlock res = 1"; (3) Infrequent assert failures. Different buffer sizes result in different emphases: Smaller buffer sizes tend toward problem 1; Larger buffer sizes toward problem 2 or 3. And, in general, lower sample rates (44100 vs 96000) have seemed more stable (though I have not experimented heavily with that). I brought down 2.0.0, compiled it, and installed it. I blacklisted the OHCI modules (new stack), verified that the old stack was active, and tried again. Same problem. I should have said up front that this problem seems to be exacerbated by compiz (vs. metacity) and by restricted video drivers (both ATI and NVidia). To my mind, this says "interrupts". I found an old cookbook recipe for adjusting interrupt priorities, but it won't work on this kernel, since interrupt are not handled by processes (but perhaps by the kernel), so I couldn't adjust the RTPRIOs in order to test this. Any further thoughts would be more than welcome. Thanks again for your excellent and expert analysis! Chris On Apr 23, 2011 6:07am, Stefan Richter <st...@s5...> wrote: > On Apr 22 Christopher Shubert wrote: > > If you think about it, 4.0 milliseconds amounts to 3.2 million clock > cycles > > (at 800 MHz), which amounts to somewhere in the neighborhood of > > (conservatively) 1 million processor instructions. > Right, but how does software make use of it? > The Linux kernel can be configured for 100, 250, 300, or 1000 Hz timer > frequency, ie 1/10...1/1.0 milliseconds^-1. AFAIU timer frequency > directly influences granularity of the CPU scheduler. The kernel that you > are using was likely built with CONFIG_HZ_1000 --- check with "grep > CONFIG_HZ_ /boot/config*" or wherever your distribution stores kernel > configuration. Still, 1.0 ms scheduling granularity is in the same order > of magnitude as the buffer setting of 4.0 ms in the jackd command line you > posted. > Also, I reiterate: From a certain point on it doesn't matter a lot how > much excess bandwidth you have. You are running Linux, an operating > system that does *not* guarantee minimum bandwidth/ maximum latency. > > And compared to the FSB > > bandwidth, that's one three millionth of what's available. Further, the > > total data stream of the FP10 (10 input ports at 96000 24-bit samples > per > > second) is 23 megabits per second. > You need to count output ports as well. Still, you don't have a bandwidth > issue, you (apparently) have a latency issue. > > That's about one fifth of what the PCI bus can do, > PCI base rate is 133 MByte/s actually, ie 1 Gbit/s. But more important > is the maximum latency of PCI. PCI is a shared bus. PCI bus master > devices hand the bus over to other devices after their latency timer > expires. This timer is in the ballpark of tens of microseconds if I > understand the output of "lspci -vvv" correctly. But since PCI does not > offer isochronous transaction modes and generally several devices need to > share the bus, latency of the bus can be huge. High-bandwidth isochronous > FireWire applications (ie video capture) frequently ran into limits of > the PCI bus back in the days when PCs were PCI based. > But in bad cases, even low-bandwidth isochronous FireWire applications > could run into trouble if the controller's own FIFO management and program > prefetch mechanisms did not deal optimally with host bus latencies. > However, you have a PCI Express based PC. PCI Express provides a bunch of > point-to-point connections between devices and host bridge. Your VT6307 > FireWire controller is a PCI device, hence sits behind a PCIe--PCI bridge, > either alone or together with other PCI devices. "lspci -tv" should show > you whether more PCI devices are on the same bus as the VT6307. > On a PCI Express based PC, you still have theoretically unbound maximum > latencies AFAIU. However, I agree that actual occuring extreme values of > PC hardware-related latencies should not be a problem for your application > as an audio DAW. Your problem is most likely with software alone --- > including firmware, operating system software, and application program > software, and their interactions. > (Of course hardware bandwidth must be a comfortable multiple of your audio > bandwidth because FireWire controller, CPU, and HDD controller need to > access the audio data buffers in addition to other memory which holds > their > respective programs.) > Really high hardware latencies are only introduced by the HDD. However, > sanely written (semi-)professional audio software should be able to cope > with that, combined with the kernel's buffering of mass storage I/O. > > about 1/4 of what a firewire interface can manage, > FireWire 400 data rate is 393.216 Mbit/s, of which about 320 Mbit/s may be > allocated to isochronous transactions. > And here comes the important point: In contrast to PCI and PCI Express, > FireWire actually provides isochronous transaction, alternatively to > asynchronous transactions. Isochronous transaction capability means that > FireWire offers guaranteed minimum bandwidth/ guaranteed maximum latency. > This guaranteed maxim latency is at the same time also a quite low > latency --- in the ballpark of 1/8 milliseconds which is the average > duration of an isochronous cycle. Per data stream, one packet may be > transmitted in each cycle. > > and about one > > two-thousandth of the memory move rate of the computer (DDR2-800). ( > > http://en.wikipedia.org/wiki/List_of_device_bit_rates provides a handy > chart > > for this sort of thing.) > Right, but keep in mind: > - 1 b/s = 0.125 B/s, :-) > - I/O bandwidths are less than bit rates ( = bus clock times bus width), > - there is no mention of guaranteed bandwidths or latencies. > > Given the fact that my machine has four independent cores and is running > > ONLY a single user and a fairly light mix at that, I just have a hard > time > > imagining that I would ever see an XRun at all. There is just too much > > muscle in a modern computer for that - even in a single core machine. > > > > Your thought about NMIs sounds more plausible. I have suspected that > there > > may be a problem related to the video interrupts. Still, this is a whole > > lot of hardware to not be able to handle this task fluidly. > > > > I've filed a ticket on the development site. I hope I can get some help > > with this. > The comment on firmware sounded promising, pity that it didn't help you. > The comment about trying ohci1394 + ieee1394 + raw1394 kernel drivers > instead of firewire-ohci + firewire-core kernel drivers is definitely > worth > a try --- because it is quite simple for you to test since your > distributor installed both sets of kernel drivers, not so much because I > expect a big effect on the hardware/ software combination you are running. > # killall jackd ffado-dbus-server > # modprobe -r firewire-ohci > # modprobe ohci1394 > # grep -e firewire -e 1394 /proc/interrupts > # modprobe raw1394 > # chown :audio /dev/raw1394 > # jackd .... > If this improves the situation, modprobe and udev can be configured to > automate this. > Further notes on your ffado-diag log: > - The /proc/interrupts table looks good to me --- at least I didn't spot > device drivers that I remember to be notorious latency killers. > - The 2.6.35 kernel should be OK AFAIR. Still, maybe I misremember and > it wasn't such a good release. Plus, newer kernels tend to behave > better and better WRT responsiveness. Hence, if you can find guidance > on how to install a newer kernel on your distribution, give it a try. > (The alternative ohci/ieee/raw1394 kernel drivers are no longer > available in newer kernels, starting with 2.6.37.) > - The libraw1394 version of yours, 2.0.5, should be good too. If you > switch to ohci/ieee/raw1394, you can use any libraw1394 starting from > 1.3.0 inclusive. But with firewire-ohci/core, newest libraw1394 is > always the best; current is 2.0.7. The nature of changes that went > into 2.0.6 and 2.0.7 does not look to me as if they could address > problems like intermittent xruns. But I may be mistaken. So, if you > have the means to install libraw1394 2.0.7 and ensure that libffado is > dynamically linked against it, give it a try as well. > - VIA VT630x controllers were occasionally reported by FFADO users as > troublesome. I have a VT6306 and it works totally fine for me with a > single FireWire audio device connected to it, though with fewer > channels than your FP10. I did try the VT6306 card once with two > devices attached and hence aggregated by FFADO, giving as many if not > more channels as with your FP10. Device aggregation imposes the added > difficulty on FFADO of having to manage 2+2 FireWire data streams > instead of 1+1 streams (1 in and 1 out for each attached audio > device). That session eventually ended in a runaway error loop, > possibly of the same kind that you noted in your initial post. I > haven't tested device aggregation systematically yet, hence cannot say > if this was just a coincidence or if it would not have happened with a > different controller, eg one from Texas Instruments. > > I would really like to just RECORD. > If you just want to /record/ (without life monitoring playback to > performers), you should configure the buffers for considerably higher > latency anyway. Eg in the ballpark of 64 ms. But try a range of medium > to large buffer sizes. Too large buffers will bring other problems to > FFADO. > If you need life playback, you still should try something more than 4 ms, > say 8 ms or even 16 ms if that is still tolerable. > In fact, if you haven't done so already, testing different buffer settings > is the very first thing that you should try. > The -n setting of 3 periods per buffer on the other hand is said to be > optimal for FireWire. > (Again a disclaimer: I am only an occasional FFADO user and know little > about the FireWire audio domain, and almost nothing about the PC audio or > Linux audio domain in general.) > -- > Stefan Richter > -=====-==-== -=-- =-=== > http://arcgraph.de/sr/ |
From: Euan de K. <eu...@de...> - 2011-04-24 07:06:28
|
Hi Chris, Isochronous is different to synchronous, in that the system just guarantees to provide a running stream at a set rate, the actual data on the stream may be used by multiple applications or protocols, in our case we can run audio/video/midi etc data over the same isochronous stream - each application using an allocated portion of the overall stream. An analogy is rather like a luggage conveyor belt with a guaranteed speed. The actual luggage on the conveyor will be derived from multiple airlines and will be distributed to many waiting passengers. The only real part that is guaranteed is that once the luggage is placed on the conveyor it will be delivered to it's destination in a fixed time. (The analogy falls down in that firewire also guarantees not to break the packets!) If the luggage from a particular flight is loaded on to the conveyor at a fixed rate, their passengers will receive it at the exact same rate, however a different airline may load there luggage at a different rate on the same conveyor. Within the constraints of the underlying system, the actual rate the application chooses to send and receive is arbitrary, hence it is possible to deliver MIDI data (31250 Baud) and Audio data (44.1K to 192K @ 24Bit) over the same bus. BTW: I am following this thread closely - XRuns are a real problem, and I have yet to get a truly consistently reliable stream at any frequency - this is with multiple machines, firewire cards, kernels, FFADO revisions etc. That said, there do appear to be people who do consistently get flawless results so it must be possible. The upcoming ALSA firewire support from Clemens look promising so far (but with limited functionality and only at 44.1 right now). Currently running 2.6.39-rc3 + the experimental ALSA stuff - 6 core AMD, TI Firewire and Echo AF Pre8. Regards, Euan. On Sun, 2011-04-24 at 02:54 +0000, the...@gm... wrote: > Stefan, > > Thanks for a thorough technical discussion! My main point was that > there is adequate headroom in the system to handle the whole data > stream, unbuffered, several times over. But of course, with the > probable exception of raw1394, none of the steps is actually > unbuffered, so the least likely cause of XRuns was excessive bandwidth > or responsiveness demand. > > (By the way, I am used to using the word "synchronous" as the antonym > to asynchronous. Is there a particular reason that you have been using > "isochronous"? Not complaining - it's a perfectly good word - just not > what I'm used to.) > > As far as your suggested steps: I have run at buffer size 1024, and > received the same results. Bear in mind that I see three different > failures: (1) Runaway "wait status < 0 (= -1)" errors; (2) Irregular > and occasional "JackPosixMutex::Unlock res = 1"; (3) Infrequent assert > failures. Different buffer sizes result in different emphases: Smaller > buffer sizes tend toward problem 1; Larger buffer sizes toward problem > 2 or 3. And, in general, lower sample rates (44100 vs 96000) have > seemed more stable (though I have not experimented heavily with that). > > I brought down 2.0.0, compiled it, and installed it. I blacklisted the > OHCI modules (new stack), verified that the old stack was active, and > tried again. Same problem. > > I should have said up front that this problem seems to be exacerbated > by compiz (vs. metacity) and by restricted video drivers (both ATI and > NVidia). To my mind, this says "interrupts". I found an old cookbook > recipe for adjusting interrupt priorities, but it won't work on this > kernel, since interrupt are not handled by processes (but perhaps by > the kernel), so I couldn't adjust the RTPRIOs in order to test this. > > Any further thoughts would be more than welcome. > > Thanks again for your excellent and expert analysis! > > Chris > > On Apr 23, 2011 6:07am, Stefan Richter <st...@s5...> > wrote: > > On Apr 22 Christopher Shubert wrote: > > > > > If you think about it, 4.0 milliseconds amounts to 3.2 million > clock cycles > > > > > (at 800 MHz), which amounts to somewhere in the neighborhood of > > > > > (conservatively) 1 million processor instructions. > > > > > > > > Right, but how does software make use of it? > > > > > > > > The Linux kernel can be configured for 100, 250, 300, or 1000 Hz > timer > > > > frequency, i.e. 1/10...1/1.0 milliseconds^-1. AFAIU timer frequency > > > > directly influences granularity of the CPU scheduler. The kernel > that you > > > > are using was likely built with CONFIG_HZ_1000 --- check with "grep > > > > CONFIG_HZ_ /boot/config*" or wherever your distribution stores > kernel > > > > configuration. Still, 1.0 ms scheduling granularity is in the same > order > > > > of magnitude as the buffer setting of 4.0 ms in the jackd command > line you > > > > posted. > > > > > > > > Also, I reiterate: From a certain point on it doesn't matter a lot > how > > > > much excess bandwidth you have. You are running Linux, an operating > > > > system that does *not* guarantee minimum bandwidth/ maximum latency. > > > > > > > > > And compared to the FSB > > > > > bandwidth, that's one three millionth of what's available. > Further, the > > > > > total data stream of the FP10 (10 input ports at 96000 24-bit > samples per > > > > > second) is 23 megabits per second. > > > > > > > > You need to count output ports as well. Still, you don't have a > bandwidth > > > > issue, you (apparently) have a latency issue. > > > > > > > > > That's about one fifth of what the PCI bus can do, > > > > > > > > PCI base rate is 133 MByte/s actually, i.e. 1 Gbit/s. But more > important > > > > is the maximum latency of PCI. PCI is a shared bus. PCI bus master > > > > devices hand the bus over to other devices after their latency timer > > > > expires. This timer is in the ballpark of tens of microseconds if I > > > > understand the output of "lspci -vvv" correctly. But since PCI does > not > > > > offer isochronous transaction modes and generally several devices > need to > > > > share the bus, latency of the bus can be huge. High-bandwidth > isochronous > > > > FireWire applications (i.e. video capture) frequently ran into > limits of > > > > the PCI bus back in the days when PCs were PCI based. > > > > > > > > But in bad cases, even low-bandwidth isochronous FireWire > applications > > > > could run into trouble if the controller's own FIFO management and > program > > > > prefetch mechanisms did not deal optimally with host bus latencies. > > > > > > > > However, you have a PCI Express based PC. PCI Express provides a > bunch of > > > > point-to-point connections between devices and host bridge. Your > VT6307 > > > > FireWire controller is a PCI device, hence sits behind a PCIe--PCI > bridge, > > > > either alone or together with other PCI devices. "lspci -tv" should > show > > > > you whether more PCI devices are on the same bus as the VT6307. > > > > > > > > On a PCI Express based PC, you still have theoretically unbound > maximum > > > > latencies AFAIU. However, I agree that actual occuring extreme > values of > > > > PC hardware-related latencies should not be a problem for your > application > > > > as an audio DAW. Your problem is most likely with software alone > --- > > > > including firmware, operating system software, and application > program > > > > software, and their interactions. > > > > > > > > (Of course hardware bandwidth must be a comfortable multiple of your > audio > > > > bandwidth because FireWire controller, CPU, and HDD controller need > to > > > > access the audio data buffers in addition to other memory which > holds their > > > > respective programs.) > > > > > > > > Really high hardware latencies are only introduced by the HDD. > However, > > > > sanely written (semi-)professional audio software should be able to > cope > > > > with that, combined with the kernel's buffering of mass storage I/O. > > > > > > > > > about 1/4 of what a firewire interface can manage, > > > > > > > > FireWire 400 data rate is 393.216 Mbit/s, of which about 320 Mbit/s > may be > > > > allocated to isochronous transactions. > > > > > > > > And here comes the important point: In contrast to PCI and PCI > Express, > > > > FireWire actually provides isochronous transaction, alternatively to > > > > asynchronous transactions. Isochronous transaction capability means > that > > > > FireWire offers guaranteed minimum bandwidth/ guaranteed maximum > latency. > > > > > > > > This guaranteed maxim latency is at the same time also a quite low > > > > latency --- in the ballpark of 1/8 milliseconds which is the average > > > > duration of an isochronous cycle. Per data stream, one packet may > be > > > > transmitted in each cycle. > > > > > > > > > and about one > > > > > two-thousandth of the memory move rate of the computer > (DDR2-800). ( > > > > > http://en.wikipedia.org/wiki/List_of_device_bit_rates provides a > handy chart > > > > > for this sort of thing.) > > > > > > > > Right, but keep in mind: > > > > - 1 b/s = 0.125 B/s, :-) > > > > - I/O bandwidths are less than bit rates ( = bus clock times bus > width), > > > > - there is no mention of guaranteed bandwidths or latencies. > > > > > > > > > Given the fact that my machine has four independent cores and is > running > > > > > ONLY a single user and a fairly light mix at that, I just have a > hard time > > > > > imagining that I would ever see an XRun at all. There is just too > much > > > > > muscle in a modern computer for that - even in a single core > machine. > > > > > > > > > > Your thought about NMIs sounds more plausible. I have suspected > that there > > > > > may be a problem related to the video interrupts. Still, this is > a whole > > > > > lot of hardware to not be able to handle this task fluidly. > > > > > > > > > > I've filed a ticket on the development site. I hope I can get > some help > > > > > with this. > > > > > > > > The comment on firmware sounded promising, pity that it didn't help > you. > > > > > > > > The comment about trying ohci1394 + ieee1394 + raw1394 kernel > drivers > > > > instead of firewire-ohci + firewire-core kernel drivers is > definitely worth > > > > a try --- because it is quite simple for you to test since your > > > > distributor installed both sets of kernel drivers, not so much > because I > > > > expect a big effect on the hardware/ software combination you are > running. > > > > > > > > # killall jackd ffado-dbus-server > > > > # modprobe -r firewire-ohci > > > > # modprobe ohci1394 > > > > # grep -e firewire -e 1394 /proc/interrupts > > > > # modprobe raw1394 > > > > # chown :audio /dev/raw1394 > > > > # jackd .... > > > > > > > > If this improves the situation, modprobe and udev can be configured > to > > > > automate this. > > > > > > > > Further notes on your ffado-diag log: > > > > > > > > - The /proc/interrupts table looks good to me --- at least I didn't > spot > > > > device drivers that I remember to be notorious latency killers. > > > > > > > > - The 2.6.35 kernel should be OK AFAIR. Still, maybe I misremember > and > > > > it wasn't such a good release. Plus, newer kernels tend to > behave > > > > better and better WRT responsiveness. Hence, if you can find > guidance > > > > on how to install a newer kernel on your distribution, give it a > try. > > > > (The alternative ohci/ieee/raw1394 kernel drivers are no longer > > > > available in newer kernels, starting with 2.6.37.) > > > > > > > > - The libraw1394 version of yours, 2.0.5, should be good too. If > you > > > > switch to ohci/ieee/raw1394, you can use any libraw1394 starting > from > > > > 1.3.0 inclusive. But with firewire-ohci/core, newest libraw1394 > is > > > > always the best; current is 2.0.7. The nature of changes that > went > > > > into 2.0.6 and 2.0.7 does not look to me as if they could address > > > > problems like intermittent xruns. But I may be mistaken. So, if > you > > > > have the means to install libraw1394 2.0.7 and ensure that > libffado is > > > > dynamically linked against it, give it a try as well. > > > > > > > > - VIA VT630x controllers were occasionally reported by FFADO users > as > > > > troublesome. I have a VT6306 and it works totally fine for me > with a > > > > single FireWire audio device connected to it, though with fewer > > > > channels than your FP10. I did try the VT6306 card once with two > > > > devices attached and hence aggregated by FFADO, giving as many if > not > > > > more channels as with your FP10. Device aggregation imposes the > added > > > > difficulty on FFADO of having to manage 2+2 FireWire data streams > > > > instead of 1+1 streams (1 in and 1 out for each attached audio > > > > device). That session eventually ended in a runaway error loop, > > > > possibly of the same kind that you noted in your initial post. I > > > > haven't tested device aggregation systematically yet, hence > cannot say > > > > if this was just a coincidence or if it would not have happened > with a > > > > different controller, e.g. one from Texas Instruments. > > > > > > > > > I would really like to just RECORD. > > > > > > > > If you just want to /record/ (without life monitoring playback to > > > > performers), you should configure the buffers for considerably > higher > > > > latency anyway. E.g. in the ballpark of 64 ms. But try a range of > medium > > > > to large buffer sizes. Too large buffers will bring other problems > to > > > > FFADO. > > > > > > > > If you need life playback, you still should try something more than > 4 ms, > > > > say 8 ms or even 16 ms if that is still tolerable. > > > > > > > > In fact, if you haven't done so already, testing different buffer > settings > > > > is the very first thing that you should try. > > > > > > > > The -n setting of 3 periods per buffer on the other hand is said to > be > > > > optimal for FireWire. > > > > > > > > (Again a disclaimer: I am only an occasional FFADO user and know > little > > > > about the FireWire audio domain, and almost nothing about the PC > audio or > > > > Linux audio domain in general.) > > > > -- > > > > Stefan Richter > > > > -=====-==-== -=-- =-=== > > > > http://arcgraph.de/sr/ > > > > > ------------------------------------------------------------------------------ > Fulfilling the Lean Software Promise > Lean software platforms are now widely adopted and the benefits have been > demonstrated beyond question. Learn why your peers are replacing JEE > containers with lightweight application servers - and what you can gain > from the move. http://p.sf.net/sfu/vmware-sfemails > _______________________________________________ FFADO-devel mailing list FFA...@li... https://lists.sourceforge.net/lists/listinfo/ffado-devel |
From: Stefan R. <st...@s5...> - 2011-04-24 14:14:43
|
On Apr 24 Euan de Kock wrote: > Isochronous is different to synchronous, in that the system just > guarantees to provide a running stream at a set rate, the actual data on > the stream may be used by multiple applications or protocols, in our > case we can run audio/video/midi etc data over the same isochronous > stream - each application using an allocated portion of the overall > stream. Yes, isochronous = periodic in constant periods, synchronous = at the same time. Isochronous is actually a kind of asynchronous since there is a phase difference between sender and receiver. The phase difference remains constant over time though (or is bounded at least; there may be jitter). Hence it is possible to achieve synchronism between sender and receiver even if they communicate merely isochronously, provided that the phase difference can be compensated by foreknowledge. The inventor of the term isochronous forgot to introduce a direct antonym, instead asynchronous doubles as antonym to isochronous. > An analogy is rather like a luggage conveyor belt with a guaranteed > speed. The actual luggage on the conveyor will be derived from multiple > airlines and will be distributed to many waiting passengers. The only > real part that is guaranteed is that once the luggage is placed on the > conveyor it will be delivered to it's destination in a fixed time. > > (The analogy falls down in that firewire also guarantees not to break > the packets!) Not quite. Asynchronous IEEE 1394 transactions feature guaranteed delivery (by means of retries if necessary). Isochronous IEEE 1394 transactions lack delivery guarantee. There is no retry protocol for them as it would break isochronism. Hence any failures at the sender, bus, or receiver (e.g. receiver link layer controller being unable to access the local bus in time) cannot be corrected, at least not at the IEEE 1394 link layer level and below. > If the luggage from a particular flight is loaded on to the conveyor at > a fixed rate, their passengers will receive it at the exact same rate, > however a different airline may load there luggage at a different rate > on the same conveyor. > > Within the constraints of the underlying system, the actual rate the > application chooses to send and receive is arbitrary, hence it is > possible to deliver MIDI data (31250 Baud) and Audio data (44.1K to 192K > @ 24Bit) over the same bus. > > BTW: I am following this thread closely - XRuns are a real problem, and > I have yet to get a truly consistently reliable stream at any frequency > - this is with multiple machines, firewire cards, kernels, FFADO > revisions etc. > > That said, there do appear to be people who do consistently get flawless > results so it must be possible. The upcoming ALSA firewire support from > Clemens look promising so far (but with limited functionality and only > at 44.1 right now). > > Currently running 2.6.39-rc3 + the experimental ALSA stuff - 6 core AMD, > TI Firewire and Echo AF Pre8. I do get xrun-free sessions over many hours under certain circumstances. First of all, I am using FFADO in an unusual way: Only as testing tool for IEEE 1394 kernel driver maintenance. I could use FireWire audio for real purposes (desktop audio playback) if it weren't so impractical for now. Not long ago I found out that whether I get xruns or not these days only depends on which jackd client applications I use: Recording: - timemachine: no xruns - haven't tried any other recorder yet Playback: - a somewhat outdated version of VLC: useless; its jackd playback subprocess dies sometime soon after start - audacious2: causes occasional xruns - xine: does not seem to cause xruns, but its playback contains glitches (random occurrences of short gaps of silence) - mplayer: no xruns, no glitches (Alas I am not aware of a convenient mplayer GUI which features suitable filemanagement, controls, OSD, and gapless playback, like I get it with audacious2.) This is my FFADO testing hardware: Phenom II X4 @ 2.5 GHz, AMD RS780 host bridge, Radeon HD 3200 onboard graphics, also onboard wired LAN/ USB/ sound in use, a collection of different FireWire controllers built in (PCI, PCIe, CardBus), Terratec Phase X24FW (BeBoB based), Focusrite Saffire PRO24 (DICE based) Software: kernel.org kernels, currently 2.6.38.2, CONFIG_HZ_1000, CONFIG_NO_HZ, CONFIG_PREEMPT, various kernel debugging options Except for experimental firewire drivers, I never use any kernel drivers from outside the mainline. I.e. radeon is at the helm, not fglrx. Gentoo Linux Jack 0.118.0 until recently, 0.120.1 now plain jackd, not jackdmp FFADO infrequently updated from SVN trunk, currently rev 1958 libraw1394 v2.0.7 desktop environment: openbox as window manager together with makeshift compositing by "xcompmgr -a", various gtk/qt/kde based X11 client applications Apart from above mentioned lack auf application software that combines desktop audio class features with a correctly working jackd backend, I have the following difficulties using FFADO: - I need to shut down ntpd before jackd is started. My RTC is so bad that ntpd needs to force a 2 seconds clock jump every quarter hour. FFADO does not tolerate discontinuities of the clock. (http://subversion.ffado.org/ticket/242) - The BeBoB driver's connection management only tolerates a clean slate. Combined with the issue that FFADO always crashes at shutdown if running on the newer kernel drivers (http://subversion.ffado.org/ticket/283, http://subversion.ffado.org/ticket/306), this means that FFADO needs to be cold-started or a FireWire bus reset needs to be issued before re-start of FFADO. - The DICE driver's startup is a can of worms. Cold start (i.e. after a power-cycle of the Saffire) often dies with a "jackd watchdog: timeout - killing jackd". It may take a few tries before a cold start succeeds. Re-start without or with prior bus reset seems virtually impossible, at least with the SVN checkout that I use at the moment. - Startup with /both/ audio devices on the same bus, hence aggregated, is understandably even more fragile than with either of the devices alone. But when it started, it runs. Right now I have a stable session here with both audio devices on a Texas Instruments XIO2213A controller, giving 20 PCM capture ports, 14 PCM playback ports, 2 MIDI capture ports, 2 MIDI playback ports. Command line is: jackd -P66 -dfirewire -r96000 -p256 -n3 -v3 This means 8 milliseconds latency. More often I use a single device, 48000 or 44100 Hz, and a larger latency. I noticed that 96000 Hz capture does not work 100%: Analog line audio -> Saffire plugs 3 and 4 -> FireWire -> Phase analogue-out plugs 1 and 2 results in junk on the headphones plugged into the Phase, whereas analog audio -> Phase plugs 1 and 2 -> FireWire -> Saffire analogue-out plugs 1 and 2 gives proper sound on the headphones plugged into the Saffire. I have got 8 GB or RAM. There is an active swap partition on a 2.5" SATA disk but it is usually not utilized. The root filesystem including /home is located on a solid state disk. I don't know if this matters to jack/FFADO usage. During this 256x3/96000 session with device aggregation I switched to the performance CPU governor. Usually I use the ondemand governor but I am not sure if this increases the likelihood of xruns or crashes; cf. Arnolds comment. This is because I used incapable jackd clients during most testing in the past (as mentioned; audacious2, vlc, xine) and therefore don't have a systematic picture yet. I also have a Core 2 Duo @ 2.33 GHz based Linux PC which I only rarely tested with jackd. So far that system worked OK, notably it is not exhibiting the ntpd related problem. Anyway; what I wanted to say in this reply is that it is indeed possible to run jackd+FFADO without xruns for many hours (a) on a recent mainline kernel, i.e. without -rt patch but with the feared :-) newer firewire driver stack, (b) at 96000 Hz, (c) with devices aggregated, (d) at rather low buffer latencies. I shall give 256x3/96000 with aggregation a try on my VIA VT6306 card in the next days. Right now I suspect that VT6306 does not make xruns any more likely than e.g. a Texas Instruments chip, but that an xrun may cause graver subsequent problems on VT6306. There is a certain DV or MPEG2-TS video capture problem known with VT6306 which might similarly affect audio I/O. (It seems as if DMA does not resume if new buffer descriptors are enqueued after the controller already reached the end of a packet-per-buffer IR DMA program.) -- Stefan Richter -=====-==-== -=-- ==--- http://arcgraph.de/sr/ |
From: Clemens L. <cl...@la...> - 2011-04-26 06:52:15
|
Stefan Richter wrote: > I shall give 256x3/96000 with aggregation a try on my VIA VT6306 card in > the next days. Right now I suspect that VT6306 does not make xruns any > more likely than e.g. a Texas Instruments chip, but that an xrun may cause > graver subsequent problems on VT6306. According to this file, the VT6306 has bandwidth limitations: https://dev.tctechnologies.tc/tcat/tags/release/public/latest/docs/drv/DICE_OHCI_Blacklist.pdf >From what I've heard, the VT6306 has smaller FIFOs, which makes DMA xruns more likely. Regards, Clemens |
From: Stefan R. <st...@s5...> - 2011-04-26 13:49:43
|
On Apr 26 Clemens Ladisch wrote: > Stefan Richter wrote: > > I shall give 256x3/96000 with aggregation a try on my VIA VT6306 card in > > the next days. Right now I suspect that VT6306 does not make xruns any > > more likely than e.g. a Texas Instruments chip, but that an xrun may cause > > graver subsequent problems on VT6306. > > According to this file, the VT6306 has bandwidth limitations: > https://dev.tctechnologies.tc/tcat/tags/release/public/latest/docs/drv/DICE_OHCI_Blacklist.pdf Ah, and by the way, the PreSonus FP10 product page links to this compatibility sheet: http://www.presonus.com/media/pdf/hardware_compatibility.pdf > From what I've heard, the VT6306 has smaller FIFOs, which makes DMA > xruns more likely. Hmm, indeed. Data sheets list the following FIFO sizes, in kBytes: IR IT AR AT ------------------------------------------------------ Agere FW323 05 4 4 2 2 FW323 06 4 4 2 2 FW643 06 8 8 4 4 FW643 07 8 8 4 4 ------------------------------------------------------ ALi M5271 ¹) ¹) ¹) ¹) ------------------------------------------------------ TI TSB12LV22,26 "deep" TSB43AB22(A) "deep" TSB82AA2 2 2 2 5 TSB83AA23 2 2 2 5 XIO2213A "deep" ------------------------------------------------------ VIA VT6306 ²) ³) 2 ³) 2 VT6307 ³) 2 ³) 2 VT6308 ³) 2 ³) 2 ¹) 4 kB reception FIFO, 4 kB transmit FIFO (shared between asynchronous and isochronous I/O?) ²) data sheet rev 1.16 from July 2002; I think there were different chip revisions of VT6306 ³) 2 kB reception FIFO is shared between asynchronous and isochronous reception As video folks found, only Agere chips have IR FIFOs that are adequate when full IEEE 1394 isochronous bandwidth utilization is approached. TI's not so "deep" FIFOs on the other hand are OK for moderate bandwidths. Unlike with the VIA chips, the IR and AR FIFOs are at least separate. Given that VIA lists the very same specifications for VT6306/7/8 regarding their reception and transmission FIFOs, I wonder why PreSonus' and TC Applied Technologies' compatibility tables don't have footnotes on VT6307/8. Could be though that VT6307/8 are somewhat more stable than the older VT6306 for other reasons. (There must have been more changes than reduction of PHY ports; e.g. VT6307/8 based cards are frequently shipped with OHCI 1.1 features enabled while VT6306 cards seem to be generally limited to OHCI 1.0.) Applying this to Christopher's FP10 troubles: Is there FCP traffic going on during streaming, in case of FFADO's BeBoB driver? What kind of IEEE 1394 bandwidth usage is to be expected from a device like the FP10? Say, 10 input + 10 output channels, configured for 96 kHz sampling rate, 24 bits per sample perhaps blown up to 32 bits by AM824 stream format (?) --> 30.7 + 30.7 Mbit/s plus headers plus MIDI plus perhaps some room for varying 1394 packet size? 30.7 Mbit/s average means 480 Bytes large 1394 packet payloads at average, per direction. A 2 kB IR + AR FIFO does have comfortable room for such ~0.5 kB sized isochronous packets plus the occasional FCP frame. But I could imagine that the chip may get into trouble if it really has to empty that FIFO into different DMA contexts, while also the IT and AT contexts are doing their things and all their DMA programs want to be read and updated as well... Christopher, in http://subversion.ffado.org/ticket/332 you wrote "this FP10 worked almost flawlessly at 96K on an older machine running Ubuntu Studio 10.04. The problems manifested when I switched out my computer's innards - new CPU, MB, RAM, 1394, VDU, HDD, and went to 10.10." Do you remember what FireWire controller there was in the older PC? How does "lspci -tv" look like on your current PC? -- Stefan Richter -=====-==-== -=-- ==-=- http://arcgraph.de/sr/ |
From: <the...@gm...> - 2011-04-26 18:52:33
|
Stefan, Good question regarding the FireWire controller. I don't know at the moment. It was an Intel board from about 2001/2002 (Hyperthreading). Theoretically, I have a new FireWire card coming, though it is tangled up in a Return action with TigerDirect. I look forward to seeing what this card has for a chip, and how it behaves. If you are following the parallel TRAC issue (#332), then you know that I have switched to jackd 1.9.7, and the "wait status < 0" floods seem now to be down to just one message. This fixes an annoying issue, but does not address the bulk of them. I will be trying jackd 0.120.1 at some point in the not-too-distant future as well. Thanks for sticking with this. As you can tell, I am highly motivated to get a clean run here - as clean as my ALSA sound box reliably gives (Tascam US-X2Y). Best, Chris |
From: <the...@gm...> - 2011-04-24 03:03:43
|
Stefan - one other remark: I disabled processor clock scaling in the BIOS in the above-described series of tests, and this also did not help. |
From: Stefan R. <st...@s5...> - 2011-04-24 16:04:27
|
On Apr 24 the...@gm... wrote: > Thanks for a thorough technical discussion! My main point was that there is > adequate headroom in the system to handle the whole data stream, > unbuffered, several times over. But of course, with the probable exception > of raw1394, none of the steps is actually unbuffered, so the least likely > cause of XRuns was excessive bandwidth or responsiveness demand. Sure, I agree to that. > (By the way, I am used to using the word "synchronous" as the antonym to > asynchronous. Is there a particular reason that you have been > using "isochronous"? Not complaining - it's a perfectly good word - just > not what I'm used to.) Usages of these terms overlap. > As far as your suggested steps: I have run at buffer size 1024, and > received the same results. Bear in mind that I see three different > failures: (1) Runaway "wait status < 0 (= -1)" errors; (2) Irregular and > occasional "JackPosixMutex::Unlock res = 1"; (3) Infrequent assert > failures. Different buffer sizes result in different emphases: Smaller > buffer sizes tend toward problem 1; Larger buffer sizes toward problem 2 or > 3. Hmm. > And, in general, lower sample rates (44100 vs 96000) have seemed more > stable (though I have not experimented heavily with that). Perhaps this is related to the FP10 hardware/firmware; see below. > I brought down 2.0.0, compiled it, and installed it. I blacklisted the OHCI > modules (new stack), verified that the old stack was active, and tried > again. Same problem. OK. Just a note: In case that you switch back to firewire-ohci/core, you need ffado 2.0.1 or ffado trunk then. FFADO 2.0.0 may only work with a 50% chance or not at all on firewire-core. > I should have said up front that this problem seems to be exacerbated by > compiz (vs. metacity) and by restricted video drivers (both ATI and > NVidia). To my mind, this says "interrupts". This is to be expected. Out-of-the-mainline drivers tend to feature misbehaviour like prolonged non--interruptible code sections more than mainline drivers. There are certainly still mainline drivers that issue too, e.g. graphics drivers, WLAN drivers, memory card slot drivers..., but mainline drivers tend to get fixed over time because they have more users, better exposure to developers; not to mention that non-free drivers can only be fixed by the owners who are normally unaware or uninterested in freak requirements like low latency. :-/ > I found an old cookbook recipe > for adjusting interrupt priorities, but it won't work on this kernel, since > interrupt are not handled by processes (but perhaps by the kernel), so I > couldn't adjust the RTPRIOs in order to test this. Yes, such a recipe applies to -rt patched kernels, and presumably to 2.6.39 mainline kernels that have threaded interrupt handlers switched on. These kernels run almost everything in "process context" (user process context and kernel thread context) even what stock kernels would perform in IRQ context or soft-IRQ context. These latter contexts are entered whenever and as long as there is something to be done in them, without priorization or preemption (except that IRQ context preempts soft-IRQ context). I.e. the -rt patchset levels the playing field, and then those RTPRIO setting scripts come in to reintroduce some selective unfairness. Still, this is priority based scheduling without bandwidth or latency guarantee, but it might make contemporary multicore hardware work more like we would expect of it. > Any further thoughts would be more than welcome. I am noticing two important points right now: Presonus FP10's support status is "reported to work", i.e. the FFADO developers don't have harwdare or documentation. But at least it is a BeBoB device, and BeBoB support in FFADO is mature and solid AFAIU. The other aspect is that the BridgeCo DM1x00 chip in your FP10 has a lot more channels to operate than the one in e.g. my Phase X24FW. I was told that this can cause situations like the chip/ firmware being sometimes unable to respond to asynchronous requests within the usual IEEE 1394 transaction time-out. With ieee1394/raw1394, FFADO works around that particular issue by modifiying ieee1394 split transaction time-out. In firewire-core of 2.6.35 or older kernels, this time-out register was not yet implemented. On those firewire-core versions you would therefore always see "Warning (ieee1394service.cpp)[ 375] initialize: Could not set SPLIT_TIMEOUT to min requested (1000000)" messages during startup of jackd, and you /may/ see "Unsolicited response" messages from firewire_core in the syslog. The former warning by itself does not pose an actual problem, but the latter kind of kernel messages indicate that the mentioned chip/ firmware issue was actually encountered. Beginning with kernel 2.6.36 and libraw1394 2.0.6, the SPLIT_TIMEOUT workaround is available on firewire-core just like on ieee1394+raw1394 but requires locally edited udev rules. From kernel 2.6.39 onwards, SPLIT_TIMEOUT is initialized to a comfortably large value by default; FFADO doesn't have to increase it anymore. Anyway; you noted that ohci1394+ieee1394+raw1394 (i.e. a setup in which FFADO's SPLIT_TIMEOUT workaround is enabled) does not work appreciably better than firewire-ohci+firewire-core in a version that doesn't offer this workaround. Still, I thought I mention it, firstly because those startup warnings may already had you wonder what's up with them and secondly because I imagine that there is potential for further issues in DM1x000 devices with many channels like FP10 compared to ones with few channels like my Phase X24FW. Perhaps a FFADO developer could comment on that aspect. > Thanks again for your excellent and expert analysis! Well, I'm not so sure about this qualification. My knowledge in this area is fragmentary. -- Stefan Richter -=====-==-== -=-- ==--- http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2011-04-24 22:45:40
|
Christopher, since you are using Ubuntu, there is an easy way to install a very current kernel: https://wiki.ubuntu.com/Kernel/MainlineBuilds The last one for 10.10 seems to be 2.6.36, but maybe you can install a more recent 11.04 kernel package on 10.10. Alternatively or additionally, replace the window manager by one which doesn't use 3D acceleration/ compositing. Though as mentioned, basic server-side compositing with radeon of 2.6.38 works fine for me, and had been with some previous kernels too. -- Stefan Richter -=====-==-== -=-- ==--= http://arcgraph.de/sr/ |