पल्सएडियो सिंक हकलाना


12

मैंने अपने पाई पर रास्पियन स्थापित किया है और लाउडस्पीकर चलाकर अपने डेस्कटॉप से ​​पाई तक सभी ऑडियो स्ट्रीम करने के इरादे से पल्सएडियो सिंक को कॉन्फ़िगर किया है।

मैंने इस अच्छे वर्णन का अनुसरण किया: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=38&t=11124

सबसे पहले, यह समस्या के बिना काम करने के लिए दिखाई दिया। हालाँकि, डेस्कटॉप से ​​भेजा गया ऑडियो पाई पर लगातार बड़बड़ा रहा है, मानो लगातार बीच-बीच में गायब हो रहे कुछ नमूनों के साथ लगातार बफर अंडरग्राउंड थे।

मैंने पूरा दिन कारण खोजने की कोशिश में बिताया, लेकिन कोई फायदा नहीं हुआ। मूल सेटअप है:

  • वायर्ड लैन कनेक्शन
  • नवीनतम फर्मवेयर अपडेट के साथ नवीनतम रस्पियन पाई (26 सितंबर 2013)
  • PulseAudio 2.0 दोनों तरफ (उबंटू डेस्कटॉप)
  • Mplayer, totem, ffplay के माध्यम से प्लेबैक
  • मॉड्यूल-देशी-प्रोटोकॉल-टीसीपी के माध्यम से नेटवर्क ट्रांसमिशन

यही मैंने कोशिश की:

  • पाई पर सीधे ऑडियो चलाना पूरी तरह से काम करता है।
  • अन्य (डेस्कटॉप) कंप्यूटर पर स्ट्रीमिंग ठीक काम करती है।
  • प्रत्यक्ष कनेक्शन के साथ ऑडियो भेजना ($ PULSE_SERVER निर्दिष्ट करना) बहुत कम हकलाने के साथ काफी अच्छा काम करता है, लेकिन फिर भी समस्या -2 (नीचे देखें) के लिए प्रवण है
  • डेस्कटॉप PulseAudio टनलिंग के माध्यम से ऑडियो भेजना लगातार हकलाना देता है
  • बढ़ती प्राथमिकताएं / वास्तविक समय निर्धारण ... मदद नहीं की
  • नमूना दर को 48 किलोहर्ट्ज़ पर ठीक करना ... मदद नहीं करता था
  • "तुच्छ" करने के लिए resampling एल्गोरिथ्म की स्थापना ... मदद नहीं की
  • डिफ़ॉल्ट-टुकड़े / टुकड़े-आकार को समायोजित करना ... मदद नहीं की
  • मुझे PulseAudio लॉग में किसी समस्या का संकेत नहीं मिल रहा है (उस समय से जब मैंने प्लेबैक शुरू किया था):

    D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
    D: [alsa-sink] sink-input.c: Requesting rewind due to uncorking
    D: [pulseaudio] sink.c: Suspend cause of sink alsa_output.platform-bcm2835_AUD0.0.analog-stereo is 0x0000, resuming
    I: [alsa-sink] alsa-sink.c: Trying resume...
    I: [alsa-sink] alsa-util.c: cannot disable ALSA period wakeups
    D: [alsa-sink] alsa-util.c: Maximum hw buffer size is 341 ms
    D: [alsa-sink] alsa-util.c: Set buffer size first (to 16384 samples),  period size second (to 16384 samples).
    I: [alsa-sink] alsa-util.c: ALSA period wakeups were not disabled
    D: [alsa-sink] alsa-sink.c: Latency set to 25.00ms
    D: [alsa-sink] alsa-sink.c: hwbuf_unused=60736
    D: [alsa-sink] alsa-sink.c: setting avail_min=15665
    I: [alsa-sink] alsa-sink.c: Time scheduling watermark is 15.00ms
    I: [alsa-sink] alsa-sink.c: Resumed successfully...
    I: [alsa-sink] alsa-sink.c: Starting playback.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [pulseaudio] module-suspend-on-idle.c: Sink alsa_output.platform-bcm2835_AUD0.0.analog-stereo becomes busy.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
    D: [alsa-sink] ratelimit.c: 115 events suppressed
    D: [alsa-sink] alsa-sink.c: Wakeup from ALSA!
    ... no more output, but stuttering continues ...
    

समस्या 2: जैसा कि ऊपर कहा गया है, मैं प्रत्यक्ष कनेक्शन के साथ काफी ठीक ऑडियो प्राप्त कर सकता हूं। हालाँकि, स्ट्रीम के कुछ स्काइप्स (mplayer का उपयोग करके) के बाद, PulseAudio सर्वर हैंग हो जाता है और किसी भी ऑडियो को नहीं चलाता है। कभी-कभी इसे mplayer को पुनरारंभ करके पुनर्जीवित किया जा सकता है। कभी-कभी यह इतनी बुरी तरह से लटक जाता है कि PulseAudio को फिर से शुरू करना पड़ता है। कभी-कभी यह तब भी लटका रहता है जब मैं केवल वॉल्यूम स्तर बदल देता हूं।

PulseAudio डॉक्स के अनुसार, ट्यून किए गए कनेक्शन पर सीधे कनेक्शन का लाभ बेहतर बफरिंग नियंत्रण है, जो यह बताता है कि मुझे सीधे कनेक्शन के साथ अच्छा ऑडियो क्यों मिलता है: http://www.freedesktop.org/wiki/Software / पल्सऑडियो / प्रलेखन / प्रयोक्ता / नेटवर्क /

मैं अभी विचारों से बाहर हूं। हकलाने और समस्या 2 का कारण क्या हो सकता है? बस एक विचार है कि डिबगिंग कैसे आगे बढ़ें, इसकी भी सराहना की जाएगी।


आपने सीधे ऑडियो कैसे चलाया? मुझे aplay के साथ कोई समस्या नहीं है, लेकिन पैपलेट स्टूटर्स और इकोस बहुत बुरी तरह से।
जॉन ला रोय

मैंने mplayer, totem, madplay, ... का उपयोग किया, लेकिन यह तथ्य कि अलग-अलग खिलाड़ी अलग-अलग व्यवहार करते हैं, मेरे अनुमान का समर्थन करते हैं कि यह डेटा बफरिंग के साथ एक सॉफ्टवेयर समस्या लगती है। कुछ खिलाड़ी दूसरों की तुलना में वास्तविक समय से अधिक डेटा को आगे बढ़ाते हैं।
किसान

मुझे सिर्फ साइन वेव्स बजाने में दिक्कत हो रही है । मुझे लगता है कि इससे पहले कि मैं लैन पर स्ट्रीमिंग की कोशिश करूं, मुझे इसे हल करने की आवश्यकता होगी।
जॉन ला रोय

जवाबों:


6

tsched_buffer_sizeऔर tsched_buffer_watermarkयह मेरे लिए काम करने वाली सेटिंग थी।

मैं अपने PulseAudio को एक सिस्टम उदाहरण के रूप में चलाता हूं, इसलिए कॉन्फ़िगरेशन में है /etc/pulse/system.pa। यदि आप इसके बजाय सत्र उदाहरण का उपयोग कर रहे हैं, तो कॉन्फ़िगरेशन अंदर होगा /etc/pulse/default.pa

यह डिफ़ॉल्ट है:

### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
load-module module-udev-detect
.else
### Use the static hardware detection module (for systems that lack udev/hal  support)
load-module module-detect
.endif

मैंने इसे इस से बदल दिया: (यानी, यह टिप्पणी की)

### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
#load-module module-udev-detect
.else
### Use the static hardware detection module (for systems that lack udev/hal  support)
#load-module module-detect
.endif

फिर मैंने निम्नलिखित पंक्ति जोड़ी:

load-module module-alsa-card device_id=0 tsched=true tsched_buffer_size=1048576 tsched_buffer_watermark=262144

Http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index6h3 देखें


अच्छी बात। मैंने कोशिश की, लेकिन इसका कोई फायदा नहीं हुआ। बहुत बड़े बफर आकार के साथ भी। PULSE_SERVER को Pi पर सेट करके सीधे कनेक्शन पर ऑडियो भेजने से स्वच्छ ऑडियो मिलता है, लेकिन सिर्फ वॉल्यूम बदलने से अंत में कनेक्शन फ्रीज हो जाएगा। सुरंग के माध्यम से ऑडियो अभी भी हकलाना देता है। मेरा अनुमान है कि यह वास्तव में एक पल्सएडियो समस्या है, क्योंकि उस बड़े बफर आकार (मैंने 4 एमबी का उपयोग किया है) के साथ, किसी को यह देखना चाहिए कि ऑडियो फ़ाइल की शुरुआत में समय से पहले डिकोड किया गया है। लेकिन यह नहीं है। तो वहाँ फिर से भरना धीमा कुछ होना चाहिए।
farindk

उसी तरह के मुद्दों में भागना। मेरे विशेष मामले में, PULSE_SERVER + mplayer एक आकर्षण की तरह काम करता है, जबकि PULSE_SERVER + क्लेमेंटाइन (जो मुझे लगता है कि gstreamer का उपयोग कर रहा है) बहुत टट्टी करता है। किसी भी विचार दोनों के बीच क्या अंतर है?
जोनाथन प्रोत्ज़ेंको

@Protzenko: किसी भी स्रोत को देखे बिना मेरा अनुमान है कि पिल्ले डेटा को तब तक धक्का दे सकता है जब तक कि पल्सएडियो ब्लॉक नहीं हो जाता है, जबकि gstreamer एक रीयलटाइम संदर्भ द्वारा देखे गए डेटा को बाहर भेज सकता है। इसका मतलब यह होगा कि पूर्व मामले में बफ़र्स बहुत अधिक भरे हुए हैं, और इसके परिणामस्वरूप, एक बड़ा विलंब है।
किसान

मैं एक ही समस्या देख रहा हूँ PULSE_SERVER + ffmpeg ठीक, PULSE_SERVER + mpd शटर और अंतर्निहित
अंडररन

3

मुख्य बिंदु यह है कि आपको उपयोग करना चाहिए module-tunnel-sink-new, लेकिन रास्पबेरी पी 1 पर हकलाना मुक्त नेटवर्क ऑडियो प्राप्त करने के लिए आपको कुछ अन्य बदलाव भी करने होंगे।

  1. रीयल टाइम प्राथमिकता के साथ रास्पबेरी पाई पर पल्सेडियो चलाएं:
pulseaudio --start --high-priority=yes --realtime=yes

कंप्यूटर को निरूपित करने के लिए हमें प्रेषक शब्द का उपयोग करें जो आपके रास्पबेरी पाई को स्ट्रीम भेजता है।

  1. सेट default-fragmentsऔर default-fragment-size-msecमें daemon.confपर इस ये मान रहे हैं:
default-fragments = 8
default-fragment-size-msec = 12
  1. प्रेषक कोmodule-tunnel-sink-new यह आदेश जारी करके उपयोग करें (अपने रास्पबेरी पाई के होस्टनाम को आरपी 1 कहकर और आप अपने स्थानीय नेटवर्क पर काम कर रहे हैं। अन्यथा, बस अपने रास्पबेरी पीआई के आईपी-एड्रेस का उपयोग करें)।
pactl load-module module-tunnel-sink-new server=RP1.local

इन सेटिंग्स के साथ मुझे 54 एमबीपीएस पर एक वायरलेस नेटवर्क पर काम करने वाले वायरलेस नेटवर्क पर एक रास्पबेरी 1 से हकलाना-मुक्त ऑडियो मिलता है (मेरे सेटअप में, प्रेषक ईथरनेट का उपयोग करता है और RP1 wlan का उपयोग कर रहा है)। वास्तव में, यह तब भी काम करता है जब प्रेषक और रास्पबेरी दोनों वायरलेस का उपयोग कर रहे हैं, कम से कम अगर वायरलेस नेटवर्क पर कोई अन्य डिवाइस नहीं हैं।


अब तक महान काम करता है। मैंने पाया कि मेरे Pi3 (कुछ हद तक नए डेबियन / सॉफ्टवेयर के साथ) के लिए मुझे "डिफ़ॉल्ट-टुकड़े" सेटिंग्स को लेने के लिए कुछ और बदलना पड़ा। (अर्थात्, कुछ सेटिंग tsched=0, wiki.archlinux.org/index.php/PulseAudio/… देखें )
rien333

यदि आप अभी भी हकलाने का अनुभव करते हैं, तो आर्क विकि भी rtp स्ट्रीमिंग प्रोटोकॉल को बदलने की सलाह देते हैं: wiki.archlinux.org/index.php/PulseAudio/…
rien333

1

क्या आपने इस पृष्ठ की जाँच की:

http://manpages.ubuntu.com/manpages/lucid/man5/pulse-daemon.conf.5.html

DEFAULT FRAGMENT SETTINGS

   Some hardware drivers  require  the  hardware  playback  buffer  to  be
   subdivided  into  several  fragments.  It  is  possible to change these
   buffer metrics for machines with high  scheduling  latencies.  Not  all
   possible  values  that  may  be  configured  here  are available in all
   hardware. The driver will to find the nearest setting supported. Modern
   drivers that support timer-based scheduling ignore these options.

   default-fragments= The default number of fragments. Defaults to 4.

   default-fragment-size-msec=The  duration of a single fragment. Defaults
   to 25ms (i.e. the total buffer is thus 100ms long).

हां, ऐसा करने की कोशिश की, लेकिन इससे कोई फायदा नहीं हुआ। जैसा कि मैंने उल्लेख किया है, डिवाइस पर ऑडियो-प्लेबैक ही ठीक काम करता है। मैं इसे पल्सएडियो टनलिंग के साथ एक नेटवर्क प्रोटोकॉल समस्या मानता हूं। यहां तक ​​कि डायरेक्ट कनेक्शन प्रोटोकॉल भी अच्छा काम करता है। मैंने अब एक सरल ब्लूटूथ स्ट्रीमिंग हार्डवेयर पर स्विच किया है, जो विश्वसनीय है और अन्य चीजों के लिए आरपीआई का उपयोग कर रहा है।
किसान

1

हकलाने या समयबाह्य समस्याओं से छुटकारा पाने के लिए, परिवार कल्याण में गिरावट का प्रयास करें:

sudo rpi-update eeb2e51c3e08cd5efa4246aa8dc54a09b25ada12

1
चेतावनीrpi-update इस बात से अवगत रहें कि इस पद्धति का आपके सिस्टम में क्या उपयोग हो सकता है।
18 मई को अर्थमून जू

@earthmeLon आप कम से कम एक संदर्भ दे सकते हैं या हमें सूचित करने की कोशिश rpi-updateकर सकते हैं कि इस शैली का उपयोग हमारे सिस्टम के लिए क्या कर सकता है ...
user11171

मैनुअल पढ़ना सुनिश्चित करें , और यह समझने के लिए कुछ शोध करें कि यह आपके सिस्टम और किसी भी संभावित खतरों को कैसे प्रभावित करता है।
अर्थमीलोन

0

मैंने माना कि यह समस्या कर्नेल संस्करण से संबंधित हो सकती है। ३.६.११ से ३.१२.० तक अपग्रेड करने के बाद मैंने लगातार उन अंडररून को प्राप्त किया। 3.6.11 के डाउनग्रेड ने मेरे लिए समस्या हल कर दी।


0

मैं इस पृष्ठ को एक-दो बार पढ़ रहा हूं ... मैं रास्पबेरीपी-पल्सेडियो-नेटवर्क संयोजन के हकलाने से भी निराश हूं। मैंने थोड़ा और खोज किया और एक पृष्ठ पाया जहां मुझे समाधान का एक भाग मिला:

=> Default.pa (या system.pa) में मॉड्यूल-सस्पेंड-ऑन-निष्क्रिय निष्क्रिय करें।

निहारना, हकलाना गायब हो गया है!

अब एकमात्र समस्या यह है कि थोड़ी देर के बाद (10 से 20 सेकंड) प्लेबैक लटका रहता है: - /

कोई सुझाव?

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.