Jack vs Pulseaudio - làm thế nào nhanh hơn?


27

Tôi thấy một loạt các tuyên bố rằng Jack nhanh hơn Pulse và có độ trễ ít hơn. Làm thế nào là như vậy? Tại sao Pulse tự gọi mình là nhẹ, và những người Jack gọi nó là béo? Bất cứ ai cũng có thể phá vỡ nội bộ của hai daemon này cho một giáo dân?


2
Theo tôi hiểu, chúng được thiết kế cho các mục đích khác nhau có thể giải thích vấn đề so sánh chúng.
NN

Câu trả lời:


30

Jack yêu cầu bạn-- người dùng có kiến ​​thức-- để định cấu hình máy chủ để xác định độ trễ xử lý thấp nhất có thể cho máy của bạn. (Độ trễ xử lý là thời gian máy chủ di chuyển dữ liệu đến / từ ứng dụng khách và sau đó gửi / nhận "khối" mẫu âm thanh tiếp theo bên ngoài hệ thống.) Jack sẽ cung cấp các khối dữ liệu âm thanh đó đúng thời gian hoặc nó sẽ thất bại và cung cấp cho bạn một bộ đệm ẩn (đôi khi được gọi là "bỏ học", hoặc bậtnhấp). Nếu Jack liên tục bị vượt quá thì công việc của bạn là khởi động lại máy chủ với các cài đặt khác nhau hoặc thay đổi thứ gì đó trong (các) ứng dụng khách để chúng hoạt động hiệu quả hơn để bạn có thể đáp ứng thời hạn âm thanh của mình. Vì cài đặt máy chủ của bạn áp dụng thống nhất cho tất cả các máy khách, Jack khá hữu ích để định tuyến âm thanh giữa nhiều ứng dụng âm thanh và nhận được kết quả có thể dự đoán được . (Tức là, giống như cắm "giắc cắm" vào các thành phần âm thanh khác nhau.)

Xung được thiết kế để giảm thiểu số lần âm thanh bị mất do máy chủ không đáp ứng thời hạn gửi / nhận âm thanh bên ngoài hệ thống. Rõ ràng là cố gắng thực hiện điều này bằng cách chọn một bộ đệm lớn cho các ứng dụng khách không yêu cầu độ trễ xử lý thấp , sau đó "tiêm" các mẫu vào bộ đệm đó cho các ứng dụng khách có thời hạn sớm hơn. Nếu nó cố gắng tiêm mẫu sớm đến mức nó bị trễ hạn và gây ra lỗi, Pulse sẽ tự động tăng thời gian ngắn nhất mà nó sẽ cho phép khách hàng gửi bản cập nhật âm thanh đến máy chủ. Các tài liệu xung tuyên bố rõ ràng rằng độ trễ cực thấp-- giả sử, độ trễ xử lý dưới 10ms- không phải là một mục tiêu thiết kế. Vì bản thân Linux (và có lẽ phần cứng của bạn) không được thiết kế để lên lịch cho âm thanh theo thời gian thực, tôi có thể tin chúng.

Về mặt cấu hình người dùng, Pulse là "ánh sáng". (Mọi người có thể nói Pulse có độ trễ cấu hình thấp , điều không may là nhiều ứng dụng Linux Audio dường như không quan tâm.) Xét về độ phức tạp cơ bản của nó so với Jack, Pulse là "béo".

Để có câu trả lời dứt khoát về câu trả lời nào nhanh hơn, bạn sẽ chỉ cần có một thiết bị loopback và đo độ trễ chuyến đi khứ hồi trên hệ thống của chính bạn để biết sự thật. Độ trễ chuyến đi khứ hồi là thời gian hệ thống của bạn xử lý âm thanh và nhận lại những gì nó đã xử lý trở lại hệ thống. Có hướng dẫn trực tuyến giải thích cách thực hiện điều này trong Linux. Điều đó sẽ cho bạn ý tưởng về những gì bạn thực sự theo đuổi, đó là độ trễ nhận biết - thời gian cần thiết từ khi bạn kích hoạt một sự kiện (ví dụ: xâu chuỗi dây đàn guitar) cho đến khi bạn nghe thấy âm thanh đầu tiên kết quả đó (ví dụ, nghe hợp âm guitar).

Cuối cùng, hãy nhớ rằng cả Pulse và Jack đều đứng đầu ALSA trên hầu hết các bản phân phối GNU / Linux. Tôi biết bạn chỉ hỏi về Jack so với Pulse. Nhưng nếu bạn đang sử dụng một ứng dụng âm thanh duy nhất có thể kết nối trực tiếp với ALSA, thì không có cách nào có thể hiểu được rằng việc thêm Pulse hoặc Jack sẽ giúp bạn có độ trễ nhận thức thấp hơn so với ALSA. Theo nghĩa đó, cả Pulse và Jack đều "béo".

tldr; Chỉ riêng ALSA là nhanh nhất, Jack rất hữu ích trong việc kết nối nhiều ứng dụng âm thanh và Pulse có thể dễ sử dụng nhất khi bạn không quan tâm đến độ trễ cực thấp. Bỏ qua mọi tài liệu hoặc thảo luận sử dụng độ trễ hạn mà không giải thích loại độ trễ có nghĩa là gì. (Thật không may, cả tài liệu chính thức của Jack và các mục blog của Lennart về Pulse đều thuộc danh mục này.)

Lưu ý : Có thể có các trường hợp cạnh mà bạn muốn sử dụng một ứng dụng âm thanh duy nhất và nó có giao diện ALSA nhàu nát và giao diện Jack phong nha. Trong trường hợp đó, sử dụng Jack có thể giúp bạn có độ trễ thấp hơn. Nhưng nếu chúng ta đang nói về các ứng dụng được thiết kế để giảm thiểu độ trễ thì những trường hợp đó sẽ rất hiếm. Nhưng hãy kết nối một thiết bị loopback và kiểm tra giả thuyết của tôi!


9

Họ thực sự giống nhau trong việc là máy chủ âm thanh . JACK được thiết kế để đáp ứng thời gian thực / độ trễ thấp, được yêu cầu bởi các giải pháp âm thanh cấp chuyên nghiệp. PulseAudio được nhắm mục tiêu nhiều hơn trên máy tính để bàn nói chung (nơi áp dụng các nhu cầu ít nghiêm ngặt hơn). PA dường như nặng hơn JACK - phức tạp hơn gây ra nhiều chi phí hơn. Trên Linux cả hai đều sử dụng ALSA cho đầu ra thực sự cuối cùng. Với PA, dữ liệu thường được định tuyến từ ALSA (đầu ra ứng dụng) sang PA (xử lý) đến ALSA (đầu ra), tất nhiên là chậm hơn so với tuyến JACK-ALSA. Mặt khác, nó trong suốt đối với các ứng dụng không thể sử dụng nguyên bản, vì nó cung cấp cho chúng một card âm thanh ảo với giao diện ALSA.

Trong mọi trường hợp, trừ khi bạn có ý định sản xuất nhạc hoặc không thể sống mà không có điều khiển âm lượng ứng dụng (hoặc chuyển tiếp âm thanh sang máy khác qua mạng), ALSA đơn giản sẽ hoạt động tốt, với ít chi phí hơn. Một số trình điều khiển có thể thực hiện trộn phần cứng và thậm chí nếu không, ALSA có thể trộn thông qua một plugin (được cho là không linh hoạt như JACK, nhưng sử dụng "bình thường" sẽ ổn).


Là liên kết đến hình ảnh PA bị đánh giá sai?
NN

@NN làm việc cho tôi, nhưng tôi đã thay đổi ngay bây giờ, vì vậy hy vọng nó sẽ tốt hơn.
peterph 22/03/13

@Sukminder lỗi dường như khá ngẫu nhiên.
peterph 22/03/13

1
Tôi không nghĩ câu trả lời này sẽ cắt nó: đầu tiên bạn không nói làm thế nào Jack nhanh hơn và thứ hai bạn kết luận câu trả lời bằng một ví dụ liên quan đến trình điều khiển giả, thay vì một Pulse Pulse trực tiếp. Câu hỏi khá rõ ràng, nhưng để trực tiếp hơn - làm thế nào JACK nhanh hơn nhanh nhất, so với Pulse ở tốc độ nhanh nhất?
Evan Carroll

Tôi cảm thấy mệt mỏi khi nghe nhóm Jack nói rằng nó nhanh hơn bởi vì nó không có trọng lượng nặng mà không giải thích lý do tại sao nặng - và, những gì ở hạng nặng - làm cho Pulse chậm hơn. Câu trả lời này giống như một sự tái khẳng định của Cartesian về tiền đề trong câu hỏi.
Evan Carroll

4

Jack dành cho các ứng dụng cần độ trễ thấp, ví dụ: thu âm / tạo âm thanh cho nhạc sĩ, nhà sản xuất video, v.v.

  • không lấy mẫu lại!
  • buộc các nguồn trộn phần mềm
  • những thứ định tuyến thích hợp (âm thanh, thời gian đồng bộ, v.v.) giữa các ứng dụng, thiết bị, plugin ladspa / lv2 / vst, v.v.
  • có thể được sử dụng với pulseaudio (cầu nối)

Pulse dành cho các ứng dụng máy tính để bàn thông thường (không mong đợi độ trễ thấp)

  • cung cấp khả năng tương thích với aRtsesd
  • có thể được sử dụng như alsaossđầu ra
  • buộc thay đổi phần mềm
  • buộc các nguồn trộn phần mềm
  • phần mềm upmix, downmix, v.v.
  • cung cấp api đẹp cho các plugin (ví dụ: pulseeffects )
  • định tuyến đơn giản (để cắm đầu ra vào thiết bị hoặc ứng dụng khác)
  • điều khiển âm lượng trên mỗi ứng dụng

Lớp không gian người dùng Alsa (không phải trình điều khiển) làm tối thiểu (độ trễ giữa [*])

  • [*] lấy mẫu lại phần cứng, trộn nguồn, trộn âm, v.v. (bạn cần có card âm thanh đầy đủ để sử dụng, nếu không phần mềm sẽ được sử dụng)
  • plugin ladspa mà bạn có thể đặt ở định dạng cấu hình xấu
  • kiểm soát mức âm lượng đơn giản / toàn cầu

Trong hầu hết các trường hợp, Pulse là lựa chọn tốt nhất cho người dùng máy tính để bàn thông thường. Jack là sự lựa chọn tốt nhất cho các nhạc sĩ, v.v.


Tôi đã bỏ một upvote, nhưng tôi không chắc đó là câu trả lời cho câu hỏi nhiều như một so sánh tốt. Tại sao PulseAudio chậm hơn nếu nó không thực hiện lấy mẫu lại?
Evan Carroll

> Tại sao PulseAudio chậm hơn nếu không lấy mẫu lại?
3ED

Không phải? Họ làm công cụ trong phần mềm, ví dụ: buộc lấy mẫu lại (bạn có thể chọn giữa 2). Jack một phần bỏ qua alsa. Jack là một cái gì đó tương tự như asio. Xung tương tự như âm thanh cửa sổ tiêu chuẩn từ vista trở lên. Không giống nhau nhưng khái niệm tương tự. Pulse rất tuyệt vời đối với các card âm thanh giá rẻ / tích hợp / không được hỗ trợ đúng cách mà không thể thực hiện mọi thứ trong phần cứng.
3ED

2

Đó thực sự không phải là một câu hỏi "vs". Lúc đầu, chúng ta có thể thấy cả hai đều là "Máy chủ âm thanh". Vì vậy, có lẽ, kết luận người ta chỉ cần chọn giữa chúng. Đó không phải là trường hợp. So sánh, ví dụ, một máy quay video và máy ảnh FLIR, cả hai đều là máy ảnh. Nhưng, người ta không chỉ "chọn" giữa họ. Chúng phục vụ các vai trò rất khác nhau, những vai trò đó có thể là sự tự mãn, nhưng chúng không có tính cạnh tranh. Một người cần jack, hoặc một người cần xung, hoặc một người có thể cần cả hai. Sự lựa chọn được điều khiển bởi miền vấn đề, không phải tính năng như độ trễ cụ thể.

Đối với "FAT" so với không, thuật ngữ này được sử dụng theo quá nhiều cách để thực sự có ý nghĩa. Nhưng, nói chung, thuật ngữ FAT được sử dụng khi ứng dụng "làm tất cả cho bạn", ít nhiều. "Nhẹ" có xu hướng về phía bạn để tải fucntionallity bạn muốn, có thể chọn từ một loạt các tùy chọn, và loại bỏ phần còn lại. Pulse là một chương trình "big blob" mà bạn đưa ra một vài thông số và, khá nhiều, nó sẽ hoạt động. Cần nó, hoặc không, một lượng lớn chức năng được tải khi bạn bắt đầu xung. Jack là một chương trình nhỏ bé và vô dụng, chính nó là chương trình mà bạn dán vào bất kỳ số lượng plugin, chương trình, v.v. để xây dựng những gì bạn muốn. Các lập trình viên có xu hướng nhìn thế giới từ phía tài nguyên máy.

Vì vậy, xung là một máy chủ có độ trễ thay đổi và jack là độ trễ cố định. Đó là những lĩnh vực vấn đề cụ thể của họ. Nếu bạn chỉ xem TV hoặc nghe nhạc qua mạng, bạn chắc chắn muốn có mạch. Nếu bạn đang cố gắng phát nhạc điện tử trực tiếp, bạn chắc chắn cần jack. Nếu bạn đang xem TV và thực hiện một số xử lý nặng trên (các) luồng âm thanh, chắc chắn bạn sẽ cần cả hai.


1
Hơi chủ quan: Tôi nghĩ rằng máy chủ âm thanh nên tuân theo thiết kế JACK, vì không thể loại bỏ bất kỳ độ trễ nào được thêm bởi máy chủ. Sau đó, nhà phát triển ứng dụng sẽ sử dụng bộ đệm lớn hơn cho I / O của đĩa hoặc mạng, chuyển đổi tốc độ mẫu, v.v ... Độ trễ trên mốc 10 ms là cao.
dùng877329
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.