TLDR; If this approach to external decoding would work, the user experience under these conditions would appear and sound like a fully integrated OEM SiriusXM experience using the Tesla SiriusXM OEM tuner with all controls using the native Tesla MCU SiriusXM client.
Another thought to a Ryzen solution: The part that is working is the UI interface, and the control plane of sending tuning commands to the tuner, and receiving control data back (confirmation of stream selection as well as song ID, etc). Can we use this part, which is 90% of the integration we want and solve the audio decoding externally? Tesla has done us a favor with the fallback behavior playing the audio stream of the last tuned FM station. Were we to decode the SiriusXM audio stream likely on the Broad R ethernet properly tuned already, we could just take the decoded analog signal and put it through an FM modulator whose audio is already playing through the MCU driven speakers in fallback to FM. The user experience under these conditions would
appear to be a fully integrated OEM SiriusXM experience using the Tesla SiriusXM OEM tuner with all controls using the native Tesla MCU SiriusXM client.
I handwaved away the hardest and most unknown part:
External decoding of the SiriusXM audio stream
However it looks like we have some pieces to start with stutech posted this response in this thread back in April 2023 to a separate question I asked.
Good start! So what does audio encoded on Broad R look like? A quick read of this chapter...
...suggest:
"We focus on the current solutions for audio/video communications, i.e. Ethernet audio video bridging (AVB) specification. This specification has adapted Ethernet technology to meet electromagnetic constraints (EMC) specific to the automotive domain, and at the same time reducing the number of wires required to communicate (only one twisted pair in the current specification for at a throughput of 1 Gb/s instead of four). We review Physical (Broad R-Reach PHY) and Ethernet MAC layer in that perspective. Several new protocols including: clock synchronization (802.1AS gPTP), stream reservation and transmission protocols (IEEE 802.1Qat SRP and IEEE 1722) have been developed, and new mechanisms for forwarding and queuing frames have been proposed."
Key words I'm picking out here are these protocols: IEEE 802.1Qat SRP and IEEE 1722
Stream Reservation Protocol:
en.wikipedia.org
This matches the description of how IEEE 802.1Qat SRP seems to work. IEEE 802.1Qat SRP and IEEE 1722 along with a number of other protocols appear to be all wrapped up in a larger standard called AVB (Audio/Video Bridging):
en.wikipedia.org
That "weird non-encrypted binary format" feels like it might be the AVB stream. So how do we take this stream and decode it externally? There appears to already be work on support with GStreamer and ALSA in Linux. Including a sample implementation of Talker
AND Listener! Here:
Getting Started with AVB on Linux* — TSN Documentation Project for Linux* 0.1 documentation
[/B]
gst-launch-1.0 clockselect. \( clock-id=realtime \
avtpsrc ifname=eth0.5 ! avtpcvfdepay streamid=0xAABBCCDDEEFF000A ! \
queue max-size-bytes=0 max-size-buffers=0 max-size-time=0 ! \
vaapih264dec ! videoconvert ! clockoverlay halignment=right ! autovideosink \)
[B]
The above is for a video stream, but the elements are there. We'd likely be in the dark on some needed values such as clock timing and frame size. External decoding would require some amount of computing power. Would a small SoC based system such as a Raspberry Pi be able to? Do the libraries exist compiled for ARM that would be required? Alternatively could an x86 based SFF system such as an Intel Nuc survive in a hot car? Those are question to address if the decoding is successful using desktop computing power.
If stutech has those wireshark dumps from the Ryzen car, it might be enough to get started. Honestly, I'm slightly beyond the edge of my knowledge here on the software side.
Has anyone explored down this line of thinking yet? If so, what have you found?
