BasedHardware
sample webserver
This implements a sample webserver for for the sdks in python. It uses uv to handle dependencies which is pretty standard nowadays.
The webserver saves the data to .wav and .opus files, demonstrating decoding opus data and exposing a local webserver to the internet (and thus the phone) via ngrok.
Please add a description to your pull request along with some screenshots or a video to demonstrate how it works. An empty pull request makes it difficult and time-consuming for other developers to understand what’s going on.
Also, the README is currently empty — please fill it in with basic instructions on how to get started. This will help others test and contribute more effectively.
man @AnkushMalaker , appreciate you help but it's cleaning time now.
feel free to re-open it later if needed
/ closed
@skywinder @beastoin , thanks for your feedback and time, I've updated the PR with details.
The thing to note here is that with my devkit, some of the frames are failing to decode
LOG Received message from backend: Received 37 bytes (decoding failed)
LOG Received message from backend: Received and decoded 41 bytes
LOG Received message from backend: Received and decoded 42 bytes
LOG Received message from backend: Received and decoded 36 bytes
LOG Received message from backend: Received and decoded 50 bytes
LOG Received message from backend: Received and decoded 40 bytes
LOG Received message from backend: Received 42 bytes (decoding failed)
LOG Received message from backend: Received 37 bytes (decoding failed)
LOG Received message from backend: Received and decoded 36 bytes
LOG Received message from backend: Received 37 bytes (decoding failed)
LOG Received message from backend: Received and decoded 38 bytes
LOG Received message from backend: Received 37 bytes (decoding failed)
LOG Received message from backend: Received and decoded 36 bytes
LOG Received message from backend: Received and decoded 48 bytes
This COULD indicate the root behind the clicking, I'm not sure. It should take at max 5 minutes to run this example end-to-end and validate if this happens on other devices.
The Omi SDKs are designed to support functionalities of the Omi device when connected directly to a specific platform. The back-end shouldn't be involved here.
If you're just trying to debug the clicking issue from the device, I suggest starting by answering the following question:
- Are the audio bytes transmitted from the Omi device to your computer (or phone), via an app using the Omi SDK, clean? In other words, is the clicking issue happening at that stage?
I will keep the PR here in a week to see if we could find the value of merging this PR or not.
Keep diving man.
@AnkushMalaker
See, and that's exactly why I think we need an example backend at the very least that shows how to interact with the data from these sdks. There are just two key points here: Strip header, decode opus.
But I'm getting decoding errors. Could I have been doing something wrong? Not sure. Again, that's why we may need an example.
Without the decoded audio (without corruption), being saved to a .wav file properly, I can't verify if the audio is clean.
I will keep the PR here in a week to see if we could find the value of merging this PR or not.
Just want to clarify: this pull request should be treated as an open issue related to the clicking sound. We should not merge it unless we find it genuinely helpful, but it’s useful to keep it open while the issue exists, as it significantly helps with debugging.
Once we identify the root cause and figure out how to fix it, we can decide whether this PR is still needed — and either merge it if it’s useful, or close it if not.
But please don’t close it yet — it’s important to keep the thread active so we can continue working on the issue and tracking the research progress here.
Also, please, for the whole team and for people who don’t know what it’s about, explain why it’s needed and in which cases to use it, so everyone can review and fully understand its purpose here.
Some people might think it should be outside and just referenced from the repo. If it’s an essential part of debugging, then it needs to be explained clearly right here, so others can easily understand it without searching, googling, or asking questions.
So please make these changes to keep it simple for everyone.
any updates on this one @AnkushMalaker @skywinder or should we create a issue instead of keeping that PR ?
the issue is already created here https://github.com/BasedHardware/omi/issues/2165
I'm working on firmware part and will handle this when will start to refacror SD card writing logic. As for now it's useful helper to debug.