Ok, so we championed the open DSP architecture in 2014. Now its 2020: audio accessories skipped our Smart Connector interface (also from 2014) and went straight to wireless (really Devon? BT inside the chassis?); our Open DSPs are now little islands isolated by high latency, low bandwidth links.

How does the Open DSP ecosystem evolve to support – and maximize – an all wireless world?

Are signal processing entities portable? How does the framework optimize processing?

SPE = Signal Processing Element

Monkey Bus Wireless = A wireless bus from a future bbq. It must be better than Bluetooth.

What if every sound in the world was being recorded, and tagged with location and time?  What if it was all searchable, reusable and accessible from any device?  What new information could we learn from a sonic omniscience?  What could we detect and automate?  What problems could a system like this create or solve?  What would it disrupt?  What new forms of art could emerge?

As our world becomes increasingly filled with sensors and microphones, and the services we use are paid for with disclosure of data, it seems as though a system like this might one day be possible.  What are the long term implications of a sonic omniscience?  Is it all NSA and 1984, or are there opportunities to mitigate an Orwellian dystopia and use a system like this to create a better world?  What responsibilities should those developing sensor networks and search algorithms have to ensure the best possible outcome?  What should the equivalent be to Asimov’s “Laws of Robotics?”

Over the years we’ve all seen several promising standards efforts fail to bear timely fruit, consuming huge amounts of valuable volunteer time and energy in the process. I posit that this is a relevant problem for at least some of the industries represented at BBQ, and worthy of careful thought inside those industries.

Therefore, let the Big BBQ Brain think together upon: When to Standardize, vs. When Not To?  Each path has its peculiar advantages and disadvantages which some people understand well but others don’t, particularly.  A BBQ Workgroup Report gathering knowledge on this subject could, perhaps, have practical use as inception-time advice for future efforts by helping them to choose whatever path’s best for the particular project.

Discussion

Under certain circumstances standards development can be slow and contentious, and therefore frustrating.  Participants may burn out, then drop out, making subsequent progress even slower.  Sometimes standards efforts fail as a result.

When progress toward any important thing is perceived as excessively process-heavy, technical people naturally become impatient and seek a faster workaround… and start thinking of open-source projects etc. … but this is also not always a perfect solution.  After the feel-good launch and coding-party stages, the practical end results from that path don’t always display quite the required level of technical rigor, nor succeed quite as widely, nor attract quite the kinds of companies needed, nor exhibit quite the kind of technical stability over time that a large market may require.

A timely and good quality standard from a recognized standards development organization that’s created by major relevant companies can, by contrast, powerfully succeed and prevail in the market for many years, even as individual vendors come and go.  And for the right kind of project with the right individual participants, the fluidity of an open source project is absolutely the best and most productive way to go.

What exactly is it about a given project that makes it likely to fail as a standard, or fail as an open-source project?  This topic is all about characterizing the two ways, and characterizing projects.

Key Questions

• How to funnel precious volunteer-hours toward more (vs. less) productive outcomes?
• What are the characteristics of successful standards efforts?
• What are the characteristics of unsuccessful standards efforts?
• What characteristics make something other than a standards effort – for example, an open-source project, or establishing a new community – a more effective path for a given project?
• What does taking a standards path achieve that other approaches (open-source, etc.) don’t, or can’t?
• What does taking a non-standards path achieve that a standard doesn’t, or can’t?
• What about IPR models?
• Is there anything standards bodies could be doing differently to help troubled projects succeed
• Which of standardization’s many inconveniences are simply unavoidable?
• How about hybrid models, for example combining standardized specifications with open-source implementations?

‘…or meaningful ways to safeguard hearing without becoming a nanny state.’

I know that protecting hearing is a major hot-button issue with several BBQers, and I think it is an important issue that we should talk about.

I have not recently been involved in any updates to the EU hearing protection rules, but when I last read the proposed changes I nearly fainted. What I read:

-Dupe users into thinking they’re deaf or suffering from tinnitus when they’ve listened to too much loud music.

-Plaster ugly UI elements all over otherwise beautiful OSes.

-Hosts/players must psychically intuit rendering devices in order to know their output parameters.

-Track users across devices to monitor exposure.

If you are involved with the EU rulemaking and these do not reflect the current state of affairs (and assuming that you are permitted to do so), please correct my understanding. Note that I have taken some liberty in describing my observations.

What is the best way to protect hearing? What roll (or controls) should content creators/parents/governments/police have in protecting their fans/children/citizens/sheep? What can we do as technologists to help?

What’s the hottest new consumer technology? Helicopter drone video. What’s the worst thing about helicopter drone video? That droning sound. (Or no sound at all.) Imagine…

• A drone-mounted mic that cancels the propeller sound, producing pristine soundtracks
• A ring of drone-mounted speakers that follow you around, for mobile surround sound (“wingtones”)
• An app that synthesizes music from silent drone video

More practically, future noise cancellation algorithms will offer numerous opportunities for adding sound and music to previously hostile environments. What are some scenarios that would encourage that development?

While the creators of augmented and mixed reality are pioneering great experiences in the realm of binaural audio, one might ask the question, what’s next?  Where are the greatest opportunities for understanding our environment through sound, and seamlessly blending audio content with the world around us?  What would we do with greater contextual awareness and responsiveness?  What problems could we solve?  What are the limitations and the possibilities?

From the earliest sputtering combustion engine of the Ford Model T, or the clackity-clack of a Mickey Mantle card in your bicycle spokes, to the modern stealthy sounds of the Tesla, the symphony of transportation continues to evolve.  Knight Rider’s Kitt sold us on the dream of a car with the ability to carry on a conversation, although we’re not there yet.  Car enthusiasts modify their exhausts to make them louder, and researchers are designing tires to make them quieter.   As vehicle sound systems become more complex, what will this mean for our interactions with them?  How will the sonic experience of vehicles impact the emotional relationships that users or bystanders have with them.  What risks and opportunities does the vehicle give us that’s different from other platforms?

As Apple’s dominance continues to sore, most recently with iOS device sales overtaking Win PC sales, what does this mean for us developers? How much do the current popular platforms define the products we build? How much should they define what we build? In the case of iOS and music production there are some serious hurdles, namely screen real-estate and until recently lack of a good standard for inter-app communication. In the case of musical instruments, lack of tactile feedback creates serious design challenges. And in the case of all iOS products (software at least) there are significant economic challenges, namely, how do you fund and profit a serious development with a $5 product (if you’re lucky to charge any money at all)?  Is anybody other than Apple making money on iOS apps? Will El Capitan’s AU3 and Audio Extensions change things? Will Windows 10 audio updates change things? Can touch devices really change the way music is produced without Android attending the party?

The IoT buzzword and concept has a lot of push behind it. The topic that I think would be interesting is does the Audio of Things in a given place want / need to use the internet. The companies with server side services are pushing it but that mean it is the “right” answer. Because of implied power (Radios) and security (information on shared server) can I keep the information local and still accomplish all of my home automation goals and get a benefit?

With the advent of digital interfaces for headset accessories, what kind of functionality are end-users wanting in their next gen headset/accessories?

Let’s keep the conversation away from the “how” and “over what interface” and think bigger to what end users are really looking for in future systems. Sensor, lights, multichannel, floating cameras that take selfies! etc.