Re: Bluetooth Headset Solution
This is a great idea. I believe fury is right about the bluetooth issues though. It's kind of a shame, as the Bluetooth 5.0 standard introduced better support for multiple bluetooth connections (including multiple audio ones!).
Bluetooth LE/Smart is a different radio technology than EDR/Classic and really should've been called something other than Bluetooth to avoid consumer and developer confusion. I hate how hard it is to google for things about one Bluetooth without the other Bluetooth getting in the way.
As far as I know, the new goodies in Bluetooth 5 are for Smart/LE so that it can do mesh network, send more data, have longer range, or other enhancements needed for wearables, health, IoT, super low power devices. As with the past few Bluetooth spec releases (3.0, 4.x), it's still not making EDR/Classic any better.
Audio (A2DP) goes over EDR/Classic, the old 2.1 standard. With the new 2 Mbps rate, audio maybe could go over Bluetooth 5/Smart/LE, but it would need the A2DP specification ported over to work on that technology, and then everyone has to design new headsets. So, we're not quite there yet. Or, at least, I haven't come across any concrete sources that LE audio is on the way. Correct me if I'm wrong (I would be both happy and sad to be wrong, as both a user and developer of audio systems).
In any case, the Switch is stuck at Bluetooth spec 4.1 at the moment, and I don't know if the chip could be updated in firmware to support 5.
Not including bluetooth headphone support in the first place (even with the potential bluetooth collisions) just seems like an odd choice for Nintendo. I wonder how much that shaved off their costs.
The Bluetooth chip used in the Switch (BCM4356) has a built-in SBC audio encoder included, so the only cost for the most basic solution is working out the user interface, fitting the data transmission in, and testing.
It'd cost some money if they were to license a higher quality codec like AAC or aptX, and then it'd cost CPU time to do the higher quality encoding, but those formats can take less Bluetooth airtime while providing better quality audio (to headsets that support it).
*puts on propeller hat* Feel free to stop me if any of this doesn't make sense--I haven't dug this deep into Bluetooth in a while and my explanation may be a little off. But I worked on a product that handled audio to/from 3-4 devices simultaneously from one chip, so I got to know a little bit about how it gets sent over the air.
Bluetooth Classic is split into 0.625 millisecond time slots (1,600 a second). Until this magical mythical Bluetooth 5 LE audio profile becomes a thing, headsets for the foreseeable future receive audio over Classic. When detached, joycons do their thing over Classic. So that's 3 devices that need to fit within those time slots. It's doable, from what I understand, but would need some really clever low-level juggling of packets, especially as input probably gets sent more often than audio.
- An audio packet (SBC high quality, ~328 Kbps, 8 frames per packet) takes 5 slots to send (3-DH5) and 1 to acknowledge, and contains about 23.2 ms of audio (so needs to be sent about every 37 slots).
- Over the hard wired connection, at least, the switch requests an input update every 15 ms, leading to a roughly 66 FPS input rate. 61 bytes for the input payload. Not sure if this is the same over Bluetooth HID, I haven't found a packet log of the communication between the Switch and the joycons yet. But assuming it is for now. Therefore, I'm guessing a joycon packet would be at least 2 slots for data plus 1 for acknowledgement (maybe an additional packet for "request", not sure) every 24 slots.
- 6 out of every 37 slots for audio, 3 or 4 out of every 24 slots for Joycon-L, and 3 or 4 out of every 24 slots for Joycon-R. 660-800 of the 1600 available slots per second just for data and acks between all 3 devices. That's a lot of opportunity for collisions / retransmissions to screw things up--not even taking into account polling and other Bluetooth overhead
So if no retransmissions are required, certainly possible. But if it has to retransmit even 1 packet every now and then, then it runs the risk of causing a very noticeable and annoying delay in either the audio or the input (or both).
Likelihood of retransmission goes up should any of the connected devices request the master role, or if there's other Bluetooth Classic or 2.4 ghz activity in the vicinity. 2.4 ghz Wi-Fi coexistence, too--the same chip handles both on the switch, so if it's connected to an online game or is downloading, the thing has to play air traffic controller between the Wi-Fi side and the Bluetooth side to make sure they don't run into each other.
Lots of things to consider, any or all of which probably why Nintendo hasn't put Bluetooth audio support in.
Interesting reading for a deep dive into how the joycons communicate with the console when plugged in:
https://github.com/dekuNukem/Nintendo_Switch_Reverse_Engineering
Facebook
Twitter
Instagram