[Sumover-dev] Re: an AccessGrid question from Leon...

[Andrew Ford]

2009/6/2 Christoph Willing <c.willing at uq.edu.au>

>
> 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.


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:
http://www.presonus.com/products/Detail.aspx?ProductId=4 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: http://www.presonus.com/products/Detail.aspx?ProductId=5 which
has 26 inputs and outputs of various kinds.

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.

Well -- if mono is used for transmission, just say 8-in/2-out 1RU
> el-cheapo mixer (with preamps built in)? :-) Then only need, in fact
> mono, cable from mixer to PC...


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.

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?).

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.

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.

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.


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.

--Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/sumover-dev/attachments/20090603/e4e76dae/attachment.html