Mopidy: انظر إلى إضافة حوض فيفو gstreamer

تم إنشاؤها على ٨ يوليو ٢٠١٤  ·  73تعليقات  ·  مصدر: mopidy/mopidy

يستمر هذا في الظهور حيث يبدو أن الناس يحبون متخيل ncmpcpp

حيلة صنع حوض FIFO موثوق به ذات شقين. تحتاج إلى استخدام عمليات الكتابة غير المحظورة ، مما يعني أن فتح مقبس الكتابة سيفشل ما لم يكن هناك قارئ ، وبالتالي تحتاج إلى قارئ أيضًا. ثانيًا ، إذا امتلأ المخزن المؤقت بسبب تأخر القارئ الخارجي أو عدم وجوده ، يحتاج القارئ الداخلي إلى مسح المخزن المؤقت.

تلتقط الشفرة التالية الجوهر الأساسي لهذا ، ولكنها لا تزال بحاجة إلى مزيد من العمل فيما يتعلق بمعالجة الأخطاء.

import errno
import os
import stat

LINUX_FIFO_BUFFER_SIZE = 65536


class FifoStreamer(object):                                                     
    def __init__(self, location):                                               
        self.location = location                                                
        self.reader = None                                                      
        self.writer = None                                                      

    def create(self):                                                           
        try:                                                                    
            mode = os.stat(self.location).st_mode                               
            if not stat.S_ISFIFO(mode):                                         
                raise Exception('File exists but is not a FIFO')                
        except OSError as e:                                                    
            if e.errno == errno.ENOENT:                                         
                os.mkfifo(self.location)                                        
            else:                                                               
                raise                                                           

        # TODO: wrap in could not open reader / writer?
        self.reader = os.open(self.location, os.O_NONBLOCK | os.O_RDONLY)       
        self.writer = os.open(self.location, os.O_NONBLOCK | os.O_WRONLY)       

    def close(self):                                                            
        # TODO: make closing robust
        os.close(self.writer)                                                   
        os.close(self.reader)                                                   

    def write(self, data):                                                      
        while data:                                                             
            try:                                                                
                written = os.write(self.writer, data)                           
                data = data[written:]                                           
            except OSError as e:                                                
                if e.errno == errno.EINTR:                                      
                    continue                                                    
                elif e.errno in (errno.EAGAIN, errno.EWOULDBLOCK):              
                    self.flush()                                                
                else:                                                           
                    raise                                                       

    def flush(self):                                                            
        while True:                                                             
            try:                                                                    
                if not os.read(self.reader, LINUX_FIFO_BUFFER_SIZE):                             
                    break                                                       
            except OSError as e:                                                
                if e.errno in (errno.EAGAIN, errno.EWOULDBLOCK):                
                    break                                                       
                elif e.errno == errno.EINTR:                                    
                    continue                                                    
                else:                                                           
                    raise

يجب الآن دمج الكود أعلاه مع GStreamer للقيام بذلك بالفعل. بافتراض أن 0.10 يمكن تحقيقها إلى حد كبير ، السبب في أنني متردد هو أننا نخطط للانتقال إلى 1.x وأن ربط gir ليس مناسبًا لعمل عناصر في Python. في حالة هذا الرمز في 1.x تتلخص المشكلة في عدم القدرة على إنشاء قوالب اللوحة التي يتوقع BaseSink العثور عليها. قد يكون إنشاء هذا كعنصر عادي أمرًا ممكنًا ، ولكنك ستحتاج إلى إعادة تنفيذ طريقة التعامل مع الكثير من عمليات المعالجة التي تضمنها BaseSink.

import gobject                                                                  

import pygst                                                                    
pygst.require('0.10')                                                           
import gst                                                             


class FifoSink(gst.BaseSink):                                                   
    __gstdetails__ = (                                                          
        'FifoSink',                                                             
        'Sink',                                                                 
        'Sink designed to handle FIFO output.',                        
        'Mopidy')                                                               

    __gsttemplates__ = (gst.PadTemplate('sink', gst.PAD_SINK, gst.PAD_ALWAYS,   
                                        gst.caps_new_any()),)                   

    # TODO: don't allow changing location in flight, i.e. create getter/setter
    location = gobject.property(type=str)                                       

    def __init__(self):                                                         
        gst.BaseSink.__init__(self)                                             
        self.streamer = None                                                    

    def do_start(self):                                                                                               
        self.streamer = FifoStreamer(self.location)                             
        self.streamer.create()                                                  
        return True                                                             

    def do_stop(self):                                                          
        self.streamer.close()                                                   
        return True                                                             

    def do_render(self, buf):                                                   
        try:                                                                    
            self.streamer.write(bytes(buf))                                     
            return gst.FLOW_OK                                                  
        except OSError as e:                                                    
            self.error("Failed: %s", e)                                         
            return gst.FLOW_ERROR                                               


gobject.type_register(FifoSink)                                                 
gst.element_register(                                                           
    FifoSink, 'fifosink', gst.RANK_MARGINAL)                                    

if __name__ == '__main__':                                                      
    import gobject                                                              
    gobject.threads_init()                                                      

    output = """                                                                
capsfilter caps="audio/x-raw-int,width=16,rate=44100,channels=1" ! 
tee name=t 
t. ! queue ! alsasink                                                           
t. ! queue ! fifosink location=/tmp/test2.fifo                                  
"""                                                                             

    sink = gst.parse_bin_from_description(                                      
        output, ghost_unconnected_pads=True)                                    

    playbin = gst.element_factory_make('playbin2')                              
    playbin.set_property('audio_sink', sink)

لاحظ أن إحدى المشكلات التي واجهتها في الاختبار كانت في الواقع نسيت مطابقة تنسيق الصوت المتوقع بواسطة ncmpcpp ، لذا تأكد من تطابق أحادي / ستريو بالفعل.

C-enhancement A-audio
مصدر
picture adamcik
👍8

التعليق الأكثر فائدة

لمعلوماتك لقد أضفت دعمًا لـ gstreamer udpsink إلى ncmpcpp حتى الآن يمكن استخدامه مباشرة بدون اختراق فيفو.

راجع https://github.com/ncmpcpp/ncmpcpp/commit/fb886f687014e22b2fe1477da855be5201063ea8 لمزيد من التفاصيل.

أدناه دعابة. هذا هو mopidy + mopidy-spotify + mopidy-mpd + ncmpcpp.

https://user-images.githubusercontent.com/387658/102549720-e41bf980-40bc-11eb-8127-70889011e52f.mp4

picture arybczak في ١٧ ديسمبر ٢٠٢٠
❤10 🎉6 👍6 👀2

ال 73 كومينتر

أين ذهب هذا؟ هل يضاف هذا إلى الباقة الرئيسية؟

CestDiego picture CestDiego في ٦ أكتوبر ٢٠١٤

لم يتم العمل على هذا لأننا سنحتاج إلى تحويله إلى GStreamer 1.0 ، وقد كشفت جميع تجاربي مع ذلك حتى الآن عن مشاكل عند عمل عناصر مخصصة في Python. هناك طرق أخرى ربما لحل كل شيء ، ولكن ليس شيئًا لدي وقت للعمل عليه.

adamcik picture adamcik في ١١ أكتوبر ٢٠١٤

أرغب في رؤية دعم FIFO مضافًا :)

johnhamelink picture johnhamelink في ٦ نوفمبر ٢٠١٤

لقد وجدت للتو هذا البحث عن طريقة للحصول على متخيل موسيقى ncmpcpp للعمل مع mopidy. أنا مؤيد.

proxa picture proxa في ٦ نوفمبر ٢٠١٤

نعم ، هذا هو نفس سبب العثور على هذا. سيكون من الرائع حقا
تكون قادرًا على تصور الموسيقى المتدفقة ،

2014-11-06 2:19 GMT-05: 00 Blake [email protected] :

لقد وجدت للتو هذا البحث عن طريقة للحصول على متخيل موسيقى ncmpcpp
العمل مع mopidy. أنا مؤيد.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -61936376.

CestDiego picture CestDiego في ٦ نوفمبر ٢٠١٤

هناك ملحقات التصور gstreamer ، ألا يمكنك فقط استخدام تلك؟
في 6 نوفمبر 2014 الساعة 08:35 ، كتب "Diego Berrocal" [email protected] :

نعم ، هذا هو نفس سبب العثور على هذا. سيكون من الرائع حقا
تكون قادرًا على تصور الموسيقى المتدفقة ،

2014-11-06 2:19 GMT-05: 00 Blake [email protected] :

لقد وجدت للتو هذا البحث عن طريقة للحصول على متخيل موسيقى ncmpcpp
ل
العمل مع mopidy. أنا مؤيد.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -61936376.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -62007426.

kingosticks picture kingosticks في ٦ نوفمبر ٢٠١٤

لاحظ أن هؤلاء في طريقهم للخروج في الإصدار التالي.

adamcik picture adamcik في ٦ نوفمبر ٢٠١٤

هل هناك شخص يعمل على هذا؟ سيكون من الرائع حقًا أن تكون قادرًا على استخدام متخيل ncmpcpp مع mopidy.

andreasboden picture andreasboden في ١٣ فبراير ٢٠١٥

ليس هذا ما أعرفه ، ومن المحتمل ألا نرغب في القيام بذلك كعنصر GStreamer لأنه سيمنع ترحيلنا إلى GStreamer 1.x.

adamcik picture adamcik في ١٤ فبراير ٢٠١٥

هذا هو IMO أيضًا ممنوع من إضافة الدعم المناسب للنواتج.

adamcik picture adamcik في ٢٥ فبراير ٢٠١٥

فقط أضفت أنني واجهت هذه المشكلة أيضًا عند محاولة إضافة دعم متخيل إلى Mopidy / ncmpcpp. أرغب في الحصول على هذا في المستقبل حتى لو لم يتم العمل عليه حاليًا. أود أيضًا أن أعرب عن فائق الاحترام لأولئك الذين يساهمون بوقتهم في مشاريع مفتوحة المصدر. :ابتسامة:

codeurge picture codeurge في ١٥ أبريل ٢٠١٥

من الناحية المثالية هذا سيعمل عن بعد. تكمن قوة Mopidy حقًا في كونه حلاً يمكن أن يكون في السحابة الخاصة بك.

wernight picture wernight في ٢٧ أبريل ٢٠١٥

بشكل عام ، لا تعد FIFOs وسيلة محمولة جدًا للاتصالات البينية ويجب تجنبها IMO. لديهم أيضًا بعض الآثار الجانبية السيئة ، والتي سبق ذكرها في هذا الموضوع. أعتقد أنك أفضل حالًا في التخلص من الحزم الخاصة بك باستخدام حوض UDP شخصيًا ... هذا حل أكثر عمومية ويمكن بسهولة تكييفه مع شيء يكتب إلى FIFO (إذا لزم الأمر) خارج Mopidy ... إنه حل واحد سطر البرنامج النصي للقذيفة لقراءة البيانات من منفذ UDP (باستخدام netcat) وكتابتها في FIFO.

liamw9534 picture liamw9534 في ٢٧ أبريل ٢٠١٥

هذا يبدو جيدا. قد يكذب العملاء أن ncmpcpp سيسمح أيضًا باستخدام ذلك كمدخل.

فكرة أخرى هي استخدام PulseAudio مباشرة لأنه لن يتطلب تنفيذًا إضافيًا من جانب Mopidy. تستخدم حاوية Docker التي صنعتها بروتوكول TCP للوصول إلى PulseAudio عبر الشبكة. يمكن أن يستخدم ncmpcpp ذلك بشكل مباشر.

wernight picture wernight في ٢٧ أبريل ٢٠١٥

من خلال ما قرأته ، يقوم المتخيل فقط بتشغيل FFT على كتل من العينات التي تتم قراءتها من ملف FIFO. النقطة التي أوضحها هي أنه يمكنك إنشاء FIFO خارج Mopidy باستخدام mkfifo ثم قراءة بيانات UDP من Mopidy باستخدام netcat وإعادة توجيه الإخراج من netcat إلى ملف FIFO. وبالتالي ، لا يلزم تغيير أي شيء بقدر ما يتعلق الأمر بـ ncmpcpp ، فهو يقرأ فقط ملف FIFO.

لتحقيق ما تستهدفه في Mopidy لا يتطلب أي جهد تنفيذ حيث يمكنك تغيير خاصية إخراج الصوت إلى الإخراج إلى عنصر udpsink GStreamer. على الأرجح سترغب في ترتيبه كجزء من "نقطة الإنطلاق" التي تخرج إلى كل من حوض ALSA / Pulse و udpsink.

liamw9534 picture liamw9534 في ٢٨ أبريل ٢٠١٥

يجب أن يعمل ما يلي .... لم يتم اختباره لذا قد يحتاج إلى بعض tweeking.

في تكوين صوت Mopidy:

output = tee name=t ! queue ! autoaudiosink t. ! queue ! udpsink port=5555

على مضيف Linux الخاص بك ، قم بتشغيل netcat للاستماع على المضيف المحلي لبيانات UDP على المنفذ 5555 وإخراج العينات إلى FIFO:

mkfifo /tmp/mopidy.fifo
nc -u -l 127.0.0.1 5555 > /tmp/mopidy.fifo &

في ملف mpd.conf الخاص بك:

audio_output {
    type                    "fifo"
    name                    "my_fifo"
    path                    "/tmp/mopidy.fifo"
    format                  "44100:16:2"
}
liamw9534 picture liamw9534 في ٢٨ أبريل ٢٠١٥

ملاحظة: إذا كنت تستخدم إخراج PulseAudio ، فقد يكون من الممكن القيام بشيء مماثل مع وحدة اتصال اتجاه TCP الخاصة به. ومع ذلك ، قد تحتاج إلى إجراء هندسة عكسية لأي بروتوكول يتم تشغيله عبر الجزء العلوي من اتصال TCP ، على سبيل المثال ، قد لا يكون من الممكن معاملته على أنه حوض خام.

liamw9534 picture liamw9534 في ٢٨ أبريل ٢٠١٥

شكرا @ liamw9534 للمشاركة. كنت سأستغرق بعض الوقت لفهم التكوين بما يكفي للقيام بذلك أو حتى معرفة أنني أستطيع ذلك. سأحاول إضافة ذلك إلى حاوية Docker لمعرفة ما إذا كانت تعمل.

wernight picture wernight في ٢٨ أبريل ٢٠١٥

قد يواجه هذا مشكلات إذا لم يكن لديك شيء يفرغ لعبة FIFA. نظرًا لأن netcat سوف يملأ مخزن kernel المؤقت ثم يفشل. واعتمادًا على كيفية فتح FIFO ، قد تواجه أيضًا مشكلات حيث يمكن أن تتطلب FIFO وجود قارئ ليكون قابلاً للكتابة: /

adamcik picture adamcik في ٢٨ أبريل ٢٠١٥

ولكن يمكنك تكييف كود FifoStreamer الخاص بي لقبول بيانات UDP والتعامل مع هذا الأمر نيابةً عنك ، كما آمل أن أكون قد تعاملت بالفعل مع معظم حالات الخطأ التي يمكنك مواجهتها هناك.

adamcik picture adamcik في ٢٨ أبريل ٢٠١٥

adamcik إذا كان لديك برنامج نصي يعمل ، فسيسعدني تضمينه كجزء من Docker-mopidy للبث على UDP افتراضيًا باستخدام خدعة الإخراج أعلاه.

wernight picture wernight في ٢٩ أبريل ٢٠١٥

لقد أجريت بعض التجارب الأساسية على سطر الأوامر وكلها تعمل بشكل جيد بشرط استخدام مهلة اتصال ، على سبيل المثال ، nc -kluw 1 127.0.0.1 5555 > /tmp/mopidy.fifo . هذا يفرض على netcat الاستماع دائمًا لاتصال منفذ مصدر جديد بعد انقطاع الاتصال الأخير (مهلة 1 ثانية).

يعمل الأمر أعلاه بغض النظر عما إذا كان أي شيء يقرأ من ملف FIFO أم لا ويعمل أيضًا إذا توقفت عملية القراءة من ملف FIFO وأغلقت الملف.

liamw9534 picture liamw9534 في ٢٩ أبريل ٢٠١٥

wernight انظر وصف هذا الخطأ ، وهذا هو كل رمز لدي.

adamcik picture adamcik في ٢٩ أبريل ٢٠١٥

وبالنسبة للأحزمة والأقواس فقط ، أود أن ألصق الأمر في حلقة while ، على سبيل المثال ، while :; do nc -kluw 1 127.0.0.1 5555> /tmp/mopidy.fifo; sleep 1; done - إذا تم الخروج ، فسيتم تشغيله مرة أخرى بعد تأخير لمدة ثانية واحدة.

liamw9534 picture liamw9534 في ٢٩ أبريل ٢٠١٥

@ liamw9534 لديك ملف mpd.conf هناك. فأنا في حيرة من هذا الأمر. أنت تقوم بتشغيل خادم MPD مستقل بالإضافة إلى mopidy-mpd؟

lrvick picture lrvick في ٢ مايو ٢٠١٥

lrvick نعم خطأي ، كان بالطبع أفكر في التكوين الذي يجب إضافته إلى ~ / .ncmpcpp / config

liamw9534 picture liamw9534 في ٢ مايو ٢٠١٥

.config/mopidy/mopidy.conf

...

[audio]
output = tee name=t ! queue ! autoaudiosink t. ! queue ! udpsink port=5555

$ mkfifo /tmp/mopidy.fifo
$ while :; do nc -kluw 1 127.0.0.1 -p 5555> /tmp/mopidy.fifo; sleep 1; done

(تمت إضافة -p هنا).

~/.ncmpcpp/config

audio_output {
    type                    "fifo"
    name                    "my_fifo"
    path                    "/tmp/mopidy.fifo"
    format                  "44100:16:2"
}

(يتم ذلك أيضًا في الليل / عامل ميناء - mopidy و wernight / عامل ميناء - ncmpcpp )

ومع ذلك ، يبدو أنه لا يمكن الاتصال بـ 5555 على الرغم من أن سجل Mopidy يوضح أنه فهم التكوين output . يظهر netstat أيضًا عدم وجود UDP مفتوح على 5555. أنا لا أفهم تمامًا سطر output : tee هو أمر bash ، والباقي يشبه Mopidy.

ومع ذلك ، وجدت udp6 [::]:51307 أثناء تشغيل الموسيقى.

wernight picture wernight في ٨ مايو ٢٠١٥

و output تم تفسيره على أنه GstBin العنصر الذي يحصل تمريرها إلى playbin2 كجزء من Mopidy - تحت غطاء محرك السيارة وهذا هو مجرد جيستريمر خط أنابيب، لا شيء خاص حقا. وبالتالي فإن tee هو في الواقع عنصر Gstreamer. لا علاقة له بأمر shell tee .

لذلك يمكنك تقريب ما يحدث داخل Mopidy في سطر الأوامر بفعل شيء مثل:

gst-launch audiotestsrc ! tee name=t ! queue ! autoaudiosink t. ! queue ! udpsink port=5555 &

سيبدأ هذا في تشغيل نغمة جيبية. ثم قم بتشغيل الأمر التالي:

nc -kluw 1 127.0.0.1 5555

يمكنني بعد ذلك البدء في رؤية الكثير من الأحرف الغريبة على شاشتي .... هذا هو اختبار دفق الصوت الذي يخرج إلى stdout من nc . هذا يثبت بشكل فعال أن النهج الأساسي يعمل. هل يمكنك تأكيد أنه يمكنك تكرار نفس السلوك؟

يمكنك بعد ذلك محاولة إضافة FIFO كخطوة ثانية وتأكيد أنه يمكنك cat في FIFO إلى stdout ورؤية نفس الأحرف الغريبة.

liamw9534 picture liamw9534 في ٨ مايو ٢٠١٥

أود أيضًا التحقق مرة أخرى من تنسيق التكوين المطلوب بواسطة ncmpcpp . لقد ألقيت نظرة سريعة على 

visualizer_fifo_path = "/tmp/mpd.fifo"
visualizer_output_name = "my_fifo"
visualizer_sync_interval = "30" 
visualizer_in_stereo = "yes"
visualizer_type = "spectrum" (spectrum/wave)

لا أستخدم ncmpcpp ، لذلك قد تكون المشكلة هنا أيضًا ...

liamw9534 picture liamw9534 في ٨ مايو ٢٠١٥ 
$ apt-get install gstreamer-tools
$ gst-launch audiotestsrc ! tee name=t ! queue ! autoaudiosink t. ! queue ! udpsink port=5555 &
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstPulseSinkClock
$ nc -kluw 1 127.0.0.1 -p 5555
no connection : Connection timed out

(مع nc ... -p else أحصل على خطأ)

أسمع النغمة تلعب بالرغم من ذلك.

wernight picture wernight في ١١ مايو ٢٠١٥

ما توزيعة الذي تستخدمه؟ أيضًا عند كتابة nc -h ما هو الناتج؟

$ nc -h
OpenBSD netcat (Debian patchlevel 1.89-4ubuntu1)
This is nc from the netcat-openbsd package. An alternative nc is available
in the netcat-traditional package.
usage: nc [-46DdhklnrStUuvzC] [-i interval] [-P proxy_username] [-p source_port]
      [-s source_ip_address] [-T ToS] [-w timeout] [-X proxy_protocol]
      [-x proxy_address[:port]] [hostname] [port[s]]
    Command Summary:
        -4      Use IPv4
        -6      Use IPv6
        -D      Enable the debug socket option
        -d      Detach from stdin
        -h      This help text
        -i secs     Delay interval for lines sent, ports scanned
        -k      Keep inbound sockets open for multiple connects
        -l      Listen mode, for inbound connects
        -n      Suppress name/port resolutions
        -P proxyuser    Username for proxy authentication
        -p port     Specify local port for remote connects
        -q secs     quit after EOF on stdin and delay of secs
        -r      Randomize remote ports
        -S      Enable the TCP MD5 signature option
        -s addr     Local source address
        -T ToS      Set IP Type of Service
        -C      Send CRLF as line-ending
        -t      Answer TELNET negotiation
        -U      Use UNIX domain socket
        -u      UDP mode
        -Z      DCCP mode
        -v      Verbose
        -w secs     Timeout for connects and final net reads
        -X proto    Proxy protocol: "4", "5" (SOCKS) or "connect"
        -x addr[:port]  Specify proxy address and port
        -z      Zero-I/O mode [used for scanning]
    Port numbers can be individual or ranges: lo-hi [inclusive]

الخيار -p غير مطلوب مع nc أستخدمه على Ubuntu. تشير صفحة الدليل أيضًا إلى أنه من الخطأ تحديد -p بالتزامن مع -l :

     -l      Used to specify that nc should listen for an incoming connection
             rather than initiate a connection to a remote host.  It is an error
             to use this option in conjunction with the -p, -s, or -z options.
             Additionally, any timeouts specified with the -w option are ignored.
liamw9534 picture liamw9534 في ١١ مايو ٢٠١٥

باستخدام Debian Wheezy.

فيما يلي الخطوات الكاملة لبدء تشغيل Ubuntu عن طريق تثبيت Docker :

  1. تثبيت Docker :

$ wget -qO- https://get.docker.com/ | sh $ sudo gpasswd -a ${USER} docker

  1. تفعيل PulseAudio عن بعد
  2. تشغيل على دبيان:

$ docker run --rm -it \ -e PULSE_SERVER=tcp:$(hostname -i):4713 \ -e PULSE_COOKIE_DATA=$(pax11publish -d | grep --color=never -Po '(?<=^Cookie: ).*') \ debian:wheezy $ apt-get update && apt-get install -y netcat $ nc -h [v1.10-40] connect to somewhere: nc [-options] hostname port[s] [ports] ... listen for inbound: nc -l -p port [-options] [hostname] [port] options: -c shell commands as `-e'; use /bin/sh to exec [dangerous!!] -e filename program to exec after connect [dangerous!!] -b allow broadcasts -g gateway source-routing hop point[s], up to 8 -G num source-routing pointer: 4, 8, 12, ... -h this cruft -i secs delay interval for lines sent, ports scanned -k set keepalive option on socket -l listen mode, for inbound connects -n numeric-only IP addresses, no DNS -o file hex dump of traffic -p port local port number -r randomize local and remote ports -q secs quit after EOF on stdin and delay of secs -s addr local source address -T tos set Type Of Service -t answer TELNET negotiation -u UDP mode -v verbose [use twice to be more verbose] -w secs timeout for connects and final net reads -z zero-I/O mode [used for scanning] port numbers can be individual or ranges: lo-hi [inclusive]; hyphens in port names must be backslash escaped (e.g. 'ftp\-data'). $ nc -kluw 1 127.0.0.1 5555 UDP listen needs -p arg $ apt-get install -y net-tools gstreamer-tools gstreamer0.10-plugins-good $ echo -ne $(echo $PULSE_COOKIE_DATA | sed -e 's/../\\x&/g') >$HOME/pulse.cookie $ export PULSE_COOKIE=$HOME/pulse.cookie $ gst-launch audiotestsrc ! tee name=t ! queue ! autoaudiosink t. ! queue ! udpsink port=5555 & $ nc -kluw 1 127.0.0.1 -p 5555 no connection : Connection timed out

wernight picture wernight في ١١ مايو ٢٠١٥

حاولت مع حزمة netcat-openbsd والتي تعطي:

$ nc -h
OpenBSD netcat (Debian patchlevel 1.105-7)
...

الآن nc لا يظهر شيئًا أثناء تشغيل النغمة (والتي تبدو أفضل إلى حد ما):

$ nc -kluw 1 127.0.0.1 5555
(nothing here)
wernight picture wernight في ١١ مايو ٢٠١٥

حسنًا ، افتح محطتين وفي أول تشغيل طرفية:

nc -kluw 1 127.0.0.1 5555

ثم في الجولة الثانية من المحطة:

nc -u 127.0.0.1 5555

أدخل بعض الأحرف في stdin في المحطة الثانية واضغط على ENTER. هل ترى نفس الأحرف تظهر في المحطة الأولى على stdout؟

liamw9534 picture liamw9534 في ١١ مايو ٢٠١٥

نعم هذا يعمل. حتى أنها تعمل عبر Dockers:

$ docker run --rm --name nc1 -it my-debian-with-nc nc -kluw 1 0.0.0.0 5555
Hello

$ docker run --rm --link nc1:nc1 -it my-debian-with-nc nc -u nc1 5555
Hello

لذا فإن هذا لا يفسر سبب إظهار nc لا شيء مع gst-launch . ومع ذلك ، اكتشفت أنني سأحتاج إلى تعيين host=SOMETHING لكي يعمل عبر الحاويات. سيكون هذا إشكالية. يبدو أنه لا يمكن البث. لكن هذا شيء يمكنني حله بمجرد أن يعمل على الأقل في حاوية واحدة.

wernight picture wernight في ١١ مايو ٢٠١٥

آها! إذا قمت بتعيين host=0.0.0.0 فإنه يعمل!

wernight picture wernight في ١١ مايو ٢٠١٥
👍2

هل تحتاج إلى إرسال البيانات عبر الشبكة؟ لقد افترضت أنك بحاجة فقط إلى الحزم الموجودة على الجهاز المحلي. سيؤدي استخدام udpsink host=0.0.0.0 port=5555 إلى بث الحزم في كل مكان على شبكتك. ربما ليس ما انت تريد...

يجب أن تكون قادرًا على قول host=127.0.0.1 بدلاً من ذلك لتقييد الحزم على الاسترجاع المحلي.

أظن أن المشكلة الحقيقية تعود إلى تكوين التوجيه الافتراضي. بشكل افتراضي ، في نظامك ، يتم توجيه الحزم الصادرة إلى واجهة مختلفة. من المحتمل وجود إصدارات مختلفة من عنصر gstreamer أو اختلافات في إعداد توجيه IP.

liamw9534 picture liamw9534 في ١١ مايو ٢٠١٥

من الحاوية ، كان علي استخدام 0.0.0.0 أو IP الخاص بالجهاز. لم يكن الإعداد الافتراضي يعمل حتى على جهاز / حاوية واحدة.

لكن نعم ، لا بد لي من استخدام الشبكة الآن لأنه من الممارسات الجيدة الاحتفاظ بـ ncmpcpp و mopidy في حاويات Docker منفصلة ، مما يعني أنهما على شبكات مختلفة. هذا جيد حقًا للسلامة والعزلة وما شابه ، لكنه يخلق بعض المتاعب:

يتصل عميل ncmpcpp بخادم MPD للمطالبة بتدفق الموسيقى ، وبعد هذه النقطة فقط يكون عنوان IP الخاص بـ ncmpcpp معروفًا ويجب بث حزمة UDP إلى IP الخاص به ؛ ولكن حاليًا IP غير مشفر في تكوين Mopidy.

ليس لدي حل الآن. أفكر في الحلول:

  • إنشاء FIFO في Mopidy ومشاركته مع ncmpcpp ، لكنني أخشى أن لا شيء سيؤدي إلى مسح FIFO وهذه مشكلة كبيرة. كما أن مشاركة الملفات ليست نظيفة مثل مآخذ الشبكة.
  • الخفي المحلي لمراقبة الاتصالات وإعادة توجيه حركة مرور UDP للعثور على عنوان IP للعميل ؛ الاختراق.
  • نفق UDP SSH ، لكن هذا معقد ، يضيف تشفيرًا عديم الفائدة ، ويضيف خفيًا آخر ... سيئًا!
  • النظر في التعليمات البرمجية لمعرفة ما إذا كان يمكن تعيين مضيف
  • أخبر Docker بمشاركة المضيف عبر --net=container:NAME_or_ID والذي يضيف معلمة أخرى للمستخدمين لكتابتها ، ولكن هذا من شأنه أن يبسط الكثير!

توجد حلول لهذه التبعية الدائرية. ما زلت أشعر وكأنه اختراق فظيع ولكن يجب أن يكون سهلاً بما يكفي ليستخدمه المستخدمون في النهاية. شكرًا liamw9534 للمساعدة بشكل خاص مع أوامر nc التي كنت أجنبيًا معها.

wernight picture wernight في ١٢ مايو ٢٠١٥

تعمل ميزة FIFO باستثناء أن There is no output named "my_fifo"! . يبدو أن الاسم يجب أن يتطابق مع الاسم الموجود في mdp.conf :

 audio_output {
        type            "fifo"
        name            "my_fifo"
        path            "/tmp/mpd.fifo"
        format           "44100:16:2"
}

قد أحاول مشاركة ملف FIFO إذا كنت أعرف كيفية إضافة هذا الإخراج الصوتي إلى Mopidy. يبدو أن للغثيان نفس المتطلبات.

لقد وجدت هذه الوثائق الخاصة بـ visualizer_output_name :

  • هناك حاجة إلى المعلمة أدناه لـ ncmpcpp لتحديد المخرجات التي توفر البيانات للمتخيل وبالتالي السماح بالمزامنة بين التصور والصوت حيث توجد حاليًا بعض المشكلات معها.
  • خرج fifo ، الذي يجب تعيين معلمة التنسيق الخاصة به على 44100: 16: 1 للتصور الأحادي أو 44100: 16: 2 لتصور الاستريو
wernight picture wernight في ١٢ مايو ٢٠١٥

لست متأكدًا مما تقصده بقولك "على شبكات مختلفة". إذا كنت ترغب في عزل حركة مرور الصوت إلى الجهاز المحلي ، فيجب عليك استخدام 127.0.0.1 مقابل udpsink . إذا اخترت 0.0.0.0 ، فسيتم توجيه الحزم باستخدام المسار الافتراضي الذي يعني على الأرجح إرسال حزم UDP عبر الشبكة ... بشكل عام ، سأقول أن هذه فكرة سيئة لأن حركة مرور الشبكة ستستهلك الكثير من النطاق الترددي ، أي 2 × 16 × 44100 = 1.41 ميجابت في الثانية.

من الناحية النظرية ، يجب أن يكون من الممكن تكوين nc بـ 0.0.0.0 بغض النظر عن واجهة الشبكة المستخدمة بواسطة udpsink . سيستمع هذا على جميع واجهات الشبكة. لا بأس بذلك طالما أنك لا تستخدم نفس رقم منفذ IP لخدمات أخرى على واجهات شبكة مختلفة.

liamw9534 picture liamw9534 في ١٢ مايو ٢٠١٥

لقد استخدمت اقتراحي الأخير ووضعتهما على نفس الشبكة. هذه الشبكات محلية على أي حال ، إنه مجرد فصل منطقي. يعمل هذا على بناء FIFO ، فقط ncmpcpp لا يريده (انظر إجابتي السابقة ، 2 أعلاه).

wernight picture wernight في ١٢ مايو ٢٠١٥

أي فكرة عن اسم القناة تلك؟ أو إذا كانت هناك طريقة أخرى لـ FIFO مثل mpd.conf ؟ لا يبدو أنه يعمل على الإطلاق بدون.

wernight picture wernight في ١٣ مايو ٢٠١٥

اعتقدت أنه تم استخدام mpd.conf لتكوين البرنامج الخفي MPD فقط. في هذه الحالة ، يجب أن يكون ذلك زائدًا عن الحاجة لأن mopidy هو البرنامج الخفي MPD ويقوم عامل الإرساء بإنشاء ملف FIFO. في هذه الحالة ، الشيء الوحيد الذي يجب أن يكون ضروريًا هو التأكد من مطابقة .ncmpcpp/config للعميل ، أليس كذلك؟

liamw9534 picture liamw9534 في ١٣ مايو ٢٠١٥

نوعا من. ما الذي تفعله بالضبط أنا لا أعرف. ولكن كما ترى ، يجب أن يتطابق audio_output { name "my_fifo" } visualizer_output_name = "my_fifo" مع audio_output { name "my_fifo" } . يعرض ncmpcpp حاليًا There is no output named "my_fifo" . وصف visualizer_output_name هو مجرد 5 مشاركات أعلاه. يبدو أنه في الواقع يتصل مباشرة بطريقة ما بالإخراج للمزامنة.

wernight picture wernight في ١٣ مايو ٢٠١٥

لا أستخدم أيًا من هذا ولكن يبدو لي أن visualizer_output_name يجب أن يتطابق مع أحد مخرجات MPD (البروتوكول ، وليس البرنامج) (أي شيء في mpc outputs ). لا يسمح Mopidy حاليًا بمخرجات قابلة للتكوين ولديه فقط خرج MPD واحد: "Mute".

ربما تريد إلغاء تعيين visualizer_output_name ، إذا أمكن.

kingosticks picture kingosticks في ١٣ مايو ٢٠١٥

حاول عدم وضعه. لا يوجد حتى الآن متخيل مرئي. أتساءل عن تنسيق الإخراج udpsink : يجب أن يكون 44100:16:2 لعمل المتخيلات ( ncmpcpp أو nausea ).

حاولت Mute فقط في حالة ، حصلت على تجربة مضحكة للغاية: لقد كتم الصوت فقط ، دون إظهار أي خطأ ولكن أيضًا بدون إظهار المتخيلات. أو بشكل أكثر دقة ، فقد عطل الناتج Mute .

wernight picture wernight في ١٣ مايو ٢٠١٥

أنا لا أتساءل أين يتم تنفيذ وظيفة FFT للمتخيل.
هل يتم إجراؤه عند إخراج FIFO أو عند الإدخال إلى FIFO؟ أنت
سيحتاج إلى التحقق من رمز عميل MPD لمعرفة كيفية تعامله مع بيانات FIFO.

liamw9534 picture liamw9534 في ١٣ مايو ٢٠١٥

هل هناك طريقة لدعم أي منهما ، للاختبار فقط ، حتى لو كان سينشئ عادةً ملفًا ضخمًا بشكل فظيع.

wernight picture wernight في ١٣ مايو ٢٠١٥

لست بحاجة إلى الدعم أيضًا. تحتاج إلى معرفة مكان FFT
من المفترض أن يتم ذلك ثم اختر الطريقة الصحيحة. إذا كان FFT هو
تم إجراؤه في المتخيل ، فسيكون مجرد إهدار كامل للجهد
تنفيذه مرة أخرى.

في 13 مايو 2015 الساعة 15:09 ، كتب Werner Beroux [email protected] :

هل هناك طريقة لدعم أي منهما ، فقط للاختبار ، حتى لو كان ذلك ممكنًا
عادة إنشاء ملف ضخم بشكل رهيب.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -101676033.

liamw9534 picture liamw9534 في ١٣ مايو ٢٠١٥

يتم إجراء FFT بواسطة المتخيل ويتطلب تنسيق الصوت المحدد في FIFO للعمل من أجل ذلك. المرجع: http://git.2f30.org/nausea/about/

wernight picture wernight في ١٣ مايو ٢٠١٥

جيد - إذًا لا يوجد سبب يمنعه من العمل! هل فعلت أ
مقارنة جنبًا إلى جنب مع نظام يقوم بتشغيل برنامج خفي MPD قياسي بامتداد
عميل ncmpcpp المحلي؟ ماذا يحدث إذا قمت بإعادة تسمية اسم ملف FIFO في كليهما
ملفات التكوين؟ هل ما زالت تعمل؟ مجرد محاولة لمعرفة ما إذا كان
المسار الثابت موجود في مكان ما ...

في 13 مايو 2015 الساعة 15:57 ، كتب Werner Beroux [email protected] :

يتم إجراء FFT بواسطة المتخيل ويتطلب تنسيق الصوت المحدد
في FIFO للعمل من أجل ذلك. المرجع: http://git.2f30.org/nausea/about/

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -101702624.

liamw9534 picture liamw9534 في ١٣ مايو ٢٠١٥

استند تعليقي إلى مصدر ncmpcpp .

يتم تعطيل إخراج Mopidy كتم الصوت افتراضيًا ، على سبيل المثال ، لا يتم كتم الصوت. سيأخذ ncmpcpp visualiser الإخراج الذي أعطيته له ، ويعطله (بدون تأثير) ثم يقوم بتمكينه ، وبالتالي كتم الصوت. يمكن القول أنه يجب عليهم تبديلها مرتين.

يعد الصوت بتنسيق خاطئ احتمالًا جيدًا. ليس لديك أي شيء في خط أنابيب gstreamer للتأكد من صحته على عكس adamcik الموجود في الكود أعلاه.

kingosticks picture kingosticks في ١٣ مايو ٢٠١٥

من الصعب أن نرى كيف يمكن أن يكون التنسيق مشكلة .... إنه موقع 16 بت
أعداد صحيحة. أسوأ ما يمكن أن يحدث هو أنك تقوم بتبديل قنوات L / R؟

في 13 مايو 2015 الساعة 16:33 ، كتب Nick Steel [email protected] :

استند تعليقي إلى مصدر ncmpcpp
http://git.musicpd.org/cgit/mirror/ncmpcpp.git/tree/src/visualizer.cpp.

يتم تعطيل إخراج Mopidy كتم الصوت افتراضيًا ، على سبيل المثال ، لا يتم كتم الصوت.
سيأخذ ncmpcpp المرئي الناتج الذي أعطيته له ، قم بتعطيله (لا
تأثير) ثم قم بتمكينه ، وبالتالي كتم الصوت. يمكن القول إنهم يجب عليهم ذلك
فقط قم بتبديله مرتين.

يعد الصوت بتنسيق خاطئ احتمالًا جيدًا. لديك
لا شيء في خط أنابيب gstreamer الخاص بك للتأكد من صحته على عكسadamcik
https://github.com/adamcik كان في الكود أعلاه.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -101716947.

liamw9534 picture liamw9534 في ١٣ مايو ٢٠١٥

وحتى إذا كان ترتيب البايت خاطئًا ، فقد تتوقع فقط FFT
الإخراج لتوليد استجابة تردد خاطئة ...... لكنك ما زلت ترى
شيئا ما.

في 13 مايو 2015 الساعة 16:37 ، كتب Liam Wickins [email protected] :

من الصعب أن نرى كيف يمكن أن يكون التنسيق مشكلة .... إنه موقع 16 بت
أعداد صحيحة. أسوأ ما يمكن أن يحدث هو أنك تقوم بتبديل قنوات L / R؟

في 13 مايو 2015 الساعة 16:33 ، كتب Nick Steel [email protected] :

استند تعليقي إلى مصدر ncmpcpp
http://git.musicpd.org/cgit/mirror/ncmpcpp.git/tree/src/visualizer.cpp.

يتم تعطيل إخراج Mopidy كتم الصوت افتراضيًا ، على سبيل المثال ، لا يتم كتم الصوت.
سيأخذ ncmpcpp المرئي الناتج الذي أعطيته له ، قم بتعطيله (لا
تأثير) ثم قم بتمكينه ، وبالتالي كتم الصوت. يمكن القول إنهم يجب عليهم ذلك
فقط قم بتبديله مرتين.

يعد الصوت بتنسيق خاطئ احتمالًا جيدًا. لديك
لا شيء في خط أنابيب gstreamer الخاص بك للتأكد من صحته على عكس
adamcik https://github.com/adamcik كان في الكود أعلاه.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/mopidy/mopidy/issues/775#issuecomment -101716947.

liamw9534 picture liamw9534 في ١٣ مايو ٢٠١٥

نعم صحيح ، لذا ربما يرجع السبب في ذلك إلى أن ترك إخراج Mopidy Mute ممكّنًا يعني أن udpsink لن يرسل أي بيانات.

kingosticks picture kingosticks في ١٣ مايو ٢٠١٥

يظهر cat /tmp/mdp.fifo (تم إنشاؤه من UDP على النحو الوارد أعلاه) بشكل صحيح تدفق البيانات المستمر.

لقد ألقيت نظرة على الكود المتخيل ncmpcpp:

  1. يفتح الملف كـ O_RDONLY | O_NONBLOCK
  2. يقرأ من أعلى نظرًا لأنه تم ضبطه للاستريو في تكوين mopidy الخاص بي ، يجب أن يكون 44100: 16: 2.

يمكن لأي شخص أيضًا المحاولة من فرعي (بعد تثبيت Docker):

git clone https://github.com/wernight/docker-mopidy.git
cd docker-mopidy
git checkout udpsink
docker build -t mopidy .
cd ..

git clone https://github.com/wernight/docker-ncmpcpp.git
cd docker-ncmpcpp
git checkout udpsink
docker build -t ncmpcpp .
cd ..

# Remember to enable PulseAudio over network 

docker run --name mopidy -d \
      -e PULSE_SERVER=tcp:$(hostname -i):4713 \
      -e PULSE_COOKIE_DATA=$(pax11publish -d | grep --color=never -Po '(?<=^Cookie: ).*') \
      mopidy
docker run --rm -it --link mopidy:mopidy ncmpcpp --host mopidy
wernight picture wernight في ١٨ مايو ٢٠١٥

اضطررت إلى قضاء بعض الوقت في الجدل حول netcat لأن -k لم ينجح معي ، ولكن هذا ما توصلت إليه لتشغيله تلقائيًا على مفاتيح الأغاني:

while :; do yes $'\n' | nc -lu 127.0.0.1 5555 > /tmp/mopidy.fifo; done

خيارات أخرى على النحو الوارد أعلاه في الأساس.

s-ol picture s-ol في ٢٨ ديسمبر ٢٠١٥

لم @ S0lll0swernight أداة netcat -k أيضا ليست العمل بالنسبة لي وكان لا بد من إعادة تشغيل بعد التغييرات أغنية. بينما يعمل الحل الخاص بك ، وجدت أن سكات تعمل بشكل أفضل:

while :; do socat -d -d -T 1 -u UDP4-LISTEN:5555 OPEN:/tmp/mopidy.fifo; done

SjRNMzU picture SjRNMzU في ٦ فبراير ٢٠١٦
❤3

لمستخدمي Arch linux:

للحصول على دعم nc مع دعم -k تحتاج إلى تثبيت حزمة openbsd-netcat ، لكنها لم تنجح أيضًا ، لذا حاول استخدام البرنامج النصي SjRNMzU - أنت بحاجة حزمة socat لتشغيلها.

johnhamelink picture johnhamelink في ٣ سبتمبر ٢٠١٦
❤1

johnhamelink (أفترض أنك تقوم بتشغيل Arch من تعليقك) هل واجهتك مشكلات مع socat ؟

tmb picture tmb في ٤ يونيو ٢٠١٧

@ theos-space لا أستطيع أن أقول أنني لاحظت ذلك بنفسي

johnhamelink picture johnhamelink في ٥ يونيو ٢٠١٧

أنا على Arch ولم أستطع تشغيله مع أي من nc (كلاهما gnu و openbsd ) أو socat . بالإضافة إلى ذلك ، لا يمكنني القراءة من gst-launch-1.0 ... udpsink port=5555 بـ nc -kluw 1 127.0.0.1 5555 ، لأنه لا يطبع أي شيء على الشاشة.

ranisalt picture ranisalt في ٦ يونيو ٢٠١٧
👍1

يمكن تأكيد أن هذا يعمل على debian buster (4.11.6-1) ، mopidy 2.1.0-1 ، أدوات gstreamer1.0 1.12.2-1 ، ncmpcpp 0.7.4-1 + b3 ، socat 1.7.3.2-1:

ابدأ socat في بدء تشغيل النظام:

open_mpd_fifo() {
    local fifo
    readonly fifo='/tmp/mpd.fifo'

    mkfifo "$fifo"
    while :; do socat -d -d -T 1 -u UDP4-LISTEN:5555 OPEN:"$fifo"; done
}

mopidy [صوت] conf (يجب تحديد مضيف الملاحظات لـ udpsink):

[audio]
output = tee name=t ! queue ! autoaudiosink t. ! queue ! udpsink host=127.0.0.1 port=5555
laur89 picture laur89 في ٢٧ أغسطس ٢٠١٧

ranisalt for Arch يجب عليك تجميع ncmpcpp مع دعم fifo تحقق هنا: https://bbs.archlinux.org/viewtopic.php؟id=99915

r1ft4469 picture r1ft4469 في ٣٠ سبتمبر ٢٠١٧

إليك إعداد Arch الذي أعمل به ، بعد قراءة بقية سلسلة الرسائل + المستندات + manpages + المدونات المتنوعة. أقوم بتشغيل Mopidy كخدمة نظام وأرسل الصوت إلى خدمة المستخدم PulseAudio عبر TCP. لقد قمت بتضمين بعض التعليقات التوضيحية الإضافية التي نأمل أن تساعد الأقل خبرة.

الحزم

كل هذه من مستودعات Arch الرسمية:

gstreamer 1.12.3-1
mopidy 2.1.0
ncmpcpp 0.8.1  # this had fifo support without any special compiling for me
openbsd-netcat 1.178_3-1  # gnu-netcat lacks the -k flag, as discussed above
pulseaudio 11.1

يثبت

تمكين خدمة نظام mopidy:

sudo systemctl enable mopidy.service

استبدل تكوين نظام mopidy برابط رمزي لتكوين المستخدم لسهولة التحرير (اختياري):

sudo ln -sf ~/.config/mopidy/mopidy.conf /etc/mopidy/mopidy.conf

قم بإنشاء ملف fifo:

mkfifo "/tmp/mpd.fifo"

Configs

في ~/.config/mopidy/mopidy.conf (أو /etc/mopidy/mopidy.conf إذا لم تقم بإنشاء الارتباط الرمزي): اطلب من mopidy إرسال الصوت إلى خادم pulseaudio يستمع على localhost وإلى حوض UDP في المضيف المحلي 

[audio]
output = tee name=t ! queue ! pulsesink server=127.0.0.1 t. ! queue ! udpsink host=127.0.0.1 port=5555

في ~/.ncmpcpp/config : أخبر ncmpcpp أين تجد ملف fifo الذي يحتاج للاستماع إليه ، وبعض الإعدادات المتنوعة الأخرى

visualizer_fifo_path = "/tmp/mpd.fifo"
visualizer_output_name = "my_fifo"
visualizer_sync_interval = "30"
visualizer_in_stereo = "yes"
visualizer_type = "spectrum"
visualizer_look = "+|"

في ~/.config/pulse/default.pa : أخبر pulseaudio بقبول الصوت عبر TCP من المضيف المحلي (من المحتمل أن يكون الإعداد موجودًا بالفعل ويمكن فقط أن يكون بدون تعليق)

load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1

في ~/.zshrc (يجب أن تعمل أيضًا في ~/.bashrc ): أنشئ وظيفة مجمعة "nplayer" للتعامل مع بدء وإيقاف netcat مع ncmpcpp :

nplayer () (nc -kluw 1 127.0.0.1 5555 > /tmp/mpd.fifo & trap "kill $!" EXIT; ncmpcpp)

ماذا يفعل هذا:

  • تحديد دالة مع غلاف فرعي يغلف محتوياته بالكامل
  • ابدأ عملية netcat في الخلفية للاستماع إلى البيانات الصوتية المرسلة إلى حوض UDP وإعادة توجيهها إلى FIFo الذي تم إنشاؤه مسبقًا. الأعلام:

    • -k استمر في الاستماع بعد اكتمال الاتصال الحالي

    • تمكين وضع الاستماع -l

    • -u تفعيل وضع UDP

    • انتهت مهلة -w NUM للاتصالات الخاملة بعد NUM ثانية (ثانية واحدة في هذه الحالة)

  • اضبط مصيدة الخروج لقتل عملية netcat عندما تنتهي عملية ncmpcpp وتتسبب في إنهاء المجموعة الفرعية للوظيفة
  • بدء عملية ncmpcpp في المقدمة
mosbasik picture mosbasik في ٢٧ نوفمبر ٢٠١٧
👍16 ❤1

أنا أركض mopidy على Manjaro (توزيعة القوس). كنت أواجه مشكلة في الحصول على أي ناتج من خلال socat أو netcat. تمكنت من مراقبة الحزم الواردة مع tcpdump على الرغم من:
sudo tcpdump -i lo -n udp port 5555 -XX

لقد استغرق الأمر مني وقتًا طويلاً ولم أكن لأجد المشكلة لولا
كانت المشكلة عدم وجود host=127.0.0.1 بعد udpsink ، فلماذا يعمل هذا مع أشخاص آخرين وليس أنا ، لا أعرف. ولكن إذا لم تحصل على أي ناتج فمن الممكن أن يكون هذا هو الحال. هؤلاء 2 عملوا بالنسبة لي:

[audio]
output = tee name=t ! queue ! autoaudiosink server=127.0.0.1 t. ! queue ! udpsink host=127.0.0.1 port=5555↪

أو

[audio]
output = tee name=t ! queue ! autoaudiosink  t. ! queue ! udpsink host=127.0.0.1 port=5555↪

في ملاحظة جانبية: لم أتمكن من الحصول على pulsesink للعمل لذلك اضطررت إلى تركه عند autoaudiosink ، وهو ما قمت بتعيينه من قبل أيضًا. ومع ذلك ، يبدو أن المتخيل بطيء حقًا لسبب ما ، لست متأكدًا مما إذا كان ذلك بسبب autoaudiosink يعمل بشكل مثالي بعد إعادة التشغيل .. لا يزال بطيئًا بعض الشيء. مع Pulselink استمر في الشكوى من المكونات الإضافية لـ gstreamer. حتى بعد (أفترض) قمت بتثبيت كل حزمة مكون إضافي لـ gst على مستودعات Arch الرسمية. لاحظ flump3dec و mad


الناتج mopidy deps

Executable: /usr/bin/mopidy
Platform: Linux-4.16.7-1-MANJARO-x86_64-with-glibc2.2.5
Python: CPython 2.7.15 from /usr/lib/python2.7
Mopidy: 2.2.1 from /usr/lib/python2.7/site-packages
  Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
  requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
    chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
    idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
    urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
  setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
  tornado>=4.4: 5.1.1 from /usr/lib/python2.7/site-packages
    futures: 3.2.0 from /usr/lib/python2.7/site-packages
    singledispatch: 3.4.0.3 from /usr/lib/python2.7/site-packages
      six: 1.11.0 from /usr/lib/python2.7/site-packages
    backports_abc>=0.4: 0.5 from /usr/lib/python2.7/site-packages
Mopidy-Iris: 3.4.9 from /usr/lib/python2.7/site-packages
  setuptools>=3.3: 40.5.0 from /usr/lib/python2.7/site-packages
  pylast>=1.6.0: 2.3.0 from /usr/lib/python2.7/site-packages
    six: 1.11.0 from /usr/lib/python2.7/site-packages
  Mopidy>=2.0: 2.2.1 from /usr/lib/python2.7/site-packages
    Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
    requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
      chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
      idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
      urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
    setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
    tornado>=4.4: 5.1.1 from /usr/lib/python2.7/site-packages
      futures: 3.2.0 from /usr/lib/python2.7/site-packages
      singledispatch: 3.4.0.3 from /usr/lib/python2.7/site-packages
        six: 1.11.0 from /usr/lib/python2.7/site-packages
      backports_abc>=0.4: 0.5 from /usr/lib/python2.7/site-packages
  Mopidy-Local-Images>=1.0: 1.0.0 from /usr/lib/python2.7/site-packages
    setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
    Mopidy>=1.1: 2.2.1 from /usr/lib/python2.7/site-packages
      Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
      requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
        chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
        idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
        urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
      setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
      tornado>=4.4: 5.1.1 from /usr/lib/python2.7/site-packages
        futures: 3.2.0 from /usr/lib/python2.7/site-packages
        singledispatch: 3.4.0.3 from /usr/lib/python2.7/site-packages
          six: 1.11.0 from /usr/lib/python2.7/site-packages
        backports_abc>=0.4: 0.5 from /usr/lib/python2.7/site-packages
    Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
    uritools>=1.0: 1.0.1 from /usr/lib/python2.7/site-packages
      ipaddress>=1.0.6: 1.0.22 from /usr/lib/python2.7/site-packages
      ipaddress>=1.0.6: 1.0.22 from /usr/lib/python2.7/site-packages
  ConfigObj>=5.0.6: 5.0.6 from /usr/lib/python2.7/site-packages
  raven>=6.1.0: 6.9.0 from /usr/lib/python2.7/site-packages
    contextlib2: 0.5.5 from /usr/lib/python2.7/site-packages
Mopidy-Local-Images: 1.0.0 from /usr/lib/python2.7/site-packages
  setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
  Mopidy>=1.1: 2.2.1 from /usr/lib/python2.7/site-packages
    Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
    requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
      chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
      idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
      urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
    setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
    tornado>=4.4: 5.1.1 from /usr/lib/python2.7/site-packages
      futures: 3.2.0 from /usr/lib/python2.7/site-packages
      singledispatch: 3.4.0.3 from /usr/lib/python2.7/site-packages
        six: 1.11.0 from /usr/lib/python2.7/site-packages
      backports_abc>=0.4: 0.5 from /usr/lib/python2.7/site-packages
  Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
  uritools>=1.0: 1.0.1 from /usr/lib/python2.7/site-packages
    ipaddress>=1.0.6: 1.0.22 from /usr/lib/python2.7/site-packages
    ipaddress>=1.0.6: 1.0.22 from /usr/lib/python2.7/site-packages
Mopidy-Spotify-Tunigo: 1.0.0 from /usr/lib/python2.7/site-packages
  Mopidy>=0.19.0: 2.2.1 from /usr/lib/python2.7/site-packages
    Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
    requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
      chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
      idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
      urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
    setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
    tornado>=4.4: 5.1.1 from /usr/lib/python2.7/site-packages
      futures: 3.2.0 from /usr/lib/python2.7/site-packages
      singledispatch: 3.4.0.3 from /usr/lib/python2.7/site-packages
        six: 1.11.0 from /usr/lib/python2.7/site-packages
      backports_abc>=0.4: 0.5 from /usr/lib/python2.7/site-packages
  Mopidy-Spotify>=1.2.0: 3.1.0 from /usr/lib/python2.7/site-packages
    Mopidy>=2.0: 2.2.1 from /usr/lib/python2.7/site-packages
      Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
      requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
        chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
        idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
        urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
      setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
      tornado>=4.4: 5.1.1 from /usr/lib/python2.7/site-packages
        futures: 3.2.0 from /usr/lib/python2.7/site-packages
        singledispatch: 3.4.0.3 from /usr/lib/python2.7/site-packages
          six: 1.11.0 from /usr/lib/python2.7/site-packages
        backports_abc>=0.4: 0.5 from /usr/lib/python2.7/site-packages
    Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
    pyspotify>=2.0.5: 2.0.5 from /usr/lib/python2.7/site-packages
      cffi>=1.0.0: 1.11.5 from /usr/lib/python2.7/site-packages
        pycparser: 2.19 from /usr/lib/python2.7/site-packages
    requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
      chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
      idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
      urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
    setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
  Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
  setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
  tunigo>=1.0.0: 1.0.0 from /usr/lib/python2.7/site-packages
    requests>=2.0.0: 2.20.1 from /usr/lib/python2.7/site-packages
      chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
      idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
      urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
    setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
Mopidy-SoundCloud: 2.1.0 from /usr/lib/python2.7/site-packages
  setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
  Mopidy>=1.0: 2.2.1 from /usr/lib/python2.7/site-packages
    Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
    requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
      chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
      idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
      urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
    setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
    tornado>=4.4: 5.1.1 from /usr/lib/python2.7/site-packages
      futures: 3.2.0 from /usr/lib/python2.7/site-packages
      singledispatch: 3.4.0.3 from /usr/lib/python2.7/site-packages
        six: 1.11.0 from /usr/lib/python2.7/site-packages
      backports_abc>=0.4: 0.5 from /usr/lib/python2.7/site-packages
  Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
  requests>=2.0.0: 2.20.1 from /usr/lib/python2.7/site-packages
    chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
    idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
    urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
Mopidy-Spotify: 3.1.0 from /usr/lib/python2.7/site-packages
  Mopidy>=2.0: 2.2.1 from /usr/lib/python2.7/site-packages
    Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
    requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
      chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
      idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
      urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
    setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
    tornado>=4.4: 5.1.1 from /usr/lib/python2.7/site-packages
      futures: 3.2.0 from /usr/lib/python2.7/site-packages
      singledispatch: 3.4.0.3 from /usr/lib/python2.7/site-packages
        six: 1.11.0 from /usr/lib/python2.7/site-packages
      backports_abc>=0.4: 0.5 from /usr/lib/python2.7/site-packages
  Pykka>=1.1: 1.2.1 from /usr/lib/python2.7/site-packages
  pyspotify>=2.0.5: 2.0.5 from /usr/lib/python2.7/site-packages
    cffi>=1.0.0: 1.11.5 from /usr/lib/python2.7/site-packages
      pycparser: 2.19 from /usr/lib/python2.7/site-packages
  requests>=2.0: 2.20.1 from /usr/lib/python2.7/site-packages
    chardet>=3.0.2: 3.0.4 from /usr/lib/python2.7/site-packages
    idna>=2.5: 2.7 from /usr/lib/python2.7/site-packages
    urllib3>=1.21.1: 1.24.1 from /usr/lib/python2.7/site-packages
  setuptools: 40.5.0 from /usr/lib/python2.7/site-packages
GStreamer: 1.14.4.0 from /usr/lib/python2.7/site-packages/gi
  Detailed information: 
    Python wrapper: python-gi 3.30.2
    Relevant elements:
      Found:
        uridecodebin
        souphttpsrc
        appsrc
        alsasink
        osssink
        oss4sink
        pulsesink
        id3demux
        id3v2mux
        lamemp3enc
        mpegaudioparse
        mpg123audiodec
        vorbisdec
        vorbisenc
        vorbisparse
        oggdemux
        oggmux
        oggparse
        flacdec
        flacparse
        shout2send
      Not found:
        flump3dec
        mad

ducklin5 picture ducklin5 في ١٤ ديسمبر ٢٠١٨
👍3

أواجه مشكلة في محاولة جعل udpsink يعمل مع Mopidy وجميع عملاء ncmpcpp البعيدين. تم إعداد Mopidy مع MacVLAN في بيئة عامل إرساء. أستطيع أن أرى المنفذ الموجود على الحاوية بنجاح.

nc -vz -u mopidy.lan 5555
found 0 associations
found 1 connections:
     1: flags=82<CONNECTED,PREFERRED>
    outif (null)
    src x.x.x.x port 50630
    dst x.x.x.x port 5555
    rank info not available

Connection to mopidy.lan port 5555 [udp/personal-agent] succeeded!

يستخدم Mopidy حاليًا الجزء التالي من التكوين:

[audio]
mixer = software
mixer_volume = 100
output = tee name=t ! queue ! lamemp3enc ! shout2send async=false mount=mopidy ip="mopidy.lan" port=8092 username="some username" password="some password" t. ! queue ! udpsink host=0.0.0.0 port=5555

أي أفكار حول كيفية استخدام netcat للحصول على البيانات الأولية بنجاح في mpd.fifo؟ لا يعمل استخدام ما يلي ، أعتقد أني أستخدم netcat بطريقة خاطئة. لم تقدم بعض الأبحاث أي إجابات ، لذلك آمل أن يوجهني شخص ما في الاتجاه الصحيح.

#!/bin/bash

mkfifo /tmp/mpd.fifo
while :; do yes $'\n' | nc -lu mopidy 5555 > /tmp/mpd.fifo; done

أحصل على الخطأ التالية:

nc: Can't assign requested address

أي أفكار حول كيف يمكنني تشغيل هذا؟

هتافات!

80scyborgninja picture 80scyborgninja في ١ مارس ٢٠١٩

لمعلوماتك لقد أضفت دعمًا لـ gstreamer udpsink إلى ncmpcpp حتى الآن يمكن استخدامه مباشرة بدون اختراق فيفو.

راجع https://github.com/ncmpcpp/ncmpcpp/commit/fb886f687014e22b2fe1477da855be5201063ea8 لمزيد من التفاصيل.

أدناه دعابة. هذا هو mopidy + mopidy-spotify + mopidy-mpd + ncmpcpp.

https://user-images.githubusercontent.com/387658/102549720-e41bf980-40bc-11eb-8127-70889011e52f.mp4

arybczak picture arybczak في ١٧ ديسمبر ٢٠٢٠
❤10 🎉6 👍6 👀2

تضمين التغريدة يجب عليك نشر هذا على https://discourse.mopidy.com/c/show-and-tell/9

jodal picture jodal في ١٩ ديسمبر ٢٠٢٠
👍2

adamcik ألا يعني هذا أن مشكلة الـ 7-yo هذه "مهملة" لصالح حل أفضل لمشكلة العالم الحقيقي التي أشعلتها (دعم التصورات في ncmpcpp)؟

pspeder picture pspeder في ١٢ فبراير ٢٠٢١

pspeder ، ماذا تقصد بالضبط؟ هل هناك مشكلة في استخدام https://github.com/mopidy/mopidy/issues/775#issuecomment -747725806؟

kingosticks picture kingosticks في ١٢ فبراير ٢٠٢١

kingosticks كان يقترح ببساطة إغلاق هذه المشكلة 🙂

pspeder picture pspeder في ١٣ فبراير ٢٠٢١

أنا أتفق مع ذلك.

kingosticks picture kingosticks في ١٣ فبراير ٢٠٢١
هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

flyingrub picture flyingrub  ·  15تعليقات
jodal picture jodal  ·  13تعليقات
ecoCuyo picture ecoCuyo  ·  3تعليقات
kingosticks picture kingosticks  ·  12تعليقات
voidmann picture voidmann  ·  11تعليقات