On Sun, Jul 11, 2010 at 7:53 AM, Ralf Mardorf <[email protected]> wrote: > I'll test what happens if two sound cards become one virtual > sound card, http://www.jrigg.co.uk/linuxaudio/ice1712multi.html and > before doing this I need to test if the second, new second hand card > from Ebay isn't broken for audio, resp. I'll compare the sound quality > for my old and the new Terratec EWX 24/96 sound card, before they become > one virtual sound card.
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 http://lalists.stanford.edu/lau/2010/06/0875.html and http://lalists.stanford.edu/lau/2010/06/0827.html :-) 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. http://en.wikipedia.org/wiki/Bus_mastering .......... "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. random googles: http://thegreenbutton.com/forums/p/84249/420889.aspx http://www.rme-audio.de/english/techinfo/nforce4_tests.htm Are you running desktop effects? Turn that &^%^(*) off!! -- Niels. http://nielsmayer.com _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
