2010-11-15 35 views
7

Tôi hiện đang làm việc trên một dự án cá nhân: tạo thư viện để tổng hợp âm thanh trong thời gian thực trong Flash. Tóm lại: các công cụ để kết nối các bộ tạo sóng, bộ lọc, bộ trộn, vv với nhau và cung cấp card âm thanh với dữ liệu thô (thời gian thực). Một cái gì đó như max/msp hoặc Reaktor.Có ai có lời khuyên về lập trình tổng hợp âm thanh thời gian thực không?

Tôi đã có một số nội dung hoạt động, nhưng tôi tự hỏi liệu thiết lập cơ bản mà tôi đã viết có đúng không. Tôi không muốn gặp phải vấn đề sau đó khiến tôi thay đổi cốt lõi của ứng dụng của mình (mặc dù điều đó luôn có thể xảy ra).

Về cơ bản, những gì tôi làm bây giờ là bắt đầu ở cuối chuỗi, tại nơi âm thanh (thô) đi 'ra' (với soundcard). Để làm điều đó, tôi cần phải viết khối byte (ByteArrays) cho một đối tượng, và để có được đoạn đó tôi hỏi bất kỳ mô-đun nào được kết nối với mô-đun 'Sound Out' của tôi để cho tôi đoạn của mình. Mô-đun đó thực hiện cùng một yêu cầu cho mô-đun được kết nối với đầu vào của mình và điều đó tiếp tục xảy ra cho đến khi bắt đầu chuỗi.

Đây có phải là phương pháp phù hợp không? Tôi có thể tưởng tượng chạy vào các vấn đề nếu có một feedbackloop, hoặc nếu có một module không có đầu ra: nếu tôi kết nối một spectrumanalyzer ở đâu đó, đó sẽ là một kết thúc chết trong chuỗi (một module không có đầu ra, chỉ là một đầu vào). Trong thiết lập hiện tại của tôi, một mô-đun như vậy sẽ không hoạt động vì tôi chỉ bắt đầu tính toán từ mô-đun âm thanh-đầu ra.

Có ai có kinh nghiệm lập trình một cái gì đó như thế này không? Tôi sẽ rất quan tâm đến một số suy nghĩ về cách tiếp cận đúng đắn. (Để rõ ràng: Tôi không tìm kiếm các triển khai Flash cụ thể và đó là lý do tại sao tôi không gắn thẻ câu hỏi này theo flash hoặc actioncript)

Trả lời

1

Tôi đã làm điều tương tự trong khi quay lại và tôi đã sử dụng cách tiếp cận tương tự như bạn làm - bắt đầu ở đường ảo, và theo dõi tín hiệu trở lại đầu trang. Tôi đã làm điều này cho mỗi mẫu mặc dù, không phải mỗi bộ đệm; nếu tôi đã viết cùng một ứng dụng ngày hôm nay, tôi có thể chọn mỗi bộ đệm thay vì, bởi vì tôi nghi ngờ nó sẽ hoạt động tốt hơn.

Máy đo phổ được thiết kế làm mô-đun chèn, nghĩa là nó chỉ hoạt động nếu cả đầu vào và đầu ra của nó được kết nối và nó sẽ truyền đầu vào của nó đến đầu ra không thay đổi.

Để xử lý phản hồi, tôi có một mô-đun trợ giúp đặc biệt giới thiệu độ trễ 1 mẫu và chỉ tìm nạp dữ liệu nhập một lần cho mỗi chu kỳ. Ngoài ra, tôi nghĩ rằng làm tất cả các xử lý nội bộ của bạn với phao, và do đó mảng nổi như bộ đệm, sẽ dễ dàng hơn nhiều so với mảng byte, và nó sẽ giúp bạn tiết kiệm thêm công sức chuyển đổi giữa các số nguyên và nổi tất cả các thời gian.

0

Trong các phiên bản sau này, bạn có thể có các tốc độ gói khác nhau ở các phần khác nhau trong mạng của bạn.

Một ví dụ là nếu bạn mở rộng nó để chuyển dữ liệu đến hoặc từ đĩa. Một ví dụ khác là sẽ là các biến điều khiển tốc độ dữ liệu thấp, chẳng hạn như một điều khiển trễ trễ có thể, sau này, trở thành một phần của mạng của bạn. Có thể bạn không muốn xử lý các biến điều khiển với cùng tần suất mà bạn xử lý các gói âm thanh, nhưng chúng vẫn là 'thời gian thực' và một phần của mạng chức năng. Họ có thể ví dụ cần làm mịn để tránh chuyển tiếp đột ngột.

Miễn là bạn đang gọi tất cả các chức năng của bạn ở cùng một mức, và tất cả các chức năng chủ yếu là lấy thời gian liên tục, cách tiếp cận kéo-dữ liệu của bạn sẽ hoạt động tốt. Sẽ có ít để lựa chọn giữa việc kéo dữ liệu và đẩy. Kéo có phần tự nhiên hơn để phát âm thanh, việc đẩy có phần tự nhiên hơn để ghi, nhưng có thể hoạt động và kết thúc việc thực hiện các cuộc gọi tương tự đến các chức năng xử lý âm thanh cơ bản.

  • Đối với phổ bạn đã có vấn đề nhiều bồn cho dữ liệu, nhưng nó không phải là một vấn đề. Giới thiệu liên kết giả với nó từ bồn rửa thực sự. Liên kết giả có thể khiến yêu cầu dữ liệu không phải là được vinh danh. Miễn là liên kết giả biết nó là giả và không quan tâm đến việc thiếu dữ liệu, mọi thứ sẽ là OK. Đây là một kỹ thuật tiêu chuẩn để giảm nhiều bồn rửa hoặc nguồn vào một cái duy nhất.

  • Với loại mạng này, bạn không muốn thực hiện cùng một phép tính hai lần trong một lần cập nhật hoàn chỉnh. Ví dụ: nếu bạn kết hợp phiên bản tín hiệu vượt qua và thông lượng thấp của tín hiệu bạn không muốn đánh giá tín hiệu gốc hai lần. Bạn phải làm một cái gì đó như ghi lại một giá trị đánh dấu hẹn giờ với mỗi bộ đệm, và dừng tuyên truyền kéo khi bạn nhìn thấy giá trị đánh dấu hiện tại đã có mặt. Cơ chế tương tự này cũng sẽ bảo vệ bạn chống lại các vòng phản hồi trong đánh giá.

Vì vậy, hai vấn đề quan tâm đến bạn được dễ dàng giải quyết trong khuôn khổ hiện tại của bạn.

Tỷ lệ khớp nơi có các mức gói khác nhau trong các phần khác nhau của mạng là nơi các vấn đề với phương pháp hiện tại sẽ bắt đầu. Nếu bạn đang viết âm thanh vào đĩa thì hiệu quả bạn sẽ muốn viết khối lớn không thường xuyên. Bạn không muốn chặn việc phục vụ các gói xử lý đầu vào và đầu ra âm thanh nhỏ thường xuyên hơn trong quá trình ghi. Một tốc độ duy nhất kéo hoặc đẩy chiến lược của riêng mình sẽ không đủ.

Chỉ chấp nhận rằng tại một thời điểm nào đó bạn có thể cần một cách cập nhật tinh vi hơn so với mạng tỷ lệ đơn. Khi điều đó xảy ra, bạn sẽ cần các luồng cho các tốc độ khác nhau đang chạy hoặc bạn sẽ viết trình lập lịch đơn giản của riêng mình, có thể đơn giản như gọi các hàm được đánh giá ít thường xuyên một lần trong n, để làm cho tỷ lệ phù hợp. Bạn không cần lập kế hoạch trước cho việc này. Chức năng âm thanh của bạn gần như chắc chắn đã được giao trách nhiệm đảm bảo bộ đệm đầu vào của bạn đã sẵn sàng cho các chức năng khác, và nó sẽ chỉ là những chức năng khác cần thay đổi, chứ không phải chính các chức năng âm thanh.

Điều tôi khuyên là ở giai đoạn này là cẩn thận để tập trung bộ đệm âm thanh phân bổ, nhận thấy rằng bộ đệm giống như hàng rào. Chúng không thuộc về chức năng âm thanh , chúng nằm giữa các chức năng âm thanh. Tập trung việc cấp phát bộ đệm sẽ giúp dễ dàng sửa đổi lại chiến lược cập nhật cho các mức giá khác nhau ở các phần khác nhau của mạng.

Các vấn đề liên quan