CocoaLumberjack
willow
Our great sponsors
CocoaLumberjack | willow | |
---|---|---|
3 | 36 | |
13,116 | 2,351 | |
0.2% | 3.0% | |
8.6 | 9.6 | |
2 days ago | about 2 months ago | |
Objective-C | C | |
BSD 3-clause "New" or "Revised" License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
CocoaLumberjack
-
Looking for a flexible and fast logging library with file rotation support
On iOS using Swift I would depend on the CocoaLumberjack library to support all of my logging needs. It's fast, flexible, and very importantly, supports configurable log file rotationDDFileLogger(py)maximumFileSize). It's awesome.
-
How to log only in debug mode? including network logs
Does anyone have experience with this? I've seen people mentioning to use Cocoalumberjack but not sure if its the right package (meaning if its not overkill). Apple have an open source logging library as well for this.
-
Awesome macOS Libraries List
CocoaLumberjack - A fast & simple, yet powerful & flexible logging framework. Language: Objective-C.
willow
-
Should I Open Source my Company?
> - People might criticize my messy/bad/unfinished code
As someone who has created and maintained open source projects (most recently Willow[0]) for two decades I get a kick out of this.
Of course when interacting with users and feedback I keep it polite but in my head I'm thinking "You like to talk. I actually DID this. Shut up or submit a PR".
Surprise surprise they almost never do.
[0] - https://heywillow.io/
-
Jarvis: A Voice Virtual Assistant in Python (OpenAI, ElevenLabs, Deepgram)
Also check out Willow- https://heywillow.io
It doesn’t synthesize voice back (yet) but open source and runs all offline on ESP32-based hardware and works with HomeAssistant!
-
Any “Google Home” type solutions that work offline?
Look into https://heywillow.io/ - still early in the project but they are getting good results.
- Open Source Smart Device
-
Home Assistant 2023.11
Very nice!
Would you be interesting in integrating with my project Willow[0]?
Willow supports Home Assistant, OpenHAB, and generic REST+MQTT endpoints today. With Home Assistant and OpenHAB we benefit from their specific API support for providing speech to text output and processing through things like the HA Assist Pipelines[1].
From our standpoint we handle wake word, VAD+AEC+BSS, STT, TTS, user feedback, etc. All we really do is send the speech transcript to the Willow command endpoint (like HA) and speak+display the execution result. Other than all of the wild speech stuff and our obsession with speed and accuracy Willow is really quite "dumb" - think of it as a voice terminal.
OpenHAB has something similar but it's significantly more limited.
[0] - https://heywillow.io
[1] - https://developers.home-assistant.io/docs/voice/pipelines/
-
Distil-Whisper: distilled version of Whisper that is 6 times faster, 49% smaller
I'm the founder of Willow[0] (we use ctranslate2 as well) and I will be looking at this as soon tomorrow as these models are released. HF claims they're drop-in compatible but we won't know for sure until someone looks at it.
[0] - https://heywillow.io/
-
What's New in Python 3.12
Shameless self-plug but with my project Willow[0] we have a management server implementation to deal with multiple devices, etc. We have a new feature called "Willow One Wake" that takes the incoming audio amplitude when wake word is detected and uses our Willow Application Server (python) to only activate wake on the device closest to the person speaking. Old and tired compared to the commercial stuff but a first in the open source space.
The asyncio improvements in Python 3.12 especially (plus perf generally) have been instrumental in enabling real world use of this. With Python 3.12 asyncio, uvloop, and FastAPI it works remarkably well[1]. As the demo video shows not only does it not delay responsiveness, it has granularity down to inches.
[0] - https://heywillow.io/
- Show HN: Willow: the fastest and most private open source voice assistant
-
A Raspberry Pi 5 is better than two Pi 4S
For most people with self-hosting tasks amd64 is back as the way to go.
As you say, there are a ton of "minipcs" on the market that directly compete with the Raspberry Pi on cost and power usage. They're typically slightly larger but the expansion options (bring your own RAM/storage) plus real I/O (with real PCIe), disk, etc IMO significantly outweighs this. They're also typically more performant and while aarch64 platform support is increasing dramatically there are still the occasions where there's a project, docker container, etc that doesn't support it.
Taking it a step further, there are a TON of decommissioned/recycled corporate/enterprise SFF desktops on the market. They don't compete in terms of size (13" x 15" or so) but they can actually get close in power usage. Many of them have multiple SATA ports, real NVMe, multiple real half-height PCIe slots, significantly better USB and PCIe bandwidth, etc.
With my project Willow and Willow Inference Server[0] we're trying to drive this approach in the self-hosting community with an initial emphasis on Home Assistant. They're generally sick of Raspberry PI supply shortages, very limited performance, poor I/O, flaky SD cards, etc. The Raspberry Pi is still pretty popular for "my first Home Assistant" but generally once people get bitten by the self-hosting bug they end up looking more like homelab very quickly.
For Willow particularly we emphasize use of GPUs because a voice assistant can't be waiting > 10 seconds to do speech recognition and speech synthesis. There are approaches out there trying to kind of get something working using Whisper tiny but in our ample internal testing and community feedback we feel that Whisper small is the bare minimum for voice assistant tasks, with many users going all out and using Whisper large-v2 at beam size 5. With GPU it's still so fast it doesn't really matter.
The Raspberry Pi is especially poorly suited for this use case (and even amd64). We have some benchmarks here[1]. TLDR a ~seven year old Tesla P4 (single slot, slot power only, half-height, used for $70) does speech recognition 87x faster, with the multiple increasing for more complex models and longer speech segments. A 3.8 second voice command takes 586ms on the Tesla P4 and 51 seconds on the Raspberry Pi 4. Even with the Pi 5 being twice as fast that's still 25 seconds, which is completely unusable. Not fair to compare GPU to Raspberry Pi but consider the economics and practicality...
You can get an SFF desktop and Tesla P4 from eBay for $200 shipped to your door. It will idle (with GPU and models loaded) at ~30 watts. The CPU, RAM, disk (NVMe), I/O, etc will walk all over a Raspberry Pi anything. Add the GPU and obviously it's not even close - you end up with a machine that can easily do 10x-100x what a Raspberry Pi can do for 2x the cost and power usage. You can even throw a 2.5gb Ethernet card in another slot for $20.
Even factoring in power usage (10-15w vs 30, 2-3x) the cost difference comes down to nearly nothing and for many users this configuration is essentially future-proof to anything they may want to do for many years (my system with everything running maxes out around 50% of one core). Many also gradually grew their self-hosted situation over the years with people ending up with three or more Raspberry Pis for different tasks (PiHole, Home Assistant, Plex, etc). At this point the SFF configuration starts to pull far head in every way including power usage.
Users were initially very skeptical to GPU use, likely from taking their experience in the desktop market and assuming things like "300 watt power usage with a huge > $500 card". Now they love having a GPU around for Willow and miscellaneous other CUDA tasks like encoding/decoding/transcoding with Plex/Jellyfin, accelerated Frigate, and all kinds of other applications. Willow Inference Server (depending on configuration) uses somewhere between 1-4GB of VRAM so with an 8GB VRAM card that leaves for plenty of additional tasks. We even have users who started with the Tesla P4 and then got the LLM bug and figured out how to get an RTX 3090 working with their setup.
[0] - https://heywillow.io/
[1] - https://heywillow.io/components/willow-inference-server/#ben...
- ChatGPT can now see, hear, and speak – openai.com
What are some alternatives?
SwiftyBeaver - Convenient & secure logging during development & release in Swift 4 & 5
piper - A fast, local neural text to speech system
NSLogger - A modern, flexible logging tool
esp-box - The ESP-BOX is a new generation AIoT development platform released by Espressif Systems.
XCGLogger - A debug log framework for use in Swift projects. Allows you to log details to the console (and optionally a file), just like you would have with NSLog() or print(), but with additional information, such as the date, function name, filename and line number.
mycroft-core - Mycroft Core, the Mycroft Artificial Intelligence platform.
CleanroomLogger - CleanroomLogger provides an extensible Swift-based logging API that is simple, lightweight and performant
rhasspy3 - An open source voice assistant toolkit for many human languages
Logkit - An efficient logging library for OS X, iOS, watchOS, and tvOS – written in Swift. Log to console, file, HTTP service, or your own endpoint. Simple to get started, but smartly customizable.
vllm - A high-throughput and memory-efficient inference and serving engine for LLMs
JustLog - JustLog brings logging on iOS to the next level. It supports console, file and remote Logstash logging via TCP socket with no effort. Support for logz.io available.
willow-inference-server - Open source, local, and self-hosted highly optimized language inference server supporting ASR/STT, TTS, and LLM across WebRTC, REST, and WS