Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Server: compute the fade-in gain once per channel per frame, not once per channel pair

Đang mở
  • Có gì không ổn?
#3,945 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 5 ngày

@mcfnord đang làm issue này rồi.

Từ ngày 21/9/2026.

  • #3959 của @mcfnord — đang mở

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
68/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
c
Lĩnh vực
audio-video-rtc, performance

Hướng nghiên cứu

Bắt đầu trong src/server.cpp tại vòng lặp xây dựng vecChanIDsCurConChan và kiểm tra DecodeReceiveData, sau đó đọc GetFadeInGain() trong src/channel.h. Xác minh rằng gain của mỗi kênh đã kết nối được lấy một lần cho mỗi frame và được dùng lại cho cả hai phép tính cặp, trong khi đầu ra vẫn không thay đổi; sử dụng benchmark được liên kết để so sánh hình dạng của các vòng lặp.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

AI refactoring

🤖 AI: Follow-up to ann0see/jamulus#293, opened at @ann0see's request.

What is the current behaviour and why should it be changed?

The gain loop in DecodeReceiveData calls GetFadeInGain() twice per channel pair, once for the source channel (line 909) and once for the target (line 915): 2N²−N int-to-float conversions and float divisions per frame, 44850 at N=150. The N values behind them are constant for the frame. Both counters are written only in PutAudioData and OnNetTranspPropsReceived, reached under CServer::Mutex from PutAudioData and OnProtocolMessageReceived, and OnTimer holds that mutex for the whole decode phase, single- or multithreaded.

Describe possible approaches

Read each connected channel's fade-in gain once into a CVector<float> in the loop that builds vecChanIDsCurConChan, and multiply by vecfFadeInGains[j] and vecfFadeInGains[iChanCnt] at lines 909 and 915 — #293's one-read-per-channel pattern applied to the remaining per-pair accessor, independent of that PR. The output is unchanged: a benchmark of the two loop shapes with a lock-free gain read produces byte-identical matrices at N=50, 100 and 150, and times the fade-in term alone (Raspberry Pi 4 Model B, g++ 14.2 -O2, median of 5 batches, 64-sample frame):

N per pair per frame saving share of a 1.33 ms frame
50 15.4 µs 5.4 µs 10.0 µs 0.75%
100 59.4 µs 21.3 µs 38.1 µs 2.9%
150 136.3 µs 40.6 µs 95.7 µs 7.2%

At the default 128-sample frame the microseconds are the same and the shares halve.

Has this feature been discussed and generally agreed?

Requested by @ann0see on #293; no PR until the design is agreed here.

🤖 This message was written by AI and reviewed by @mcfnord.

Ngôn ngữ chính
C
Star
1.1k
Fork
248
Merge trung bình
7 ngày 4 giờ
Pull request đã merge (30 ngày)
5

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của jamulussoftware/jamulus

Tất cả issue của jamulussoftware/jamulus

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.