Have a few devices that keep conflicting with one another and acquiring the connection to my bluetooth headset. I have to go through the hassle of navigating to the offending device's bluetooth settings, disconnect it, go to my desired device's settings (which, although it reports it is connected, doesn't actually produce any sound), disconnect it, then reconnect it. Each time.
I'd rather have them all stay connected (maybe one cheap dongle per endpoint) to my rpi and then route to the intended destination with just a press of a physical toggle/key/slider etc, or via phone app.
Additionally would like to be able to simultaneously mix multiple audio sources to the one headset.. oh, and all of this with no latency overhead, please :)
I just tried, and I'm able to pair both my Macbook Pro and iPhone to my Linux desktop PC. The PC has Kensington Bluetooth USB dongle. Both the MBP and iPhone can simultaneously play audio over Bluetooth and I can route the incoming audio to a pair of wired headphones. The volume of each stream is independently adjustable via `pavucontrol`.
I also tried pairing a bluetooth headset, but the audio was choppy. Maybe too much bandwidth for 3 devices streaming audio at once? Maybe another dongle would work?
Note that at one point I was experimenting with receiving BT audio on my PC. I can't remember the exact set of configuration changes needed to make this work (if any -- it might've worked out of the box). But the stack is BlueZ + Pipewire on Archlinux.
Pipewire (and Pulse) have a lot of modules and config knobs. Might be possible to get auto-switch working too. They also expose a D-Bus interface, so control from some sort of e.g. Python webapp from your phone is likely.
Definitely possible, and I've done a similar proof of concept using PipeWire with "Wireplumber" as the GUI to map the required inputs/outputs to a wired headset.
The problem was that I had no clue where to even begin to make this setup persistent so I could eventually put it all on a GUI-less RPi, so I gave up.
> I also tried pairing a bluetooth headset, but the audio was choppy.
Try reconnecting it. I have the same problem with my headset sometimes and reconnecting fixes it. My best guess is the implementation of the two Bluetooth modules don't play nice with each other. I have no troubles connecting to a different pc.
You could do it with a 4 channel mixer and USB audio devices hooked up to one Bluetooth transmitter... I don't know about latency though and good luck with the cable management!
I think the reverse of this kind of exists in the from of Bluetooth to 3.5mm receivers.
The one I have and most I've seen support two connections so I can have both PC and laptop output sound on some speakers.
You could probably chain a multi input receiver to a single output transmitter via 3.5mm to your Bluetooth headphones and just toggle connections on the receiver to select the device you want your headphones to use.
The bad news is the latency which is about 200ms regularly and 40ms with APT Low Latency or 80ms with APT Adaptive. If you go BT > BT RX > BT TX > BT this might be doubled. Both devices will also need to support the same codes and only newer devices support APT Adaptive.
I had plans to do such project for exactly same reasons since, like, 2011..
Wanted to have pulseaudio/alsa dmix handling multiple streams/mixing them out with a help of dedicated hardware BT/DAC-ADC-BT path, with a goal to have smart handling of voice calls over music on the go, fake 5.1 in the room, and a voice enhancer / fast rewind for call streams..
Then, Volumio took enough of the raspberry-based hifi market (despite having no bluetooth support, lol) that I've declared these plans no-go as investing in this solely for fun wasn't that enticing, compared to just getting a spare set of equipment to separate work/home audio.
I like this project but the hardware seems quite overpriced at $300+. Similar for tinypilotkvm.com.
In the past I've considered making and selling a cheaper version. Aside from lack of time (or motivation), one thing which discouraged me is that I would feel bad "undercutting" someone selling open hardware.
I understand the feedback about the price. When I created the original TinyPilot,[0] I wanted a low-priced alternative to the $600 KVM over IP options I was seeing, and now I sell my devices for $400-500/unit.
The thing that's tough about selling hardware is that it seems easy to produce a few units cheaply, but creating a sustainable business for it, the costs add up. You have to fulfill orders, provide support when there are delivery issues, provide support when the customer has trouble understanding how to connect to a device on their local network. And there's certification, stockpiling components so you don't run out of stock, managing inventory from many different vendors.
TinyPilot became profitable in 2023, but for the first 2.5 years, we were operating at a loss. [1]
Also, small correction: no KVM over IP vendor is really selling open hardware. The part that's open is the software. I haven't seen any vendors publish their hardware schematics. It's expensive to create PCBs, and it's not like open-source software where you can hope to get useful external contributions.
I have been following the TinyPilot project on & off for a while, and I just wanted to say I appreciate your openness as well as your excellent attitude toward feedback. I think many of us (myself included) have been spoiled with various forms of free/open software and have come to expect things to be cheap or free.
But of course github stars and positive reviews won't pay our bills. So it totally makes sense to charge what you are charging for your product. You deserve it, and you're clearly putting in hard and honest work. If and when I need a KVM I will 100% be reaching for a TinyPilot.
Hey, thanks for commenting. I'm a big fan of your transparency and don't get me wrong, I like the product and the price is certainly better than the "enterprise" gear.
But I personally don't care about support, the enclosure can be 3d printed or some cheap plastic box, if sold as DIY kit it would save assembly costs and avoid need for certification and so on. I think there is a small market for homelabers like myself who would pay maybe $100-150 for a simpler product.
>But I personally don't care about support, the enclosure can be 3d printed or some cheap plastic box, if sold as DIY kit it would save assembly costs and avoid need for certification and so on. I think there is a small market for homelabers like myself who would pay maybe $100-150 for a simpler product.
We used to sell both the pre-made units and a $190 DIY kit. Surprisingly, when I tried removing the DIY kits, sales jumped by 50%. And it wasn't just higher revenue because people were buying the more expensive product - order volume increased too.[0]
My theory is that when we asked customers if they wanted to pay more for a pre-made version, some of them stopped to think about which version they wanted and then just never returned. So, when we simplified to just one product, it eliminated friction in the buying process.
With the Pi 4 shortage the past few years, using our limited Pi 4 supply for DIY kits instead of our pre-made product would be a terrible move. We're expecting the shortage to be over in the next few months, but even if there was a way for me to sell an extra 50 units per month at a $50 profit, selling a second product line and managing it end-to-end is so complicated that it wouldn't be worth the extra $2.5k/month. And that $2.5k/month is before chargebacks, hiring people to assemble and fulfill the kits, etc.
We do still work to serve DIY customers and make sure our software stays compatible with users who just use off-the-shelf parts. And we still sell a power splitter,[1] as it's the one thing you can't really buy off the shelf from other vendors. We're able to do that because they cost about $10/unit to make, so we can make a year's worth in a week and just ship them to our warehouse. But doing that with a whole kit would be way more costly.
> provide support when the customer has trouble understanding how to connect to a device on their local network.
Is it possible to order current revision of TinyPilot for someone in a remote location and connect to it on arrival through some managed service - without going through all the hoops of helping end user with setting up some form of reverse shell (e.g. either meshcentral or openvpn/wireguard for webinterface)?
If you REALLY want to try it and you have PiKVM, you can contact us at Discord (https://discord.gg/bpmXfz5) and we will give you access to the beta version.
Customers could do that on their end, but they'd have to buy the device from us, configure it for remote access,[0] and then forward the device to the final destination.
Well said Mr. Founder. I think the best that can be wished for, would be the pi-hat/screws/case/etc plus a howto & code. perhaps you could explore the ce vs. pro version (ce being dated, less feature rich than pro. By getting your tech in the hands of thinkerers/homelab-builders, you will ensure once they get into the enterprise, they willa dvocate for paid products from you.
I'm very impressed with your write up and transparency. I hope the manufacturing issues are sorted out! I don't manufacture anything but I've read a 3x rule of sale price to raw input cost.
You’d be surprised at how expensive it can be to manufacture, program, test, package, warehouse, sell, ship, and support small hardware projects like this.
It may seem overpriced when compared to collecting all of the pieces and putting them together for yourself, but the person trying to do this as a business has to make a big investment in up front purchasing as well as labor to get them all together and shipped out. It quickly reaches a point where doing it for an “undercutting” level price doesn’t justify the risk and effort.
It helps to remember that your own time has a cost associated with it. Standing one up from pieces is probably a couple of days of indecision over component selection and loss to misc software refusing to behave itself.
An arm soc is probably $100. So break even is maybe $200 per day getting the thing working. Thus should buy the thing, unless you particularly enjoy the construction process more than whatever else you could spend the weekend doing.
The posted profit over time figures suggests the above back of envelope is rather optimistic, so there's a non-zero risk that after the weekend the thing wouldn't work.
(and thus I've learned that the UK distributor is in Germany with possible brexit/VAT hazards, but hopefully it'll turn up at some point)
Note there are also alternative Pi-KVM hardware boards (in a variety of formats) from BliKVM.
They don't seem to directly support the upstream project, and I believe they may have even forked some of the software from PiKVM and TinyPilot both and may or may not have provided proper attribution/recognition... so take that as you may.
This project is a full-time job for an entire development and support team, and it's a way to keep the software open. For this money you get excellent hardware, software without any restrictions and a huge number of features. We also have a production-grade support: if you find a bug, it will be fixed quickly, and if the device fails due to a defect, we will quickly replace it.
In fact, we have developed and support all the key components of the KVM stack for Linux - the video server, kernel patches, and so on, which is also used by our competitors, like TinyPilot. But unlike them, we don't impose any licensing restrictions - for example, buying TinyPilot you find yourself bound by a subscription, and if you stop paying, your OS will no longer receive updates. With PiKVM, you don't need to do this - the device is yours forever, with updates until the end of time.
In addition, the production of large quantities of iron is quite expensive. Each device must be assembled, tested, packaged, and so on. When you do some small project, you can do it yourself, but in a large batch it inevitably has to be delegated to the factory, where each operation costs a certain amount of money.
In summary, that's where the price comes from: software, support, development, people.
>But unlike them, we don't impose any licensing restrictions - for example, buying TinyPilot you find yourself bound by a subscription, and if you stop paying, your OS will no longer receive updates. With PiKVM, you don't need to do this - the device is yours forever, with updates until the end of time.
This is true and is a fundamental difference between PiKVM and TinyPilot.
TinyPilot charges a yearly subscription for customer support and software updates because those things have ongoing costs.
I don't think small businesses can realistically promise customers free support and updates for life. It may work in the short term, but at a certain point, it's not sustainable for a vendor to spend their limited support and dev resources on customers who purchased hardware five years ago and will never pay the vendor another dime.
Well, I don't know what you consider a short term, but PiKVM feels pretty good throughout its existence, and it has been for several years. It seems that we have set priorities differently at the start. My policy has always been that throughout the entire lifecycle of the device, the user must be sure of its security. In particular, this means that the user must receive updates. There is nothing more important than security when it comes to equipment, and I hate when a device turns into a unsafe brick after a few years. That's why we put it into the business model even before the first Kickstarter.
Another thing that made it possible to do this is the automation of all routine processes, such as testing and package builds. In PiKVM, the first component that was written was a build system to solve this issue once and for all. In this vein, I made a huge contribution to the "pre-launch" before flying. BTW, to be honest, I was somewhat surprised that you used Ansible instead of packages, it seems that this caused you a giant overhead for support.
Of course, in the future we plan to provide some paid services, but this does not concern the regular OS and access to updates at all, they should remain free.
>* BTW, to be honest, I was somewhat surprised that you used Ansible instead of packages, it seems that this caused you a giant overhead for support.*
Why didn't you tell me three years ago?!? : )
Yeah, Ansible was a huge mistake.[0] I knew it wasn't the right tool for distribution, but starting out, I just stuck with the tools I knew. We finally purged it in our last release and moved everything to standard Debian packages.
I'm glad to hear that PiKVM's stragegy has been working. I know our two projects are often pitted against each other, but I think there's ton of space for both of us to win back market share from the huge enterprise players and their consistently weak KVM offerings.
I have some experience operating large clusters and distributing software, and these damn things like Ansible have never led us to anything good. So either packages or the whole chroot (docker, whatever).
In fact, I'm a fan of the good old time-tested solutions. You know, Makefiles, packages, maximum integration with native OS tools. A lot can be done with simple tools, and although the start will be difficult, the support will be simple.
> there's ton of space for both of us to win back market share from the huge enterprise players
Ofc. In addition, users clearly benefit from competition.
You can save even more by making the splitter/power blocker yourself. It's simple enough that you can even do it by twisting instead of proper soldering, as long as you have a couple of cables you can sacrifice. On top of that you can get a cheaper hdmi-usb converter instead of using MIPI.
They don't recommend it because the latency is bad and it's awkward, but it's still serviceable, especially if you only use the KVM for quick tasks. Doing it this way you could make the thing for only about ten euro cost on top of the pi.
Roll your own. I've got one running PiKVM software on a Pi Zero 2W with an AliExpress HDMI-CSI board connected, and the whole thing bundled together with kapton tape and hanging off the USB port on a headless system. I had to mask off one pin on one of the two microUSB cables. I think I'm into it for about €50 including the Pi0. The instructions are/were on their website.
I wonder if the cost can be cut by replacing computer part with ESP32 at the cost of losing .iso mount and video input quality, and at the same time take out SD card anxiety. The only problem is difficulty of getting framebuffer cheaply, I think.
But it's also bloat on a rescue device. KVM has to and only has to work when a remote computer is unable to come back online, no need for computing power or app marketplace to fix that.
I once wanted to build one like this, but for console devkits. That situation was and went, but I did end up wanting to have the same for all windows machines at work and home (Unity dev, so workstations, test runners even servers are desktop windows machines).
My solution was:
-BIOS: auto-power on when power is connected
-Smart power plugs on important computers
-AnyDesk for software on all machines, with unattended password set (connectable even at login screen, less annoying for licenses than Teamviewer)
-(Optional) my own WoL sending / restarting / RAT program for all the machines too
-(Optional) Parsec also installed, to allow remote desktop good enough latency/control wise for actually gaming remotely (which I often did!)
This way, I will never be stuck in a situation that I can't access a machine that I'm away from, unless it's one of those without a smartplug and has somehow hard crashed. Costs less than 20€ per machine. I've NEVER needed to access the bios or similar remotely.
I've recently played around with a lot of SBC's and have a spare capture card and cheaper sbc's that could work as OTG keyboards. Might end up building a crappy version of one of these for fun
Can I ask what is the exact point of adding more NIC's? Considering one can just hard reset the machine remotely, a network card driver goof (like I've gotten with maxwell 10gbit cards) should be clearable.
Unless you mean a separate internet connection entirely?
I have one and indeed my only use of it is to type in BitLocker password when I'm not at home. I really hope one day I can just ssh in and unlock the disk like what I do with LUKS.
If price is a barrier, a less open, fiddlier, but much cheaper ($79) solution I've used recently is the Aurga viewer[0]. You have to use their awful apps to access the device, but if you can get past that, it does work - I was able to access and control the BIOS of a NUC I had in a closet. It can join a wifi network or host its own, which is useful in the field.
The suggested CSI2 adapter works up to 25fps at 1080p, while this one which also declares compatibility with the Rpi goes up to 60fps at the same resolution.
Can you explain what all would be needed to make a similar setup? I see the dongles for ~30 but does it need to be in a location with another piece of hardware or what?
Correct, the dongles connect via ethernet cables (not ip protocol) to the raritan unit. Then you access the raritan via IP to access the dongle outputs.
There is a great video from Level 1 Techs where he explains why he started making KVMs and why it is an extremely hard problem. (Edit: I can't seem to find the video now, it might have been on another channel, but I'll keep looking)
The TLDR is that manufactures don't follow specs as closely as you'd think, and as a KVM you have to handle the bugs of thousands of different manufactures for both upstream and downstream devices.
Best value I've found is a just a cheap USB switcher for the keyboard and mouse and use the monitor input switch for video. Might not work for all use cases, but if you just have 2 computers you want to switch between it works pretty well.
Adding to this: search for haimgel/Display-Switch[1] on GitHub, which can switch monitor inputs using DDC commands on USB connect/disconnect events. Poor man's KVM :-)
I've recently seen this project in Wolfgang's Channel [0]. The team behind it seem to be pretty nice about the open source nature of it and the DIY ways of getting a similar hardware doing the same thing as their own product. Kudos to them!
i got the V3 a bit ago, was definately worth it for an out-of-box running solution. though the fan settings needed fiddling so as to not make too much noise.
KVMD_FAN_ARGS="--speed-idle=50 --speed-low=60 --temp-low=50"
anywhoo for those who never and are curious the lag is almost entirely on the return channel, processing the hdmi signal and getting it back to client side.
it is definatley useable for programming but certainly not for any interactive graphics or gaming.
i'm wondering if since its a processing bottneck if overclocking the pi would speed it up a bit... it seems to idle at around %20 usage as per the little display.
I'm glad projects like this exist, but I'm too lazy and more than happy to have a Pi provide a serial console and a hardware reset via GPIO over IPv6 for colocated hardware. It's much simpler ;)
The problem with IPMI / iLO / iDRAC is that they're not secure. You can't safely put them on the Internet, so you need to pay your colocation provider for out of band connectivity and a separate drop.
To save money, I have a switch inside of my machines and have the serial console Pi on an IPv6 address. Having a fully up-to-date, modern OS makes a world of difference.
I'm currently working on a variation of this, specifically for accessing/controlling smartphones. My hunch is that even though a hardware-based KVM approach was meant for remote manual control, it could also be extremely useful for automation (and specifically test automation). But the big question is if anyone would agree with me about that. Hope to find out soon enough...
yeah, I saw those on amazon. Not sure how well they worked compared to the official PikVM board/kit. I might buy the CSI-HDMI adapter from Geekworm and try it out on a Pi4.
IP-KVMs are more useful for fixing remote access without physically interacting servers. In cases where a server is stuck in BIOS, BSoD, wrong IP configured, just waiting for a RETURN key input, etc. and not responding to RDP/VNC/SSH, an operator can log into KVM to unstuck it.
It can... but this goes one level lower to the hardware layer... so that you can do things like reboot the computer and view/edit BIOS settings (since you're viewing the same raw HDMI signal that would otherwise show up on a real monitor display). You wouldn't be able view the BIOS with Remote Desktop or VNC because those are not available until after the operating system has launched.
The project lists several DIY options for building (more like buying and plugging in) the hardware yourself. You might be able to find an off-the-shelf VGA-to-HDMI adapter/converter that would then be downstream compatible with the rest of the stack. There is discussion about VGA support in the project's GitHub Issues and Discord.
There are both VGA-HDMI and HDMI-VGA easily powered from a spare USB port, sometimes even HDMI bus power. I’ve heard the data can be converted line-by-line and timings are close enough that such devices never need to hold the complete framebuffer.
> AMT is designed into a service processor located on the motherboard, and uses TLS-secured communication and strong encryption to provide additional security.[6] AMT is built into PCs with Intel vPro technology and is based on the Intel Management Engine (ME).[6] AMT has moved towards increasing support for DMTF Desktop and mobile Architecture for System Hardware (DASH) standards and AMT Release 5.1 and later releases are an implementation of DASH version 1.0/1.1 standards for out-of-band management.[7] AMT provides similar functionality to IPMI, although AMT is designed for client computing systems as compared with the typically server-based IPMI.
> To understand what PSP and ME can do you need to understand CPU security rings. https://en.wikipedia.org/wiki/Protection_ring . These are different levels of privilege software has on the system.
> Originally the Linux kernel occupies ring 0, which is the level with highest privilege. Then user space would run in some other ring.
> However with things like PSP and ME they have created rings lower then ring 0. Things like Ring -1 and -2. Intel Minix ME runs in -3 ring.
> DASH provides support for the redirection of KVM (Keyboard, Video and Mouse) and text consoles, as well as USB and media, and supports the management of software updates, BIOS (Basic Input Output System), batteries, NIC (Network Interface Card), MAC and IP addresses, as well as DNS and DHCP configuration.
Have a few devices that keep conflicting with one another and acquiring the connection to my bluetooth headset. I have to go through the hassle of navigating to the offending device's bluetooth settings, disconnect it, go to my desired device's settings (which, although it reports it is connected, doesn't actually produce any sound), disconnect it, then reconnect it. Each time.
I'd rather have them all stay connected (maybe one cheap dongle per endpoint) to my rpi and then route to the intended destination with just a press of a physical toggle/key/slider etc, or via phone app.
Additionally would like to be able to simultaneously mix multiple audio sources to the one headset.. oh, and all of this with no latency overhead, please :)