جافا من أجل معالجة الصوت هل هو عملي ؟
https://stackoverflow.com/questions/407624
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
هو جافا بديل مناسب إلى C / C++ الوقت الحقيقي معالجة الصوت?
أنا أفكر في التطبيق مع ~100 (كحد أقصى) مسارات الصوت مع خطوط تأخير (30s @ 48khz), تصفية (512 نقطة الأشجار؟), وغيرها من DSP نوع العمليات التي تحدث في كل مسار في وقت واحد.
عمليات تحويل و يؤديها في النقطة العائمة.
النظام ربما يكون quad core 3GHz مع 4GB من ذاكرة الوصول العشوائي, تشغيل أوبونتو.
لقد رأيت مقالات حول جافا يجري أسرع بكثير مما كانت عليه من قبل ، الاقتراب من C / C++, والآن وبعد الحقيقي امتداد كذلك.هو هذا الواقع ؟ أنها لا تتطلب النواة الصلبة الترميز وضبط لتحقيق %50-%100 الأداء ج بعض المواصفات جي?
أنا حقا تبحث عن شعور ما إذا كان هذا ممكن و رؤساء لأي gotchas.
المحلول
لتطبيق الصوت الذي غالبا ما يكون فقط أجزاء صغيرة جدا من التعليمات البرمجية حيث قضى معظم الوقت.
في جافا، يمكنك دائما استخدام JNI (جافا واجهة الأصلية)، والتحرك كود الثقيلة الحسابي الخاص بك إلى C-وحدة (أو التجميع باستخدام SSE إذا كنت حقا بحاجة إلى قوة). لذلك أنا أقول استخدام جافا والحصول على عمل التعليمات البرمجية. إذا تبين أنك لا تلبي الهدف أدائك استخدام JNI.
و90٪ من رمز من المرجح أن يكون رمز الغراء والاشياء تطبيق على أي حال. ولكن نأخذ في الاعتبار أن تفقد بعض عبر منصة يتميز بهذه الطريقة. وإذا كنت تستطيع العيش مع هذا JNI دائما أترك لكم الباب مفتوحا لأداء التعليمات البرمجية الأصلية.
نصائح أخرى
وجافا على ما يرام للعديد من التطبيقات الصوتية. وخلافا لبعض من غيرها من الملصقات، وأجد جافا الصوت الفرح للعمل مع. مقارنة API والموارد المتاحة لك لالبشعة، mindf موثقة بالكاد * ك وهذا هو CoreAudio وعليك أن تكون مؤمنا. جافا الصوت يعاني من بعض القضايا الكمون، على الرغم من للعديد من التطبيقات هذا لا يهم، وعدم وجود الترميز. وهناك أيضا الكثير من الناس الذين قد ازعجت أبدا أن تأخذ من الوقت لكتابة جيدة محركات تشغيل الصوت (تلميح، أبدا إغلاق SourceDataLine، بدلا إرسال الأصفار إلى ذلك)، وبعد ذلك لوم جافا لمشاكلهم. من وجهة نظر API، جافا الصوت واضح وصريح جدا، من السهل جدا للاستخدام، وهناك الكثير والكثير من التوجيه في أكثر من jsresources حسنى .
بالطبع ، لم لا ؟
الأسئلة الحاسمة (المستقلة اللغة ، وهذا من نظرية الطابور) هي:
- ما هو الحد الأقصى من الإنتاجية تحتاج إلى التعامل مع (لقد المحدد 100 × 48kHz, هو أن مونو أو ستيريو كم بت أي ما يعادل في ذلك التردد؟)
- يمكن Java إجراءات مواكبة هذا المعدل على المتوسط ؟
- ما هو الحد الأقصى المسموح به الكمون?
إذا كان البرنامج يمكن مواكبة الإنتاجية في المتوسط ، وكان لديك ما يكفي من غرفة الكمون, ثم عليك أن تكون قادرا على استخدام قوائم انتظار المدخلات والمخرجات ، أجزاء البرنامج التي تعتبر بالغة الأهمية بالنسبة التوقيت هي القطع التي وضعت البيانات في انتظار الإدخال و اخراجه من قائمة انتظار الإخراج وإرسالها إلى لجنة المساعدة الإنمائية/المتكلم/أيا كان.
تأخير خطوط منخفضة الحسابية تحميل, تحتاج فقط ما يكفي من الذاكرة (+ عرض النطاق الترددي الذاكرة)...في الواقع ربما يجب عليك فقط استخدام قوائم الإدخال/الإخراج ، أيالبدء في وضع البيانات في انتظار الإدخال فورا والبدء في أخذ البيانات من قائمة انتظار الإخراج 30s في وقت لاحق.إذا لم يكن هناك البرنامج بطيئة جدا...).
اولا هي أكثر تكلفة ، وهذا ربما سيكون عنق الزجاجة (& ما كنت ترغب في تحسين) إلا إذا كان لديك بعض قبيحة سيئة العملية في الاعتبار.
وأعتقد الكمون سيكون مشكلتك الرئيسية - من الصعب جدا للحفاظ على الكمون بالفعل في C / C ++ على أنظمة تشغيل الحديثة، وجافا يضيف بالتأكيد لمشكلة (جامع القمامة). التصميم العام ل "الوقت الحقيقي" معالجة الصوت هو أن تكون المواضيع المعالجة الخاصة بك قيد التشغيل في الوقت الحقيقي جدولة (SCHED_FIFO على نواة لينكس، أي ما يعادل على أنظمة تشغيل أخرى)، وينبغي لتلك المواضيع كتلة أبدا. هذا يعني عدم وجود استدعاءات النظام، لا malloc، لا IO بالطبع، الخ ... وحتى الترحيل مشكلة (الحصول على الصفحة من القرص إلى الذاكرة يمكن أن تتخذ بسهولة عدة مللي ثانية)، لذلك يجب تأمين بعض الصفحات للتأكد من أنها لن تكون أبدا تبادلت بها.
وأنت قد تكون قادرة على القيام تلك الأشياء في جاوة، ولكن جافا يجعل الأمر أكثر تعقيدا، وليس أسهل. وأود أن ننظر إلى تصميم مختلط، حيث الأساسية ستكون في C، والباقي (GUI، الخ ...) سيكون في جافا إذا كنت تريد.
وشيء واحد لم أكن أرى في سؤالك ما إذا كنت بحاجة للعب خارج هذه العينات المصنعة أو إذا كنت تفعل شيئا آخر معهم (ترميز لهم في الملف، على سبيل المثال). سأكون أكثر قلقا بشأن حالة محرك الصوت جاوة مما كانت عليه في مدى السرعة التي يمكن للJVM ازمة العينات.
ولقد ضغطت من الصعب جدا على javax.sound.sampled قبل بضع سنوات، وخرج متفائلين للغاية - لا مقارنة مع الأطر تعادل مثل مكتبة الصوت المفتوحة أو أغنية الأساسية ماك / آي فون (كلاهما لقد استعملت في مستوى مماثل من شدة). javax.sound.sampled يتطلب منك دفع العينات الخاصة بك إلى وجود مخزن مؤقت غير شفاف لمدة غير معروفة، مما يجعل تزامن شبه مستحيل. الأساليب أيضا توثيقه سيئة (من الصعب جدا العثور على أمثلة من تدفق طول غير محدد الصوت عبر خط بدلا من الأمثلة تافهة من كليب في الذاكرة)، وغير منفذة (DataLine.getLevel () ... الذي التنفيذ غير يسن ' تي حتى موثقة)، وذلك قبالة إلى أعلى، وأعتقد أن وضعت الشمس من قبل المهندس سنوات JavaSound الماضية.
إذا أنا <القوي> قد لاستخدام محرك جافا للصوت خلط والإخراج، وكنت على الارجح محاولة استخدام الارتباطات خوال إلى مكتبة الصوت المفتوحة كخيار أول، منذ كنت أعرف ما لا يقل عن المحرك وأيد حاليا وقادرة على منخفضة جدا الكمون. على الرغم من أنني أشك في المدى الطويل أن نيلس هو الصحيح، وسوف ينتهي باستخدام JNI لاستدعاء API الصوت الأصلي.
نعم، جافا تعتبر كبيرة بالنسبة لتطبيقات الصوت. يمكنك استخدام جافا والوصول إلى طبقات الصوت عبر اسيو ويكون الكمون المنخفض حقا (64 عينات الكمون وهو القادم الى لا شيء) على منصة ويندوز. وهذا يعني سيكون لديك المزامنة بين الشفاه على شريط فيديو / الفيلم. المزيد من الكمون على ماك لعدم وجود اسيو إلى "اختصار" مزيج من OS X و "جافا على رأس"، ولكن لا يزال OK. لينكس أيضا، ولكن أنا أكثر جاهل. انظر soundpimp.com ل(والعالم الأول) مثال عملي جاوة واسيو العمل في وئام تام. انظر أيضا راديو NRK والتلفزيون الروبوت التطبيق يحتوي على MP3 فك فرنك (من جاوة). يمكنك أن تفعل الأشياء الأكثر الصوت مع جافا، ومن ثم استخدام طبقة الأم إذا كان الوقت الاضافي حرجة.
تحقق من مكتبة دعا Jsyn.
لماذا لا قضاء يوم واحد وكتابة تطبيق جافا بسيط أن يفعل الحد الأدنى من المعالجة والتحقق ما إذا كان الأداء هو أداكواتي.
من http://www.jsresources.org/faq_performance.html#java_slow
دعونا جمع بعض ethernal الحكمة:
الأرض مسطحة.
و لا تنسى:جافا بطيء.
كما العديد من التطبيقات تثبت (انظر قسم الروابط), جافا كافية لبناء المحررين الصوت متعدد المسارات تسجيل أنظمة MIDI برامج معالجة.في محاولة منه!
