Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

Những người góp phần vào độ trễ âm thanh

Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.

Trang này tập trung vào những người đóng góp vào độ trễ đầu ra, nhưng một cuộc thảo luận tương tự cũng áp dụng cho độ trễ đầu vào.

Giả sử mạch tương tự không đóng góp đáng kể, thì các yếu tố đóng góp chính ở mức bề mặt vào độ trễ âm thanh là:

  • Đăng kí
  • Tổng số bộ đệm trong đường ống
  • Kích thước của mỗi bộ đệm, trong khung
  • Độ trễ bổ sung sau bộ xử lý ứng dụng, chẳng hạn như từ DSP

Danh sách những người đóng góp ở trên có thể chính xác, nhưng nó cũng có thể gây hiểu nhầm. Lý do là số lượng bộ đệm và kích thước bộ đệm có tác dụng nhiều hơn là nguyên nhân . Điều thường xảy ra là một lược đồ bộ đệm nhất định được triển khai và thử nghiệm, nhưng trong quá trình thử nghiệm, âm thanh bị chạy ngầm hoặc chạy quá mức được nghe thấy dưới dạng "nhấp chuột" hoặc "bật lên". Để bù đắp, nhà thiết kế hệ thống sau đó sẽ tăng kích thước bộ đệm hoặc số lượng bộ đệm. Điều này mang lại kết quả mong muốn là loại bỏ những phần thiếu hoặc phần thừa, nhưng nó cũng có tác dụng phụ không mong muốn là tăng độ trễ. Để biết thêm thông tin về kích thước bộ đệm, hãy xem video Độ trễ âm thanh: kích thước bộ đệm .

Một cách tiếp cận tốt hơn là tìm hiểu nguyên nhân của việc thiếu và vượt quá, sau đó sửa chữa những nguyên nhân đó. Điều này giúp loại bỏ các hiện vật có thể nghe được và có thể cho phép bộ đệm nhỏ hơn hoặc ít hơn và do đó giảm độ trễ.

Theo kinh nghiệm của chúng tôi, những nguyên nhân phổ biến nhất gây ra tình trạng thiếu và vượt mức bao gồm:

  • Linux CFS (Bộ lập lịch hoàn toàn công bằng)
  • chuỗi ưu tiên cao với lập lịch SCHED_FIFO
  • đảo ngược ưu tiên
  • độ trễ lập lịch dài
  • trình xử lý ngắt hoạt động lâu dài
  • thời gian vô hiệu hóa gián đoạn dài
  • quản lý năng lượng
  • hạt nhân bảo mật

Lập lịch CFS và SCHED_FIFO của Linux

CFS của Linux được thiết kế để công bằng với các khối lượng công việc cạnh tranh chia sẻ một tài nguyên CPU chung. Sự công bằng này được thể hiện bằng một tham số đẹp trên mỗi luồng. Giá trị đẹp nằm trong khoảng từ -19 (ít đẹp nhất hoặc được phân bổ thời gian CPU nhiều nhất) đến 20 (đẹp nhất hoặc ít thời gian CPU nhất được phân bổ). Nói chung, tất cả các luồng có giá trị đẹp nhất định sẽ nhận được thời gian CPU xấp xỉ bằng nhau và các luồng có giá trị số đẹp thấp hơn sẽ nhận được nhiều thời gian CPU hơn. Tuy nhiên, CFS chỉ "công bằng" trong thời gian quan sát tương đối dài. Qua các cửa sổ quan sát ngắn hạn, CFS có thể phân bổ tài nguyên CPU theo những cách không mong muốn. Ví dụ, nó có thể đưa CPU rời khỏi một luồng có độ đẹp thấp về số thành một luồng có độ đẹp cao về mặt số. Trong trường hợp âm thanh, điều này có thể dẫn đến chạy thiếu hoặc chạy quá mức.

Giải pháp rõ ràng là tránh CFS cho các luồng âm thanh hiệu suất cao. Bắt đầu từ Android 4.1, các chuỗi như vậy hiện sử dụng chính sách lập lịch SCHED_FIFO thay vì chính sách lập lịch SCHED_NORMAL (còn gọi là SCHED_OTHER ) do CFS triển khai.

SCHED_FIFO mức độ ưu tiên

Mặc dù các luồng âm thanh hiệu suất cao hiện sử dụng SCHED_FIFO , chúng vẫn dễ bị ảnh hưởng bởi các luồng SCHED_FIFO khác có mức độ ưu tiên cao hơn. Đây thường là các luồng nhân viên hạt nhân, nhưng cũng có thể có một vài luồng người dùng không phải âm thanh với chính sách SCHED_FIFO . Các mức độ ưu tiên SCHED_FIFO có sẵn nằm trong khoảng từ 1 đến 99. Các luồng âm thanh chạy ở mức ưu tiên 2 hoặc 3. Điều này khiến mức độ ưu tiên 1 có sẵn cho các luồng có mức độ ưu tiên thấp hơn và mức độ ưu tiên 4 đến 99 cho các luồng có mức độ ưu tiên cao hơn. Chúng tôi khuyên bạn nên sử dụng mức độ ưu tiên 1 bất cứ khi nào có thể và dành mức độ ưu tiên từ 4 đến 99 cho những chuỗi được đảm bảo hoàn thành trong một khoảng thời gian nhất định, thực thi với khoảng thời gian ngắn hơn khoảng thời gian của chuỗi âm thanh và được biết là không ảnh hưởng đến việc lập lịch của chủ đề âm thanh.

Lập kế hoạch đơn điệu tỷ lệ

Để biết thêm thông tin về lý thuyết phân bổ các mức độ ưu tiên cố định, hãy xem bài viết Lập lịch biểu đơn giá (RMS) trên Wikipedia. Một điểm chính là các ưu tiên cố định nên được phân bổ nghiêm ngặt dựa trên thời gian, với các ưu tiên cao hơn được chỉ định cho các chủ đề có thời gian ngắn hơn, không dựa trên "tầm quan trọng" được nhận thức. Các chủ đề không tuần hoàn có thể được mô hình hóa thành các chủ đề tuần hoàn, sử dụng tần suất thực thi tối đa và tính toán tối đa cho mỗi lần thực hiện. Nếu một chuỗi không tuần hoàn không thể được mô hình hóa như một chuỗi tuần hoàn (ví dụ: nó có thể thực thi với tần số không giới hạn hoặc tính toán không giới hạn cho mỗi lần thực hiện), thì nó không nên được chỉ định một mức độ ưu tiên cố định vì điều đó sẽ không tương thích với việc lập lịch cho các chuỗi định kỳ thực sự .

Đảo ngược ưu tiên

Đảo ngược mức độ ưu tiên là một chế độ lỗi cổ điển của hệ thống thời gian thực, trong đó tác vụ có mức độ ưu tiên cao hơn bị chặn trong thời gian không giới hạn để chờ tác vụ có mức độ ưu tiên thấp hơn giải phóng tài nguyên chẳng hạn như (trạng thái được chia sẻ được bảo vệ bởi) mutex . Xem bài viết " Tránh đảo ngược ưu tiên " để biết các kỹ thuật giảm thiểu nó.

Lập lịch trình độ trễ

Độ trễ lập lịch là thời gian từ khi một luồng sẵn sàng chạy đến khi quá trình chuyển ngữ cảnh kết quả hoàn thành để luồng thực sự chạy trên CPU. Độ trễ càng ngắn càng tốt và bất kỳ thứ gì trên hai mili giây đều gây ra sự cố cho âm thanh. Độ trễ lập lịch dài rất có thể xảy ra trong quá trình chuyển đổi chế độ, chẳng hạn như khởi động hoặc tắt CPU, chuyển đổi giữa hạt nhân bảo mật và hạt nhân bình thường, chuyển từ chế độ năng lượng đầy đủ sang chế độ năng lượng thấp hoặc điều chỉnh tần số và điện áp xung nhịp CPU .

Ngắt

Trong nhiều thiết kế, CPU 0 phục vụ tất cả các ngắt bên ngoài. Vì vậy, một trình xử lý ngắt hoạt động lâu dài có thể trì hoãn các ngắt khác, cụ thể là các ngắt hoàn thành truy cập bộ nhớ trực tiếp âm thanh (DMA). Thiết kế trình xử lý ngắt để hoàn thành nhanh chóng và trì hoãn công việc dài dòng cho một luồng (tốt nhất là luồng CFS hoặc luồng SCHED_FIFO có mức độ ưu tiên 1).

Tương tự, việc vô hiệu hóa các ngắt trên CPU 0 trong một thời gian dài sẽ dẫn đến việc trì hoãn việc bảo dưỡng các ngắt âm thanh. Thời gian vô hiệu hóa ngắt dài thường xảy ra trong khi chờ khóa quay hạt nhân. Xem lại các khóa quay này để đảm bảo chúng được kết dính.

Quản lý năng lượng, hiệu suất và nhiệt

Quản lý điện năng là một thuật ngữ rộng bao gồm các nỗ lực giám sát và giảm tiêu thụ điện năng trong khi tối ưu hóa hiệu suất. Quản lý nhiệtlàm mát máy tính tương tự nhau nhưng tìm cách đo và kiểm soát nhiệt để tránh thiệt hại do nhiệt thừa. Trong nhân Linux, trình điều khiển CPU chịu trách nhiệm về chính sách cấp thấp, trong khi chế độ người dùng cấu hình chính sách cấp cao. Các kỹ thuật được sử dụng bao gồm:

  • mở rộng điện áp động
  • chia tỷ lệ tần số động
  • cho phép lõi động
  • chuyển đổi cụm
  • quyền lực
  • hotplug (hotswap)
  • các chế độ ngủ khác nhau (tạm dừng, dừng, không hoạt động, tạm ngừng, v.v.)
  • quá trình di chuyển
  • mối quan hệ của bộ xử lý

Một số hoạt động quản lý có thể dẫn đến "công việc ngừng hoạt động" hoặc thời gian không có công việc hữu ích nào được thực hiện bởi bộ xử lý ứng dụng. Những lần ngừng việc này có thể ảnh hưởng đến âm thanh, do đó, việc quản lý như vậy phải được thiết kế để ngăn chặn trường hợp xấu nhất có thể chấp nhận được khi âm thanh đang hoạt động. Tất nhiên, khi sự chạy trốn nhiệt sắp xảy ra, việc tránh thiệt hại vĩnh viễn còn quan trọng hơn cả âm thanh!

Hạt nhân bảo mật

Nhân bảo mật cho quản lý quyền Kỹ thuật số (DRM) có thể chạy trên (các) nhân của bộ xử lý ứng dụng giống như nhân được sử dụng cho nhân hệ điều hành chính và mã ứng dụng. Bất kỳ lúc nào trong đó một hoạt động của nhân bảo mật đang hoạt động trên một lõi thực sự là một sự dừng lại của công việc bình thường thường chạy trên lõi đó. Đặc biệt, điều này có thể bao gồm công việc âm thanh. Theo bản chất của nó, hành vi bên trong của một nhân bảo mật là không thể giám sát được từ các lớp cấp cao hơn, và do đó, bất kỳ sự bất thường nào về hiệu suất gây ra bởi một nhân bảo mật là đặc biệt nguy hiểm. Ví dụ, các hoạt động của nhân bảo mật thường không xuất hiện trong dấu vết chuyển đổi ngữ cảnh. Chúng tôi gọi đây là "thời gian đen tối" - thời gian trôi qua mà không thể quan sát được. Hạt nhân bảo mật nên được thiết kế cho trường hợp ngừng hoạt động xấu nhất có thể chấp nhận được khi âm thanh đang hoạt động.