usb_audio.USBSpeaker: Speaker audio does not adjust based on Windows volume slider/mute.
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- c
- Lĩnh vực
- embedded-iot
Hướng nghiên cứu
Start by reading the Feature Unit descriptor in shared-module/usb_audio/init.c and tracing how volume and mute are handled in tud_audio_set_req_entity_cb, usb_audio_usbspeaker_background_drain(), and usb_audio_usbspeaker_get_buffer(). Determine which behavior the project should adopt: apply the controls to samples, stop advertising them, or expose them to Python. Done means Windows volume and mute work as expected under the chosen approach, with relevant tests or verification documented.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
CircuitPython version and board name
Adafruit CircuitPython 10.3.0-alpha.4; Adafruit QT Py RP2040 with rp2040
Code/REPL
# in boot.py
import usb_audio
usb_audio.enable(speaker=True, microphone=False)
Behavior
The device correctly registers to Windows 11 Pro 25H2 as a CircuitPython Speaker but adjusting the master volume slider or muting it at the Windows level has no effect on the audio.
Description
No response
Additional information
AI Analysis (Cursor Grok 4.6)
Windows volume does nothing because USBSpeaker claims hardware volume, then never applies it.
The taskbar slider and keyboard volume keys are endpoint volume. On a USB Audio Class 2 speaker, Windows treats that as a hardware Feature Unit control: it sends full-scale PCM and a SET_CUR volume/mute request, and it does not insert a software volume APO.
CircuitPython does the first half of that contract and skips the second.
- The descriptor advertises a real volume control. The speaker Feature Unit marks mute and volume as read/write on master and both channels:
shared-module/usb_audio/init.c
Ln 173–174
/* Feature Unit Descriptor(4.7.2.8) */
TUD_AUDIO20_DESC_FEATURE_UNIT(..., AUDIO20_CTRL_RW << MUTE | AUDIO20_CTRL_RW << VOLUME, ...)
Windows therefore binds the system slider to hardware and will not attenuate the stream itself.
- Firmware stores the host’s volume, then ignores it.
tud_audio_set_req_entity_cb writes usb_audio_mute[] / usb_audio_volume[]. Those arrays are only read back forGET_CUR / GET_RANGE. They are never used when samples are copied.
usb_audio_usbspeaker_background_drain() and usb_audio_usbspeaker_get_buffer() memcpy the USB PCM unchanged. There is no scale, no mute-to-zero, and USBSpeaker exposes no volume/mute property you could apply in Python.
So the slider moves (the SET_CUR succeeded) and the speaker stays at unity gain.
- That is why this is a Windows-specific complaint. macOS and Linux often still apply software volume in the host mixer. Windows does not, once a Feature Unit Volume control exists. Per-app sliders in Volume Mixer can still work, because those are session volumes applied before USB. System / keyboard volume cannot.
A firmware fix has to do one of these:
Apply it: scale (and mute) each sample from the per-channel Feature Unit values. Windows prefers channel 1/2 over master when both are advertised.
Stop claiming it: clear Volume/Mute from the Feature Unit so Windows inserts its software volume APO instead.
Until one of those lands, the host-side workaround is the same as for DACs that advertise volume and ignore it: force software attenuation (WinSoftVol, Equalizer APO, or the per-app mixer).
Delegate it: expose the audio channel mute and audio channel volume parameters from Windows and let other code decide what to do with it.
- Ngôn ngữ chính
- C
- Star
- 4.6k
- Fork
- 1.4k
- Merge trung bình
- 1 ngày 6 giờ
- Pull request đã merge (30 ngày)
- 145
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của adafruit/circuitpython
-
board breaks api
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
adafruit/circuitpython#11099 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Feature/API request: portable camera capture across ESP-IDF, Zephyr, and parallel interfacesĐang mởcircuitpython api enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
adafruit/circuitpython#11505 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 38/100
adafruit/circuitpython#11472 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
adafruit/circuitpython#11467 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Add file truncate()Đang mởcpython api enhancement
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
adafruit/circuitpython#11402 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của adafruit/circuitpython
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
dkfans/keeperfx#5415 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
void-linux/void-runit#141 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
ARM-software/sysarch-acs#600 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày