On Sun, Jul 11, 2010 at 7:53 AM, Ralf Mardorf
If you're planning on bridging the audio portions of two 1712-based
cards (pref of same manufacturer, like you're doing) then also be sure
to interconnect the SPDIF inputs in order to make sure the audio
portions of the cards stay in sync. And make one card slave it's clock
off the spdif out of the other... Which means you still only have one
spdif input and output remaining despite the two cards. FYI -- the
technique makes a lot more sense if you have to delta 1010's w/ the
high-quality ADC's and the external breakout box (he says in theory,
not owning a 1010, but accepting all donations! (RME's too!) :-) )...
great if you need to build a cheap 16ins/outs digital mixer with a
computer&linux thrown in for free. With the EWX 24/96 -- you're
probably better following the suggestion from
Otherwise, my understanding is that the bridging allows for IRQ
sharing between the cards. Hopefully the ALSA drivers properly support
this feature, although I'd imagine it's just an entailment of
whichever 1712 is the bus-master at the time, hanging on to the bus
for it's preallocated slot of time before relinquishing it and
allowing the next IRQ to be handled. The BIOS could be getting in the
way as well: http://alsa.opensrc.org/index.php/Ice1712#User_comments
Note that bus-mastering flies in the face of "hard realtime"... but
it's really just a matter of having your realtime requirements being
in a "slower time dimension" than your PCI bus and CPU and having all
your potential bus masters, including your disobedient graphics card
-- following the "rules of the bus." However, as bus speeds increase,
and CPU's perform the computations necessitated by the data w/o
inducing any waits or contention for other processing, then realtime
will be easy no matter whether it be realtime for audio needs, or
realtime for video needs.... basically, as processing and bus speeds
tend towards infinity, realtime will just be a matter of not
programing in a totally stupid fashion.
"Some types of bus allow only one device (typically the CPU, or its
proxy) to initiate transactions. Most modern bus architectures,
including PCI, allow multiple devices to bus master because it
significantly improves performance for general purpose operating
systems. Some real-time operating systems prohibit peripherals from
becoming bus masters, because the scheduler can no longer arbitrate
for the bus and hence cannot provide deterministic latency."
This is also most likely what is causing failures in your setup. Your
Nvidia card is hogging the PCI bus and hanging on for longer than it
should, and your audio devices, be they 1712-based, or USB can't do
anything about it but wait for your graphics card to stop hogging.
You might find a new cheap video card could solve all your issues....
if you're not planning on playing games, or decoding/watching HD
video, one that simply has good X windows acceleration, which is
probably perfectly well supported on graphics cards people are
otherwise throwing away because they won't play some FPS at a high
framerate... And if you want http://en.wikipedia.org/wiki/VDPAU for
video, perhaps something like a 9500gt or GT220 may be sufficient.
Are you running desktop effects? Turn that &^%^(*) off!!
Linux-audio-dev mailing list