Data_Event String double picking up string from Nexia Biamp
fogled@mizzou
Posts: 549
I just installed a Nexia Biamp TC to one of my systems, via TCP/IP control. Commands to the unit work fine. But it appears to be sending back it's responses twice, instead of once.
I have the same code picking up all the IP device strings, and discreetly adding the received string to the device buffer. This works correctly for every other IP device (all my projectors, etc.), but it picks up the response from the Nexia twice. Complicating matters is the fact that, despite being an IP device, the Nexia usually sends just a single character at a time. It's been awhile since I worked with Biamps, I forgot why I despise them so much. Talk about a PITA to configure them and use the software... But, I digress.
When I telnet directly into the device from a command line, I do not get double responses. The only time the response appears twice is when the STRING {} picks it up.
I'm perplexed. Any help from the crowd out there?
I have the same code picking up all the IP device strings, and discreetly adding the received string to the device buffer. This works correctly for every other IP device (all my projectors, etc.), but it picks up the response from the Nexia twice. Complicating matters is the fact that, despite being an IP device, the Nexia usually sends just a single character at a time. It's been awhile since I worked with Biamps, I forgot why I despise them so much. Talk about a PITA to configure them and use the software... But, I digress.
When I telnet directly into the device from a command line, I do not get double responses. The only time the response appears twice is when the STRING {} picks it up.
I'm perplexed. Any help from the crowd out there?
0
Comments
Are you getting two responses, or an echo of the message that you are sending?
Still have the problem after upgrading the firmware. And it gives me the double-character even on initial connection where it outputs "WELCOME TO BIAMP".
Here are a couple snippets from the code...
dvaudio_248 = 0:15:0 data_event[d_all] { string { call 'debug' ("'Data from device:',data.text") } }and what I get back is garbage like this:
...you get the idea. The most characters I've seen come across in one data.device event is 4. 95% of the time it's just one, 4% of the time it's two, and once in a great while it will get 3 or 4 in.
The "d_all" device is an array of all my IP devices: 4 projectors, the new Biamp, and another switch and serial audio controller being driven through a MOXA IP-Serial box. None of the other devices give me the double-event from incoming data. Only the biamp does.
But of course, again, if I telnet into the device, I don't get any double characters sent back.
It seems, for all intents and purposes, that the communications back from the Biamp is so F'ing slow the controller picks up a single data string twice. Never seen that before.
I have another one of these back at the shop. I'll fire it up and set up the simplest single-device IP setup and see what I get.
Can you please post the code where you define d_all?
Also, have you read the section regarding telnet control in the Nexia/Audia manuals?
My driver sends 0xFF 0xFE 0x01 in the ONLINE event after connecting to it.
@Auser: A night's sleep, and your question, led me to finding my problem. When I changed the audio device definition from a serial device (MVC 121) to an IP device (Biamp), I copied and pasted the last IP device I had on 0:15:0, and apparently forgot to increment the number (actually, I think I did that at first, but then got a little crazy with CTRL-Z after mis-pasting the next bit of code and didn't catch the fact that I un-did the number increment).
So, I had 2 devices defined on 0:15:0. The other one isn't actually active yet, so it was less obvious than it should have been. D'oh!
Anyway, crisis averted. Thanks for the help!
As for Biamps in general, their erector set sort of program structure is not my favorite particularly because it depends on the guy who programs the Biamp to be consistent with how he snaps it all together if you want to have pretty much reusable code. There are a number of little things that can be snapped together in different ways and it sometimes comes out looking like "the exciting game without any rules." I much prefer the control protocol of the ClearOne (Gentner) units or the older Polycom stuff (eg: EF2211) or even Lectrosonics. But, we've never had anything with the Biamps that couldn't be worked out pretty easily so I don't hate on them all that much.
Thought you might have - it was fairly obvious to me that the data event was firing twice when you got the welcome message. Glad you found the problem.
My frustration is centered more around how clunky it is to set up the IP configurations in the program, as well as the system configurations and maintenance stuff. And, silly stuff like the way the firmware files are numbered vs. the firmware number in the unit itself. I find the Polycom Soundstructures to be about the easiest to set up and configure as far as DSP's. But, I haven't done anything with the ClearOne units.
One thing that gets me about the Nexia units is the actual sound quality. I replaced a $350 Extron MVC-121 with a $2,000 Nexia TC because I needed AEC for videoconferencing. But for everything except the AEC, that little MVC-121 sounds way better than the Nexia. The MVC's have much richer, fuller, cleaner mic gain and response, have way less problems with local feedback, and no digital buzzing, popping, or other artifacts. A $1K TOA DSP sounds much better too, and it's got a 120 watt 70V amp built in as well.
But when you need AEC, you gotta have it. Does anyone have any recommendations for other audio DSP's that do AEC for videoconferencing?
Oh well, all better now, except for the fact that the next time the client came in, I was in the middle of testing the boundaries of the room audio, and was getting really bad feedback on the mic to find out where the worst resonant frequencies were. Now he's convinced the new DSP is the wrong equipment and we need to install something else.
The problem is the room, not the audio DSP. It's got a bare concrete ceiling with roughly 6x6x3 ft "cells" sunken upward. And of course asbestos coated, so we can't touch it or put in a drop ceiling without major $$ and time which the client doesn't have. The echo in that room even without any PA reinforcement is awful. The sad part is, a cheap little MVC-121 sounded way better and had far less mic feedback than the Biamp Nexia.
I hate audio, especally PA reinforcement. It's by far the hardest part of any job to get right, and it's the part of my job I really know the least about.
With your feedback issue, if you really can't get any wall or ceiling treatments in, do the following:
- EQ the mics and speakers
- Drop a feedback suppressor into the design along with a PEQ downstream of it
- Let the mics ring out so the feedback suppressor can grab the resonant frequencies
- Copy the DSP data from the feedback suppressor into the PEQ
- Delete the feedback suppressor to free up DSP power if required, or leave it in the system to clean up the acoustics if the mics are likely to move within the room
Feedback suppressors are very costly from a DSP point of view. Most of the time copying the filters they create into a PEQ is a better approach, particularly in the Nexia series which have less DSP horsepower than the Audias. If multiple PEQs are included in the system, a single feedback suppressor can be used to learn resonant peaks and then copy them to individual PEQs to provide many bands of feedback suppression.
IMHO fixed architecture DSPs like the Clearones and Polycoms are great (so long as you are aware of their inherent capability limitations) - right up until you need more complexity in a system than a single unit can provide. Having to buss audio between units with fixed architectures and large central matrices becomes diabolical very, very quickly. If there's a requirement to link more than two units, go straight for a free architecture DSP. I say this with a large amount of experience behind me.
Biamp has instance tags; arbitrary text names which can be used in place of instance ID's when controlling the units. It makes sense to use them to make the control more logical and human readable when debugging and more consistent between systems - unfortunately nobody ever seems to use them.
The BSS London Blue series give the Biamps a hiding in terms of DSP power at the moment (until the Tesira range hit the market anyway). Unfortunately the control is diabolical and debugging near impossible. The code blocks available on the AMX and BSS websites are ... crap. They do the job very well from an acoustic standpoint if you're willing to invest the time in being able to control them however.
Yes, this is pretty much exactly what I'm doing. Unfortunately, the feedback suppressor punches out almost everything between 100-450hz, plus a more up higher, and it would punch out more lower if not for the high pass filter. In other words, the frequencies the feedback eliminator finds, when punched out, pretty much kill voice quality anyway. We did get *some* wall treatment, but it's less than 5% of total solid-wall area, and this is still one nasty, nasty sounding room.
A drop ceiling and ceiling mics would solve the problem, but that's not happening any time soon. Working in EDU with squirrelly grant money restrictions is the bane of my existence. Fortunately this situation is a bit of an outlier; one of the worst rooms acoustically, one of the poorer budgets, one of the shortest timeframes (grant money must be spent by X), and one of the worst clients intelligence-wise. If I were private enterprise, I'd walk away from this job.
One trick to use with Biamp that'll make your code more reusable is to have whoever makes the DSP file use the instance ID tag for the blocks. This is a logical name that takes the place of the instance ID in the command, so for instance you would have SET 1 FDRMUTE MasterVolume 1 0 instead of SET 1 FDRMUTE 23 1 0. You can use a standard set of tags so that, as long as the DSP programmer has them in the right place, will react the same way every time, no matter how the DSP is built. This also keeps you from having to change the program when someone decides to check the box that redistributes the instance IDs in the DSP file.
Huh, can't say I've ever noticed buzzing or popping with the nexia units. Nexia/audia are currently our dsp's of choice for jobs with AEC. I will agree that Biamp's ip configuration in their software is a bit clunky though.
We used to use the ClearOne ConvergePro boxes a bunch, and they're not bad. However the AEC is a bit more difficult to get working perfectly in complicated systems/difficult rooms IMO. I've also worked with the ClearOne InteractPro boxes, and while they work (with the same note about the AEC as the ConvergePros) I loathe the config software for them.
I've never really played with Polycom SoundStructure so I can't comment on that, but I'd rather shove an ice pick through my eye then ever deal with another Polycom Vortex system again. Their AEC sucks, the rest of their DSP sucks, and the config software both sucks and blows. Not to mention their power supplys WILL explode at some point. Every one we've ever sold has had it's power supply replaced once, and most of them have been replaced many times.
-Ryan
+1 - I've never installed them myself, but I've replaced countless units installed by other contractors where the power supply has gone.
And yes, I am working towards eliminating deployment of expensive, proprietary teleconferencing systems like Polycom on our campus, too.
For the Biamp systems popping and buzzing, I can definitely hear it, but I'm willing to blame myself for implementing less than "best practice" configurations. The most glaring and reproducible problem is that every time I've ever tried to put a noise gate into one of the systems, it basically craps it's pants and gives me nothing but intermittent popping on that input. Biamp tech support has even told me, "yeah, they do that." It's my understanding that most of the sound quality issues stem from the digital gain vs. most systems that have analog gain before digitizing the signal.
But I'd still like to try to work through the problems I'm having with the systems, and for now Biamp tech support seems easy to reach and fairly attentive to my needs. Overall, they do what I need and are the least expensive decent AEC option. I just need to get used to working around their limitations. Unlike AMX, there's no realistic way I can abstract AEC audio DSP's in virtual servers on my production floor.
Thanks for all the tips - this has been very helpful!