जैक को आपकी मशीन के लिए न्यूनतम संभव प्रसंस्करण विलंबता निर्धारित करने के लिए सर्वर को कॉन्फ़िगर करने के लिए - ज्ञानी उपयोगकर्ता की आवश्यकता होती है । (प्रोसेसिंग लेटेंसी वह समय है जो सर्वर को क्लाइंट एप्लिकेशन से / के पास डेटा ले जाने और फिर सिस्टम के बाहर ऑडियो नमूनों के अगले "चंक" को भेजने / प्राप्त करने के लिए लेता है।) जैक या तो समय पर ऑडियो डेटा के उन हिस्सों को वितरित करेगा, या। यह विफल हो जाएगा और आपको एक बफर अंडर्रन (कभी-कभी "ड्रॉपआउट", या पॉप और क्लिक कहा जाता है) देगा)। यदि जैक लगातार कम हो जाता है, तो यह आपका काम है कि सर्वर को अलग-अलग सेटिंग्स के साथ फिर से शुरू करें, या क्लाइंट एप्लिकेशन में कुछ परिवर्तन करके उन्हें अधिक कुशल बनाएं ताकि आप अपने ऑडियो समय सीमा को पूरा कर सकें। चूंकि आपकी सर्वर सेटिंग्स सभी ग्राहकों के लिए समान रूप से लागू होती हैं, जैक कई ऑडियो अनुप्रयोगों के बीच ऑडियो को रूट करने और अनुमानित परिणाम प्राप्त करने के लिए काफी उपयोगी है । (यानी, यह विभिन्न ऑडियो घटकों में "जैक" प्लग करने जैसा है।)
पल्स को सर्वर द्वारा सिस्टम से बाहर ऑडियो भेजने / प्राप्त करने की समय सीमा पूरी नहीं करने के कारण ऑडियो ड्रॉप आउट की संख्या को कम करने के लिए डिज़ाइन किया गया है। यह जाहिरा तौर पर क्लाइंट अनुप्रयोगों के लिए एक बड़े बफर को चुनकर ऐसा करने की कोशिश करता है जो कम प्रसंस्करण विलंबता का अनुरोध नहीं करता है , फिर ग्राहकों के अनुप्रयोगों के लिए उस बफर में "इंजेक्शन" नमूने जो कि एक समय सीमा है। यदि यह इतनी जल्दी नमूनों को इंजेक्ट करने की कोशिश करता है, तो यह एक समय सीमा समाप्त हो जाती है और इसके कारण कम हो जाता है, पल्स स्वचालित रूप से उस समय की सबसे कम मात्रा में वृद्धि करेगा, जो क्लाइंट को सर्वर पर ऑडियो अपडेट भेजने देगा। पल्स डॉक्स स्पष्ट रूप से बताता है कि अल्ट्रा लो लेटेंसी - कहते हैं, प्रसंस्करण लेटेंसी के 10ms से कम है- डिजाइन लक्ष्य नहीं है। यह देखते हुए कि स्वयं लिनक्स (और शायद आपका हार्डवेयर) ऑडियो के वास्तविक समय निर्धारण के लिए डिज़ाइन नहीं किया गया था, मैं उन पर विश्वास करने के लिए उपयुक्त हूं।
उपयोगकर्ता-विन्यास के संदर्भ में, पल्स "प्रकाश" है। (कोई कह सकता है कि पल्स में कम कॉन्फ़िगरेशन विलंबता है , कुछ ऐसा जो दुर्भाग्य से कई लिनक्स ऑडियो ऐप को स्पष्ट रूप से अवहेलना करता है।) जैक की तुलना में इसकी अंतर्निहित जटिलता के संदर्भ में, पल्स "वसा" है।
एक निश्चित उत्तर पाने के लिए जिस पर तेजी है, आपको बस एक लूपबैक डिवाइस प्राप्त करना होगा और सच्चाई को जानने के लिए अपने सिस्टम पर राउंड-ट्रिप लेटेंसी को मापना होगा । राउंड-ट्रिप लेटेंसी वह समय है जो आपके सिस्टम को ऑडियो प्रोसेस करने और प्राप्त करने के लिए सिस्टम में वापस संसाधित होने में ले जाता है। ऑनलाइन ट्यूटोरियल हैं जो बताते हैं कि लिनक्स के तहत यह कैसे करना है। इससे आपको पता चल जाएगा कि आप वास्तव में उसके बाद क्या कर रहे हैं, जो कि कथित विलंबता है - उस समय से जब आप किसी घटना को ट्रिगर करते हैं (उदाहरण के लिए, गिटार के तारों को टकराते हुए) जब आप पहली बार ध्वनि सुनते हैं। वह परिणाम (जैसे, गिटार राग सुनना)।
अंत में, ध्यान रखें कि पल्स और जैक दोनों अधिकांश GNU / लिनक्स वितरण पर ALSA के शीर्ष पर बैठते हैं। मुझे पता है कि आप केवल जैक बनाम पल्स के बारे में पूछ रहे हैं। लेकिन अगर आप एक एकल ऑडियो एप्लिकेशन का उपयोग कर रहे हैं, जो सीधे ALSA से जुड़ सकता है, तो कोई अनुमान योग्य तरीका नहीं है कि पल्स या जैक को जोड़ने से आपको अकेले ALSA की तुलना में कथित विलंबता कम मिलेगी । इस अर्थ में, पल्स और जैक दोनों "मोटे" हैं।
tldr; अकेले ALSA सबसे तेज़ है, जैक कई ऑडियो अनुप्रयोगों को एक साथ चलाने के लिए उपयोगी है, और जब आप अल्ट्रा लो लेटेंसी के बारे में परवाह नहीं करते हैं, तो पल्स का उपयोग करना सबसे आसान है। किसी भी दस्तावेज या चर्चा को अनदेखा करें जो यह बताए बिना विलंबता का उपयोग करता है कि किस प्रकार की विलंबता का मतलब है। (दुर्भाग्य से, पल्स के बारे में आधिकारिक जैक डॉक्स और लेनार्ट के ब्लॉग प्रविष्टियों दोनों इस श्रेणी में आते हैं।)
नोट : ऐसे किनारे-मामले हो सकते हैं, जहां आप एकल ऑडियो एप्लिकेशन का उपयोग करना चाहते हैं और इसमें एक cram ALSA इंटरफ़ेस और एक सभ्य जैक इंटरफ़ेस है। उस स्थिति में जैक का उपयोग करने से आपको कम विलंबता मिल सकती है। लेकिन अगर हम विलंबता को कम करने के लिए डिज़ाइन किए गए ऐप्स के बारे में बात कर रहे हैं तो उन मामलों को दुर्लभ होना चाहिए। लेकिन एक लूपबैक डिवाइस को हुक करें और मेरी परिकल्पना का परीक्षण करें!