<div class="gmail_quote">2009/6/2 Christoph Willing <span dir="ltr"><<a href="mailto:c.willing@uq.edu.au">c.willing@uq.edu.au</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br></div>
Anyway, I think it would be a great idea if you could do it. My only concern is a "mechanical" one. For a reasonable sized system, multiple input & outputs will be involved. As an example, the almost canonical system of this type in the AG world is the ClearOne XAP-400, nominally 8 inputs (4 with echo cancelling) and 8 outputs with software routing between them all. There's also a phone input and a small amplified output but we can probably forget about those (although we have found the phone input pretty useful here). The "mechanical" problem is about the physical connectors for all those inputs & outputs - they won't fit on a normal PC. I guess you could have some mega-pin connector with some sort of breakout cable but someone will have to solder it all together. Thats certainly not impossible, but I'd guess beyond the skill level of those most likely to want one of these systems.</blockquote>
<div><br>Chris - the professional audio industry has already solved this problem :) Anywhere there is many-in/out PC audio, there are external audio interfaces, mostly using Firewire. Take for example the Presonus Firebox: <a href="http://www.presonus.com/products/Detail.aspx?ProductId=4">http://www.presonus.com/products/Detail.aspx?ProductId=4</a> which I use at home for audio production and has 2 mic in, 2 line in, and a number of outputs (which also works in RAT in Windows at least, albeit a bit clunkily), or the Firestudio: <a href="http://www.presonus.com/products/Detail.aspx?ProductId=5">http://www.presonus.com/products/Detail.aspx?ProductId=5</a> which has 26 inputs and outputs of various kinds.<br>
</div></div><br>Examples like these make support for JACK (which, in combination with FFADO, is the only way to use Firewire devices in Linux AFAIK) more urgent.<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
Well -- if mono is used for transmission, just say 8-in/2-out 1RU<br>
el-cheapo mixer (with preamps built in)? :-) Then only need, in fact<br>
mono, cable from mixer to PC...</blockquote><div><br>Leon - won't mixing all the mic inputs down to mono destroy all the effectiveness of the echo cancellation? Different reverb times, different arrival times, etc all in one stream... Any solution would thus have to deal with aforementioned hardware and each input channel individually. <br>
<br>A small tangent - multiple outputs should be possible too. Imagine communicating with vic or another video client with an immersive 360 degree display and having accurate surround sound positioning... :) though I have a nagging feeling this has already been attempted with RAT in some basic way (just stereo?).<br>
<br>Also, AimeDSP does sound interesting, especially the resampling, as the reliability & quality of resampling in RAT seemed wildly disparate across platforms - I think it was depending on the lower-level API or audio hardware to actually perform it (Piers, confirm?) We had a lot of resampling issues particularly on Linux with certain onboard soundcards.<br>
<br>A note - when I mentioned separate input/output devices, I was mostly thinking of smaller end-user scenarios, like someone using a webcam mic (since webcams are usually USB-only, something like this will only show up as an input-only device) for input and onboard sound to speakers for output. On a related note, having separate processing daemons (per input channel?) seems like a very interesting idea though.<br>
<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">Andrew no offence taken on RAT - sometimes it can be good develop new
tools but as we have seen in the history of AccessGrid the work
required to develop replacements often too much for a single project or
institution and the projects never quite get finished. This probably
down to the fact that tools are rather complex beasts and do require a
substantial effort to copy or better. But if someone has effort then
they're welcome to give it a shot. When one is developing [open source]
software it is often a choice between modifying an existing tool or
canabalising it and/or developing a totally new tool.</blockquote><div><br>Piers - I definitely realize that, and I want to avoid reinventing the wheel whenever possible, I'm just concerned that the internal structure of RAT, being so old, might impede efforts to add new parts - especially in potentially having some kind of modular signal chain (being able to send a stream out to JACK and back at any arbitrary point, etc), as well as modifying or even tearing out and replacing the interface. (Needless to say I don't completely like/trust Tcl/Tk :) but did I see something in a vic svn commit about having native windowing/styling in a new version? Doug?) Is there any developer documentation as to the structure of RAT? Unfortunately I don't really have the time to just dive in and figure it out myself, and the same goes for modifying vic as well.<br>
<br>--Andrew<br></div></div>