I have an iPhone 6+ and I believe later versions of iPhones (and/or iOS) have higher bluetooth audio bitrates but it isn't clear to me if the Tesla supports this. Anyone know what the max bitrate is for Bluetooth audio between an iPhone 6+ running iOS 8.1 and a Tesla Model S (I have a three week old P85D if that matters).
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
What's the max bitrate for bluetooth audio between phone and Tesla?
- Thread starter wayner
- Start date
-
- Tags
- Model S User Interface
I found that, but apparently the bitrate depends on what is supported by the two devices. Do we know if the Tesla can support 512kbps? I am guessing that the car is more likely a limiting factor than my iPhone6+ since that is newer technology than the media system in the Model S.
finallybuying
Member
SeminoleFSU
Voluntaryist
From Undocumented | TeslaTap
Bluetooth – 3.0 + HS; Audio streaming with A2DP sink, A2DP source, AVRCP 1.4; Audio Profile A2DP includes support for standard SBC codec (highly compressed low-bit rate audio); Uses the Parrot FC6050 W chip.
One thing to keep in mind, these specs are based on the Parrot chip (I think) which may or may not be what the Tesla software also supports... Meaning the chip could support more than the software, and so your BT stream gets down converted somehow. I think this is pretty unlikely though. If you pick a file encoded at 320Kbps and it plays over BT, it is almost certainly supported.
Last edited:
bollar
Disgruntled Member
It certainly does support AAC 256 via a USB stick. It also supports FLAC and AIFF lossless via USB
But if using BT, presumably the phone is doing the decoding into whatever the BT profile can support, as indicated above.
Yea no, this was specifically a claim that it was over bt and that they'd used a tool to see which code over a2dp was being used. I didn't believe and did some research and indeed aac is a valid codec used over a2dp but I was still skeptical especially given that I have about 100 tracks of aac songs I've purchased from iTunes and P85D will not play them off the USB. I can select them but nothing happens. It says it's playing them but no audio comes out.
bollar
Disgruntled Member
I don't have the tools to comment on what's actually going on with BT encoding.
It would be interesting to see what's up with your AAC files. My entire music library is either AAC 256, AIFF and FLAC and all of the files play from a USB stick. The ones that don't are m4p (protected) files from the original iTunes days.
That's probably the issue. All my tracks are old. I gave up on iTunes early and started buying my single tracks from amazon in mp3 format. Most of my music is ripped from cds at 320kb.
bollar
Disgruntled Member
Perhaps it's worth buying iTunes Music Match. That will remove the DRM and then you can download and cancel.
finallybuying
Member
Thanks. Looks like using iPhone stored music, or Spotify over Bluetooth is just asking for bad sounding compressed audio given these specs. Still can't figure out why there isn't a $5 audio input (or alternatively a way to play directly from a phone via a cord) for use with mobile phones. My 2006/7 Toyota has one.
Bummer.
Anyone ever modified the stereo to provide a direct audio input via 3mm jack or similar?
(I know I can use a sub stick but that doesn't help me stream audio from my phone.)
GaryREM
Member
I ran diagnostics on my iPhone and saw:
A2dpStreamConfig.cpp:598 PickStreamConfig Info A2DP Selecting remote AAC SEID 3
A2DPClient.cpp:1118 SelectStreamConfig Info A2DP Setting stream configuration for local SEID 4 and remote SEID 3 on device xx:xx:xx:xx:xx:xx "Tesla Model S", remote delay reporting 0, local delay reporting 1
...
A2DPClient.cpp:1260 SetConfigCfm Info A2DP Attempting to open streaming channel to device xx:xx:xx:xx:xx:xx "Tesla Model S"
...
A2DPClient.cpp:1330 OpenCfm Info A2DP Successfully opened streaming channel to device xx:xx:xx:xx:xx:xx "Tesla Model S"
A2DPClient.cpp:563 MediaConfig Info A2DP MTU for device xx:xx:xx:xx:xx:xx "Tesla Model S" has been changed to 1005
A2dpStreamConfig.cpp:708 SetAacDataRate Info A2DP AAC frame len: 743 bytes, num frames: 1, bitrate: 256 kb/s, rtp intr: 23219, rtpFrameLen 990, latency 92879
A2DPClient.cpp:2630 PublishAudioDevice Info A2DP Creating A2DPAudioDeviceModel for device Tesla Model S with handle 1
A2dpStreamConfig.cpp:102 GetCategory Info A2DP Publishing device as carkit
So, it looks like 256 kbps AAC was successfully negotiated over Bluetooth!
A2dpStreamConfig.cpp:598 PickStreamConfig Info A2DP Selecting remote AAC SEID 3
A2DPClient.cpp:1118 SelectStreamConfig Info A2DP Setting stream configuration for local SEID 4 and remote SEID 3 on device xx:xx:xx:xx:xx:xx "Tesla Model S", remote delay reporting 0, local delay reporting 1
...
A2DPClient.cpp:1260 SetConfigCfm Info A2DP Attempting to open streaming channel to device xx:xx:xx:xx:xx:xx "Tesla Model S"
...
A2DPClient.cpp:1330 OpenCfm Info A2DP Successfully opened streaming channel to device xx:xx:xx:xx:xx:xx "Tesla Model S"
A2DPClient.cpp:563 MediaConfig Info A2DP MTU for device xx:xx:xx:xx:xx:xx "Tesla Model S" has been changed to 1005
A2dpStreamConfig.cpp:708 SetAacDataRate Info A2DP AAC frame len: 743 bytes, num frames: 1, bitrate: 256 kb/s, rtp intr: 23219, rtpFrameLen 990, latency 92879
A2DPClient.cpp:2630 PublishAudioDevice Info A2DP Creating A2DPAudioDeviceModel for device Tesla Model S with handle 1
A2dpStreamConfig.cpp:102 GetCategory Info A2DP Publishing device as carkit
So, it looks like 256 kbps AAC was successfully negotiated over Bluetooth!
Amen! +1 on that. BT, USB and the supported music services are great, but are no substitute for a simple analog aux in. As just one of many examples, high res players like Pono, Astell & Kern, Sony, etc. with superior DACs are increasingly popular. Aux in would have been simple to design into the system, but from all I've read (a lot), quite involved to retrofit (especially for the Bose systems). The only option I can come up with (and might undertake for my base MS system), is to add/integrate an after-market amp (or amps) to run the OEM signal to each/all speakers. Then one could run an aux in directly to the new amp(s), and of course have more/better power for the existing OEM system. You wouldn't have steering wheel or touch screen control for the aux input -- would have to use the external device for volume, etc. -- one of the many reasons it should have been incorporated in the first place.
Please don't get me wrong -- I'm a huge Tesla fan and love my new 70D!!
ra-san
Member
My understanding on this, which was discussed in more detail on other threads if you want more links, etc., is that any "music" type audio from the iPhone will get decoded to raw audio before handing to the bluetooth stack in the phone, then re-encoded in stack to the 256Kbit rate and sent to the S.
Suboptimal, for sure, but still far better sounding than being stuck at the baseline Bluetooth codec. Not saying that no one could tell the difference between re-encoded 256Kbit and original 320Kbit (or even lossless), but I would be comfortable wagering that most Model S owners couldn't, particularly when actually in motion with all the associated noise. (*puts on flame retardant suit*)
Right, so the big question is......is that only when playing back an AAC file from your phone or does it show AAC even when playing back an mp3 from your iPhone? i.e. is it using AAC because that's the best sounding protocol that it can negotiate and will it transcode an mp3 in to AAC before leaving the iPhone? My guess is the answer to that last one is obviously no.
Still, if most people have high bitrate AAC music on their iOS device, it looks like bt audio won't be useless in that case.
Just wish they'd add Apt-X because it's irrelevant what the file format it. The apt-X driver on the device will transcode to lossless before it is transported over a2dp. That way you can play any audio of any file format and it should be as clean as plugging directly into the device.
ra-san
Member
Try it and see. My bet is what I said in the post right before. It'll be AAC over the Bluetooth link. Be nice if I was wrong, and iOS would see what the source is, what the link options are, and transmit without recoding if the bitstream is supported. But based on the Apple Bluetooth implementors paper, I don't think it currently does.
I wish they'd do Apt-X too since there's a lot of Android devices out there and most support Apt-X but not AAC over A2DP, but either I or you need to look again at Apt-X. While there has supposedly been a lossless variant due out basically forever (2009 first reference I can find), I can still find no evidence that it actually exists and is shipping on anything, much less many things. Without that vaporware version, Apt-X is much like AAC - a really good lossy codec. If Apt-X Lossless actually exists outside of a bulletpoint lists of the Apt-X family, white papers, and marketing blurbs (and lots of dead links), I haven't been able to find it. Is it (the lossless option - not "normal" Apt-X, which is very common) provably shipping in *anything*?
A lossless Bluetooth codec would eliminate most of the remaining objections people have. Would love to see it widely implemented.
I wish they'd do Apt-X too since there's a lot of Android devices out there and most support Apt-X but not AAC over A2DP, but either I or you need to look again at Apt-X. While there has supposedly been a lossless variant due out basically forever (2009 first reference I can find), I can still find no evidence that it actually exists and is shipping on anything, much less many things. Without that vaporware version, Apt-X is much like AAC - a really good lossy codec. If Apt-X Lossless actually exists outside of a bulletpoint lists of the Apt-X family, white papers, and marketing blurbs (and lots of dead links), I haven't been able to find it. Is it (the lossless option - not "normal" Apt-X, which is very common) provably shipping in *anything*?
A lossless Bluetooth codec would eliminate most of the remaining objections people have. Would love to see it widely implemented.
Apt-X is supported on nearly every audio bluetooth device. I have 6 pairs of BT headphones and they all support it. My Mac supports it. All my Android phones since the Galaxy S3 have supported it. Nearly every android device even other than Samsung now supports it. It's the only reason I don't wire up any more. I buy good quality headphones that have awesome amps inside of them and let them do the decoding of the apt-X stream.
I even have BT headphones that don't say they support it but when you cannect to a Mac and look at the codec used, says apt-X(at least for headphones I've bought in the last 2 years). It's so common now that many manufacturers don't even market it any more.
I even have BT headphones that don't say they support it but when you cannect to a Mac and look at the codec used, says apt-X(at least for headphones I've bought in the last 2 years). It's so common now that many manufacturers don't even market it any more.
ra-san
Member
Understood Apt-X is well supported (and is what I said). However, you implied the typical implementation was lossless. That variant is as far as I can see vaporware since 2009. The typical apt-x quality level is very similar to AAC. Would love to see support for it too, in addition to the AAC support. Would really love to see a widely implemented lossless Bluetooth codec too.
Similar threads
