BSS Cert
MLaletas
Posts: 226
Has anyone got this yet? Working on it and geez this thing is a bear, its taking forever im at the point where Im committed to finishing these last quizzes and practical. Grrrr.
0
Comments
Anyway dsp certs are usually a quick thing that I can usually fly through, not this one, this one sucks!
I found it easy enough to just follow each line in the spec doc adding and adjusting the dsp file as I went, then a bit more time afterwards to make it all look nice on screen. I found that if I read too much into their spec I went astray so keeping it as simple as possible helped.
Put simply, they are after your understanding of how the various components work together in the dsp itself, and it showed when I got the results back seeing I forgot one of the gotchas of using an noise canceller component that was covered in the course.
The guy reviewing the test made allowances for differences in final design to the BSS "optimal design" that you may encounter with other certification agencies (I'm looking at you Microsoft!)
Actually, the BSS London Soundweb has had the kind of self-contained automation/interface solution for quite some time. In fact, hardly any of that has changed much in ten years. And certainly there are situations where you don't really need a control system or want to ramp up the scope of a project to incorporate one that's close to the borderline of needing one.
I feel like in my case it's more of a financial case. There are much less expensive solutions for delivering audio in a venue if you don't really need the heavy-duty control system features. BSS kind of sits on a funny market space in that regard. You typically see it used in higher-end spaces that (by virtue of their scope and budget) are already gong to have a control system in play. In all my years of running into them in the wild, I've only seen one that was really dressed out with some pretty full-bore BSS UI and programming. In every other case there was a marriage of the BSS and a control system.
so, in my case as a VIP Independent programmer, bringing me in on a job always implies more complicated stuff where I'm usually doing control system programming and audio dsp in tandem. Otherwise, most integration firms have a tech on-staff with DSP training who can throw together a simple system who doesn't cost so much.
For me the main issue with the testing and maintaining credentials is time. I spend an inordinate amount of time learning and proving my worthiness doing things that I never ever do in real life. And since my boss is not willing to pay me for doing work that I don't get paid for (self-employment) I have to make a choice on whether to work at stuff that gets me paid or stuff that doesn't.
The London BSS system is not too difficult to configure. Like it's competitors in Polycom, ClearOne, (Cr3$7r0n's Avia, shhhhh) and Biamp, (and to a lesser extent Symmetrix), it has pros and cons. It has a graphical software that has a slight learning curve and requires some knowledge of audio. Choice then becomes a matter of price, familiarity, and preference, and frankly if I were running a company, I'd prefer to stick with one brand to make it easier on our sales people, designers, and engineers. Meaning that no one of these systems has such a marked superiority of sound quality or feature sets to merit its use over any other overall. So if we accept all things are equal, it then falls on those of us who are asked to integrate the DSP system into a conference room, divisible room, auditorium, or arena. And on that note, if and when I am asked, or even if I'm not, I NEVER recommend the London BSS over any other DSP. The control protocol interface has been an abomination since the original product release and for this reason alone, I steer clear of it.
Compare the ASCII Text communication strings used in controlling every other product to the unique device HEX byte protocol of the London BSS devices. While it's not impossibly difficult to control, it is clearly antiquated and frankly reminds me of the bitwise protocol I have used to control certain machines; but that was almost two decades ago. Think of the amount of time it takes to set up controls for the all of the manufacturers' systems listed above, and more importantly, the propensity to make an error in the control system code commands which will cause the system not to work as desired. Add to that there's also the need in the field to make changes which the client/end-user did not account for. All of these factors drive me away from the London Soundweb system.
I have spoken to Harman even prior to the AMX acquisition about this unwieldy protocol, and then after they brought AMX on board I spoke to them again.Everyone of the people I spoke to gave me a knowing wince while trying their best to smooth this obvious fault over by pointing out other product advantages. I have never met a contemporary who thought this was a better protocol than ClearOne, Biamp, Polycom, (Avia shhhhh), or Symmetrix, and I have personally helped a few of my peers on more than one occasion from throwing their laptop into a river by sharing a code I created to help them out. But if the protocol is so daunting as to make some of the smartest people I know stress out, what is the point of using this product?
I'll take their class and pass their exam, but I'll ***** the entire time about the awfulness that is their protocol, and that my current company will never use this hardware until an overhaul of the API is done.
Like I wrote, that's just my two cents.
:rolleyes:(Remember you need to add $80 and preface the byte with $1B before sending, and on the return string you need to remove the $1B and subtract $80 from the next byte to get a proper response. Brilliant)
The escape sequences are not that big a deal, write a function to deal with them on the transmit side and write a function to deal with them on the receive side. When that is done you never have to think about it again. It is just not that big a deal.
I find that when I control a DSP, 98% of the time all I need to control is level, mute, preset recall, and Telephone Hybrid. I use a registration process with my DSP modules for a faded type, a mute type, and a telephone type. The code registers the "addresses" of these controls in a call back function when the communication port (RS232, IP) goes online. I use the HiQnet address and state address so the module doesn't have to keep track of all the different state addresses for everything except for the telephone hybrids.
I found that it took far less code to implement the BSS protocol than it did to implement the Biamp DSP protocols.The BSS protocol is also a lot more efficient, there are not a ton of different control types and different string values that are control specific.
Andrew,
I've been pretty vocal about this piece of gear ever since AMX/Harman/Samsung/Samsung professional (or whoever they are this week) bought it up. I'm sure you're aware that the protocol is nightmarish and, although you can subscribe to it for feedback of the processing blocks and their parameters, The feedback still doesn't work unless you poll it.
The box in and of itself is pretty on par with the Biamp Tesira. There are a few obvious differences, but they really are pretty competitive with each other. In my honest opinion the Biamp wins out marginally featurewise in that it has a few tricks it does in teleconferencing noise handling that are pretty cool. However, the BSS has a few tricks of its own that are unique and quite good. Pound for pound their pretty much an even race.
I also think it's a bit easier to build a large multi-processor Biamp system vs. a BSS. Here again, it's not a drastic difference and in some ways having all the other parts-n-pieces such as amplifiers and so forth integrated is more helpful. BluLink is way less fussy, and much easier to configure than Dante or whatnot.
The big rub is integrating it with AMX. Biamp wins that race hands down. I will say that at last year's Developers Conference they did indicate they were working on a much friendlier protocol. If that does happen it would tip the scales for me as I have no other beef with the BSS (other than slight things) vs. the Biamp.
I say all this because you have a super knowledge of the Biamp. I knew this of you when we first met. Hopefully, you will add the BSS to your tool belt. And, if you need a module, I know a guy....
There is an issue with the subscription in that when you subscribe to something from the comm port, it does volunteer changes that occur with that "thing" coming from within the box itself (like when you're changing it from Audio Architect) or when a user changes something from one of the panels generated by the BSS. But (ironically) when you make a change from the control system, that resulting change is not sent out the control port back to you. My module works around this by always resending the Submit command after each change coming from the control system. I've found it to be pretty reliable.
I have seen what you describe as well. There is not much to be done other than just occasionally poll and sync yourself back up.
Here again, If they end up redoing the control protocol, hopefully all this kind of stuff goes away. It's clearly a half-backed cookie from the mid-90s that just never got fixed.
The Polycom Sound Structure protocol is pretty good as well. Consistent verbiage but a lot of quotations marks. And OBAM. OBAM is king shit. Truly. Set up a group of 8 C16's and you have a 128x128 matrix. Though setting them up through the wizard is an annoyance.
Like I wrote, there are benefits to all of these devices, though the off-putting control protocol of the London BSS devices makes me mental. And I recall having a similar issue with the polling. It was counter-intuititve on the set up when you checked a box for internal or external control.... Really the protocol alone makes me tell people to steer clear.
Eric I have dealt with all kinds of DSP (I was even trained on the never released Shure DSP), but they all have their place. Except the London BSS Soundweb stuff. Really.
One thing that drives me insane about the London BSS Protocol is that I believe every element on every box has a unique identifier. Which means that every time I use the code on a new box, I have to create a new array of variables, or rewrite a structure for device headers. This makes portable coding difficult.
In Biamp and in Polycom, I can identify every lectern mic level I ever encounter as lectmiclev, and my code will work for that system.
In ClearOne as long as I am using the same addresses and boxes, the code can stay pretty much the same.
You can extol the virtues of the "efficiency" of BSS coding, but when I'm cranking out 75 to 100 new DSP systems a year, portability becomes an important factor.