âm thanh nền tảng API

Question

Tôi đang xem xét phát triển một ứng dụng yêu cầu phát trực tiếp âm thanh. Tôi muốn sử dụng một số thư viện mã nguồn mở đa nền tảng (windows/linux/BSD) được viết bằng C hoặc C++ mặc dù viết nó bằng cách sử dụng các API âm thanh của hệ điều hành tương ứng vẫn là một tùy chọn.

Tôi đã đọc một chút về các thư viện âm thanh khác nhau, bao gồm SFML, SDL và PortAudio. Phải thừa nhận rằng, tôi chưa nghiên cứu đầy đủ về âm thanh trong FreeBSD và Linux (cách tương tự là nó giữa 2?)

Các yêu cầu chính sẽ là

1. nhận được âm thanh từ microphone chọn/micro để gửi qua mạng,
2. gửi dữ liệu đến lựa chọn thiết bị đầu ra,
3. xử lý âm thanh (lọc, dọn dẹp tiếng ồn, ghép kênh v.v.) nhưng điều này có thể được thực hiện khi tôi có dữ liệu âm thanh, chính thư viện KHÔNG cần để có thể làm được điều này.
4. có độ trễ khá thấp

mối quan tâm chính của tôi là các API này đề cập dường như là mục tiêu chủ yếu cho trò chơi (nơi âm thanh thường được nạp từ đĩa và không có nhiều, nếu có, ghi âm liên quan đến hơn được phát trực tuyến qua mạng có tầm quan trọng ngang nhau giữa quá trình ghi và phát lại

Có ai có bất kỳ gợi ý/cảnh báo/đề xuất nào về các API âm thanh này hoặc về lợi thế/bất lợi của việc thực hiện và thực hiện điều này trong các hệ điều hành tương ứng hay không API?

LƯU Ý: trong khi điều này: "Câu hỏi yêu cầu chúng tôi đề xuất hoặc tìm sách, công cụ, thư viện phần mềm, hướng dẫn hoặc tài nguyên ngoài trang web khác là chủ đề cho Stack Overflow" KHÔNG đặt câu hỏi ngoài chủ đề, khi người ta cũng xem xét " vì họ có xu hướng thu hút các câu trả lời và spam có ý kiến ​​"thì tôi không nghĩ rằng câu hỏi này nên được đóng lại. Một người nào đó tìm kiếm một thư viện như mô tả sẽ khó ép để tìm thấy bất cứ điều gì và câu trả lời cho câu hỏi này thực tế tóm tắt tất cả các tùy chọn có sẵn. Điều này là như vậy trong "thường bao gồm ... các công cụ phần mềm thường được sử dụng bởi các lập trình viên;" loại câu trả lời được chấp nhận.

Answer 1

PortAudio là một lựa chọn tuyệt vời cho ứng dụng bạn mô tả - nó chạy trên tất cả các nền tảng đó, được viết bằng C, cung cấp độ trễ thấp và có cả tùy chọn I/O gọi lại và chặn. Nó chắc chắn đáp ứng yêu cầu của bạn, và là không phải đặc biệt nhắm vào trò chơi. Trong thực tế, tôi có thể nói rằng có nhiều apis tốt hơn cho game, trong khi PortAudio thì tốt hơn cho các ứng dụng âm thanh đa năng như các ứng dụng như voip, audio player, pro-audio applications, audio recorder, radio phần mềm, v.v.

Một tùy chọn khác mà bạn có thể xem xét là RTAudio mà tôi không quen thuộc. Sự hiểu biết của tôi là nó đơn giản hơn một chút (không chặn I/O AFAIK), và hỗ trợ nhiều nền tảng hơn, bao gồm cả các hệ điều hành di động, mặc dù các nhân viên PortAudio đang làm việc trên đó.

Câu hỏi của bạn về FreeBSD so với Linux: Linux sử dụng ALSA, trong khi các unix khác sử dụng OSS. Cả OSS và ALSA đều cung cấp các lớp tương thích, vì vậy ALSA có khả năng tương thích PMNM và ngược lại, nhưng trong kinh nghiệm của tôi có các lỗi trong cả hai lớp tương thích. Có lẽ mọi thứ đã tốt hơn kể từ lần cuối cùng tôi sử dụng nó.

Một số máy tính để bàn chạy Linux chạy PulseAudio phía trên ALSA. Tôi không chắc chắn nếu điều này là đúng sự thật của FreeBSD. Vì một số lý do, ALSA được cấu hình trong chế độ độc quyền theo mặc định trên hầu hết các hệ thống. Mặc dù điều này dễ sửa trong lý thuyết nhưng các tệp cấu hình là lạ và hầu hết người dùng chưa thực hiện và sẽ không bao giờ, nghĩa là khi PulseAudio tiếp quản, bạn không thể truy cập trực tiếp vào các thiết bị ALSA, vì vậy bạn có thể muốn một trình điều khiển PulseAudio là tốt, trừ khi bạn muốn làm cho người dùng của bạn thay đổi cấu hình của họ (mà bạn có thể nếu ứng dụng của bạn yêu cầu độ trễ thực sự thấp).

Tôi khá chắc chắn PortAudio hỗ trợ PulseAudio, mặc dù những gì nó có thể hoặc không thể nói trên trang web. Tôi sẽ hỏi về danh sách gửi thư và cập nhật tại đây.

CẬP NHẬT: ai đó trong danh sách gửi thư cho rằng bạn có thể sử dụng trình điều khiển Alsa để truy cập PulseAudio. Đó là (tuyệt vời!) Tin tức cho tôi, nhưng có nó.

Answer 2

Tôi coi SDL và OpenAL là cả hai phổ biến và được hỗ trợ rộng rãi. Trừ khi những điều này không đáp ứng nhu cầu của bạn, tôi khuyên bạn không nên xuống cấp thấp hơn vì bạn sẽ mất nền tảng độc lập.

Lý do họ dường như hướng đến trò chơi đơn giản chỉ vì đó là một trong những trường hợp sử dụng khó khăn hơn. Vì vậy, nếu bạn có thể hỗ trợ trò chơi rất có thể là bạn sẽ hỗ trợ bất cứ điều gì ứng dụng khác sẽ muốn (ngắn của phần mềm phòng thu).

Xem xét mục tiêu độ trễ thấp của bạn. Trò chơi yêu cầu độ trễ rất thấp để đảm bảo hiệu ứng âm thanh được kết hợp tốt với các tác vụ trên màn hình. Tôi đoán đây là một lý do tương tự như bạn muốn điều này (vì vậy âm thanh của bạn phù hợp với luồng video của bạn và không có tạm dừng trong kênh thoại).

BTW, nhận thức của bạn về trò chơi là không chính xác. Rất nhiều trò chơi có các kênh thoại của người dùng để liên lạc nhóm. Ngoài ra, chúng có thể bao gồm các hiệu ứng âm thanh và âm thanh thủ tục.

---

Tôi tìm thấy một cuộc gọi khác SFML bao gồm hỗ trợ ghi âm. Tôi không biết nhiều về nó, nhưng tôi đã thấy nó có thể thay thế SDL.

Answer 3

Tôi thực sự khuyên bạn nên phát triển nó trên nền tảng Qt (Linux/Mac/Windows) trên nền tảng chéo và sử dụng các thư viện Qt riêng của mình.Trong mô-đun QtMultimedia, bạn có thể sử dụng QAudioInput để thu âm thanh thô từ micrô.Bạn có thể lại sử dụng QtMultimedia để xử lý.

Khung Qt được tối ưu hóa rất nhiều cho ứng dụng đa phương tiện và chơi trò chơi, vì vậy bạn sẽ không bị mất hiệu suất.

Answer 4

linphone chứa mediastreamer2 cho mục đích chính xác này

Answer 5

libsoundio là một thư viện C ở mức độ thấp phù hợp với yêu cầu của bạn.

Một lưu ý: nó không hỗ trợ OSS (FreeBSD) hoặc sndio (OpenBSD).