Jump to content

Personal anedote on the AudioLink

John Schulz

Recommended Posts

I will keep this post objective as I want to communicate these points well and explain the benefits of the suggestions.

The AudioLink uses the Silicon Labs WT32i-A-AI61 (Data Sheet) Bluetooth modem which is responsible for multiplexing AUX or input Bluetooth to the respective sides. Despite the documentation stating that the modem has the capacity to serve as a Bluetooth headset (Bluetooth CoD: 0b00100 000001 XX) or headphones (Bluetooth CoD: 0b00100 000110 XX) but the AudioLink is advertised as a hands free device (Bluetooth CoD: 0b00100 000010 XX). As a result, the AudioLink is limited to phone calls and (on Linux with a caveat) highly compressed call grade audio streaming. Had the device been registered as one of the two instead of the present one, it likely could have achieved AUX like audio quality and platform agnostic connectivity on any Bluetooth enabled device such as a laptop or desktop. All the while still being able to take calls (when paired to a phone) and use the integrated mic. While programming the additional parts to properly handle different audio codecs and the integrated mic would have added more time spent, it would have eliminated the need for the Audio2Ear app in it's entirety. I cannot speak to the required time needed to program either.

Secondly, there is no accessible way for the device to receive firmware updates. An accessible firmware update interface would be via USB or Bluetooth that uses the standard DFU (Device Firmware Utility) protocol. This does add additional programming complexity but had this been implemented for the AudioLink, the community or Med-El could have rolled out an update that would allow the device to serve as a headset/headphones. On top of that, the device could be reprogrammed to handle new protocols such as AuraCast for future external processors, keeping it out of the landfill/"recycling" for longer. Technically, the AudioLink can receive new firmware via it's internal SPI (Serial Peripheral Interface) but this process would be largely inaccessible the nearly all CI users.

Lastly, I think it would be in Med-El's best interest to take a more open source approach to their devices that doesn't expose their IP. The AudioLink's firmware would fit into this category. Open sourcing allows for a more hands off approach to improvements after the initial product prototyping and development cycle that could allow community members to improve the experience for other members and themselves.


Sorry for the incredibly technical info in this post; I am hoping to use this post as a reference when discussing it with others. I wanted to provide specific solutions with reference material that anyone can use to add merit to my points.


I hope Med-El takes this feedback seriously and adopts it for future products. Thank you!

  • Like 1
Link to comment
Share on other sites

Hi John, thank you for sharing your suggestions with us. We have sent them to our product experts for future product improvements.

Kind regards,

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...