I would love to add something like Crankshaft to my car, but I needs so much retrofitting :( I would also lose my current FM radio, Bluetooth, etc that the car has. I hope there could be a better solution, too bad I bought the car right before Android auto came out...
We are releasing a patch that prevents the head unit from taking over the audio from the phone. It will allow you to keep the Bluetooth (or whatever normal audio path) you have :) That also means the Pi needs to do less too, which means it will not jank.
It means that you can use the Pi as just a display (instead of as a display and an amp at the same time).
Normally, when you plug the phone into the Pi, the phone won't play audio anymore. Instead, it asks the Pi to play the audio for it. Normally, that's a good assumption because it's connected to a dedicated head unit that has an amp. Now with this DIY RPi thing, we broke that assumption: the Pi has a bad DAC and doesn't have audio input (and the performance is janky now at times for unknown reasons).
I was just tipped by Emil, another developer who got really deep into hacking this. He told me that there are ways for the Pi to say "I'm not interested in helping you project the audio, you just keep playing whatever you normally play." So now your phone only projects the UI/maps to the Pi, but still routes audio/Hands-free directly to your stereo through BT. A benefit of that is you can use your handsfree, buttons/controls built into your steering wheels fine if your car has native Bluetooth.
That workaround has some problems with Chinese phones we realized, but works OK for a couple of Nexus/Pixel we tested.
Oh, that's amazing! I'm going to look into getting the kit and setting this up, thank you for all your work. My phone is a Xiaomi, so I don't know if it's going to have problems, but being able to navigate on a front-mounted display would be fantastic.
I guess I can just test it with my TV first, thanks again!
EDIT: Can you write some installation instructions somewhere prominently? I know I probably just need to burn the image to an SD card, but many others won't. I recommend https://etcher.io/, if you want to mention some piece of software, as that works quite well.
I wonder if you'll also see the same audio routing problems on Samsungs (S8?) as they do some custom audio stuff to support multiple bluetooth devices / multiple outputs.
MIT computer lab (Athena) workstations mostly all had a well-known local root password for years. The thinking seemed to be "make it not a mark of honor to get root and trust the users to be reasonable".
I was involved in multiple attempts at "net-boot linux and let the local user be root", what works best is exactly what is mentioned in the article: just wipe the thing each time.
But there are different approaches to this: on one extreme you can boot minimalistic linux from PXE which does moral equivalent of "curl ... >/dev/sda" on the other end you can run from ramdisk. The ramdisk approach works very well, but is neccesarily limited by size of RAM.
For our anime conventions we have our own "linux distro", that consists of debian unstable with quite involved rewritten initramfs which obtains the root image from somewhere (file on USB storage, which can be optionally mounted directly, or downloads the image using HTTP) and pivot_root's into that. Being able to boot Linux on ThinkPad without any persistent storage to speak of and being able to use it completely offline (the whole infrastructure for this to happen is only on our internal LAN, not on any kind of WLAN) is somewhat magical.
These days you could solve the problem with virtualisation: boot a small ramdisk that loads KVM with GPU passthrough, and give it a block device that's an LVM snapshot or something similar that you can reset every boot. Pre-KVM, you could have used Xen with a paravirt kernel.
I just made a live Ubuntu image that fits in 300MB RAM with libvirt.
I have a 5-year-old i5 computer with 8GB of RAM that I use as a Hackintosh with dedicated passthrough GPU, USB root hub, and an SSD. Having dedicated GPU and USB root hub are for performance obviously, but having a dedicated SSD means I could just pull the SSD out and plug it into a genuine Apple computer and it will work just fine. I have only two SSDs and didn't want to waste one of them to be the host OS, so I decided I would just pull another to-RAM trick to boot the host OS from a slow USB drive and put the host OS in RAM. The "abstraction layer" costed me 1GB. Just got done today, and I'm quite pleased with it. Now I have a "shell" distro that abstracts away my underlying hardware and gives me macOS regardless of what hardware I run it on.
That's right. I hope we had more time to polish it, but then it's only a couple of computers. So we were happy with the time we spent and the relative result we had. I planned to kind of doing the >/dev/sda thing and a checksum to not having to download it every time, but so little time, so much to do.
For the end user - it's just some computers at the convention, a couple of computers in the lab, but I knew it felt really good to see a computer without storage pulling crazy tricks like that.
I'm glad you enjoyed it. One thing I tried to do is not just document what I did, but also my intentions when I did it. That's one thing I learned from the Dolphin project.
21 comments
[ 3.0 ms ] story [ 70.0 ms ] threadNormally, when you plug the phone into the Pi, the phone won't play audio anymore. Instead, it asks the Pi to play the audio for it. Normally, that's a good assumption because it's connected to a dedicated head unit that has an amp. Now with this DIY RPi thing, we broke that assumption: the Pi has a bad DAC and doesn't have audio input (and the performance is janky now at times for unknown reasons).
I was just tipped by Emil, another developer who got really deep into hacking this. He told me that there are ways for the Pi to say "I'm not interested in helping you project the audio, you just keep playing whatever you normally play." So now your phone only projects the UI/maps to the Pi, but still routes audio/Hands-free directly to your stereo through BT. A benefit of that is you can use your handsfree, buttons/controls built into your steering wheels fine if your car has native Bluetooth.
That workaround has some problems with Chinese phones we realized, but works OK for a couple of Nexus/Pixel we tested.
I guess I can just test it with my TV first, thanks again!
EDIT: Can you write some installation instructions somewhere prominently? I know I probably just need to burn the image to an SD card, but many others won't. I recommend https://etcher.io/, if you want to mention some piece of software, as that works quite well.
The command
would print out the root password for the public workstations.The command
would spew insults at you.But there are different approaches to this: on one extreme you can boot minimalistic linux from PXE which does moral equivalent of "curl ... >/dev/sda" on the other end you can run from ramdisk. The ramdisk approach works very well, but is neccesarily limited by size of RAM.
For our anime conventions we have our own "linux distro", that consists of debian unstable with quite involved rewritten initramfs which obtains the root image from somewhere (file on USB storage, which can be optionally mounted directly, or downloads the image using HTTP) and pivot_root's into that. Being able to boot Linux on ThinkPad without any persistent storage to speak of and being able to use it completely offline (the whole infrastructure for this to happen is only on our internal LAN, not on any kind of WLAN) is somewhat magical.
I have a 5-year-old i5 computer with 8GB of RAM that I use as a Hackintosh with dedicated passthrough GPU, USB root hub, and an SSD. Having dedicated GPU and USB root hub are for performance obviously, but having a dedicated SSD means I could just pull the SSD out and plug it into a genuine Apple computer and it will work just fine. I have only two SSDs and didn't want to waste one of them to be the host OS, so I decided I would just pull another to-RAM trick to boot the host OS from a slow USB drive and put the host OS in RAM. The "abstraction layer" costed me 1GB. Just got done today, and I'm quite pleased with it. Now I have a "shell" distro that abstracts away my underlying hardware and gives me macOS regardless of what hardware I run it on.
KVM/qemu are dreams come true.
For the end user - it's just some computers at the convention, a couple of computers in the lab, but I knew it felt really good to see a computer without storage pulling crazy tricks like that.