I’ve been working with the Arduino UNO Q and experimenting with App Lab for controlling hardware features. Everything works as expected on the Linux side — including camera input and microphone audio input — but I’ve encountered a limitation that I’d like to ask about.
Specifically:
The UNO Q has no onboard audio output hardware, and that’s fine.
Standard USB audio adapters (USB Audio Class) are correctly recognized by Linux as ALSA output devices.
I can install vlc / ffmpeg on the Linux host and play audio through such an adapter directly from the host.
However, from within Arduino App Lab:
I cannot find any brick or API to access audio output.
Attempts to invoke system audio players from App Lab (e.g., via subprocess) fail because these binaries aren’t visible in the App Lab container.
Python libraries that might decode audio (e.g., miniaudio) fail to install due to lack of a C++ toolchain and wheels.
Given that App Lab does expose other hardware features (camera, mic input), I was surprised that audio output isn’t currently supported.
My questions are:
Is audio output support (e.g., playing audio via USB sound cards) planned to be exposed in App Lab in the future?
Is there a recommended pattern or workaround for audio playback from App Lab on UNO Q?
Are there any documented audio API bricks for App Lab that I might have missed?
My goal isn’t just to play a static audio file, but to build interactive apps with audio output — so I’m looking for the appropriate way to do this within the App Lab environment.
In general, I agree that Audio subsystem in Uno Q is painful to work with. Not polished, not proven at all. Need some time probably for Arduino devs or maybe it was low priority for them, who knows...
Thanks a lot for the clear explanation and the links.
This confirms my understanding of the current limitations of audio on Uno Q, especially from App Lab.
It is good to know this is more about the platform maturity than a misuse on my side.
No prob. Today, after weeks of fighting, I finally managed to get Bluetooth sound from my robot without any interactive logon (neither xrdp nor ssh), fully from system service autostart. This is not an Arduino problem, this is damn Debian and PulseAudio security. But it's manageable
Summary / feedback after some testing with audio on UNO Q + App Lab
After spending some time experimenting with audio output on UNO Q, I wanted to share a short summary of my findings, in case it helps others.
App Lab itself works well for UI and logic, but audio support is currently quite difficult to use in practice.
Playing audio directly from App Lab is limited by the sandboxed environment (no access to host binaries like mpg123, ffmpeg, etc.).
The Wave Generator / Speaker bricks look promising, but in my case the examples were not stable enough yet to rely on them.
For Bluetooth audio in particular, PulseAudio seems to be required, which pushes the solution outside of App Lab.
I understand now that the most reliable approach today is to run audio playback as a system-level service (systemd autostart) on the Debian host, and control it from App Lab (or elsewhere). This works, but it also means editing and maintaining code directly on the board.
Unfortunately, I also ran into an issue where the App Lab editor on the UNO Q itself no longer displays the code correctly, which makes on-board development difficult. Ideally, being able to work remotely over Wi-Fi from App Lab on a desktop (Mac/PC) would make this workflow much more practical.
Overall, it feels like the audio subsystem on UNO Q is still evolving and not fully polished yet. I’ll probably wait for future updates before going further, but I wanted to share this feedback for others exploring similar use cases.
Thanks to everyone who shared their experience and pointers in this thread — they were very helpful.
If you are able to provide instructions we can follow to reproduce the problem, this will allow the Arduino App Lab developers to perform an investigation and fix the bug.
You are welcome to submit formal bug reports to the issue tracker of the Arduino App Lab repository:
Alternatively, you can provide the information here on the forum and one of the Arduino employees who monitor this forum category (e.g., me) will see if we are able to submit a formal report on your behalf.
I'm not sure I understand what you mean by this. You can run Arduino App Lab on your desktop machine and connect it to the UNO Q board via the network.
Did you try that approach and encounter a problem while doing so?
I think I may have expressed myself poorly earlier, as English is not my native language — sorry for the confusion.
The situation has been clear in my mind from the beginning, but I didn’t describe it precisely enough.
To clarify clearly:
When using Arduino App Lab directly on the UNO Q board (local UI with screen and keyboard), the editor shows an empty main.py file.
When using Arduino App Lab from my Mac mini over Wi-Fi, connected to the same UNO Q and opening the same application, the source code is displayed correctly.
The two attached photos show the exact same application opened at the same time:
App Lab running locally on the UNO Q → editor empty
Does the fault also occur if you create a new App (by going to the "My Apps" view, then clicking the "Create new app +" button), then open the main.py file of the new App in Arduino App Lab while running in SBC mode?
The reason I ask is to determine whether this is a global problem, or something that only occurs under specific conditions produced by your real "webRadio" App.
One additional observation / hypothesis (not certain):
Since it is possible to use the UNO Q locally (SBC mode) while the board is also accessible over Wi-Fi at the same time, there may be situations where Arduino App Lab is effectively connected from both the local UI and a remote desktop session.
I’m not sure if this is relevant, but it might be worth checking whether concurrent local and remote App Lab sessions could lead to the editor state becoming inconsistent in SBC mode.
Thanks for the clarification. Unfortunately Arduino App Lab is displaying the code files just fine for me, which makes it challenging to perform an investigation.
I'm going to ask you to provide some additional information that might help us to identify the problem.
This procedure is not intended to solve the problem. The purpose is to gather more information.
Please do this:
Access the UNO Q in SBC mode
If Arduino App Lab is already running, close all Arduino App Lab windows.
Start Arduino App Lab.
Press the Ctrl+Shift+F12 keyboard shortcut.
The "Web Inspector" window will open.
Select the "Console" tab in the "Web Inspector" window.
Right-click on the main panel of the "Web Inspector" window.
A context menu will open.
Select "Clear Log" from the menu.
The existing content will be cleared from the console panel.
Switch to the Arduino App Lab window.
Open an App.
Open the file of the App that exhibits the "empty" fault.
Verify that you can not see the content of the file in the Arduino App Lab editor.
Switch back to the "Web Inspector" window.
You should see some entries in the main panel of the "Web Inspector" window. Click and drag the mouse pointer over these so that they are all selected.
Right-click on the selection.
A context menu will open.
ⓘ Alternatively, if it is more convenient you can instead select "Save Selected" from the menu, save the logs to a file, then obtain the content from that text file.
Open a reply here on this forum topic by clicking the "Reply" button.
Click the <CODE/> icon on the post composer toolbar.
This will add the forum's code block markup (```) to your reply to make sure the error messages are correctly formatted.
Hello,
Just a short follow-up to close the loop on this issue.
I was able to fully recover the SBC and restore a working system using Arduino Flasher CLI. The key point, in my case, was to follow the hardware preparation step from the documentation and short the two EDL pins with a jumper before starting the flash procedure.
Without this, the Flasher CLI remained stuck on Waiting for EDL device, which initially made me think there was a software or tooling issue.
For reference, the recovery sequence that worked for me was:
Disconnect the board ;
Short the two EDL pins with a jumper ;
Reconnect USB-C ;
Run arduino-flasher-cli flash latest ;
After flashing, remove the jumper and reboot.
After this, App Lab and SBC mode are now working perfectly again.
I also kept one board in its previous state for further testing, in case it can be useful for investigating similar situations.
Best regards,
In the meantime, I explored an alternative approach using the Linux side of the UNO Q.
Instead of waiting for audio support to be exposed directly in App Lab, I implemented a small HTTP service running on the Linux side (radio_service.py), which controls audio playback using mpg123 and amixer.
This service is started automatically at boot via systemd, and the App Lab application simply acts as a controller (via HTTP requests).
The interesting part is that once the application is launched from App Lab, it continues running entirely on the UNO Q, even if App Lab is closed or the computer is turned off.
So while audio is not directly available as a brick yet, it is already possible to build a fully functional system by leveraging the Linux environment.
It was already mentioned earlier in this topic, but since the recent posts would seem to a casual reader to imply otherwise, I think it is worth stating once more that it already is exposed:
This code causes a /dev/snd/by-idvolume entry to be added to the Docker Compose file that is used to set up the Docker container in which the App's Python script. This happens when any sound hardware is available on the UNO Q board. This means the Python script has access to any sound devices.
Arduino provides a convenient high level arduino.app_peripherals.speaker Python package to facilitate working with audio output in the Python scripts of Apps:
Note that the use of that package is optional. You also have the option of using any other approach you like to working with the sound devices in your Python code.
You're right, I was not aware that audio output was already accessible from the App's Python environment.
That said, I explored a different approach using a Linux-side service (radio_service.py started via systemd), which allowed me to decouple audio playback from the App lifecycle and keep the system running independently after launch.
In particular, with this approach, audio playback is no longer tied to the App runtime, so it can continue even if App Lab is closed.
So even if a direct App Lab implementation is possible, this approach provides a different perspective in terms of architecture and autonomy.
Thanks again for the detailed explanation, and for taking the time to clarify this.
Best regards
P.S. Just to clarify: what I described was not only about audio playback continuing, but about the application itself remaining active on the UNO Q after launch.
This includes station changes, volume control, and stop functionality, even when App Lab is closed.
OK, then I'm glad I added that clarification. From your previous post:
, I was under the impression that you were aware of this, but hadn't found the capabilities to be sufficient for your needs:
There is never any need to keep Arduino App Lab running. The App runs on the board regardless of whether or not Arduino App Lab is open.
The one thing to keep in mind is that, by default, the App is not configured to automatically run after a power cycle/reboot. If you want that behavior, you can configure it in the App, as described here. However, the run at startup behavior is completely independent from having Arduino App Lab running either way.
Again, there is never any need to keep Arduino App Lab open. This is only a tool for developing Apps. The App itself is never in any way dependent on the Arduino App Lab application running.
In fact, you can create and use Apps without ever using Arduino App Lab once. Arduino provides a command line tool named Arduino App CLI that can be used as an alternative to Arduino App Lab for managing Apps (and in fact this tool provides much of the non-GUI functionality for Arduino App Lab under the hood).
Thanks for the clarification, that makes things much clearer.
I see now that the App lifecycle is completely independent from Arduino App Lab itself, and that Apps always run directly on the UNO Q.
My initial assumption was incorrect on that point.
In my project, the goal was actually to explore a different architecture by introducing a Linux-side service (started via systemd) to handle audio playback.
This allowed me to experiment with a more modular approach, decoupling the application logic from the audio backend and leveraging standard Linux tools.
Thanks again for the detailed explanation, it really helped me better understand how the platform works.
This procedure is not intended to solve the problem. The purpose is to gather more information.
