search

liamw9534 / mopidy-pulseaudio

Mopidy extension for PulseAudio server management
Apache License 2.0
6 stars 2 forks source link

Could not find any downloads ... #1

Open sunni2002 opened 9 years ago

sunni2002 commented 9 years ago

Hi,

I tried to install mopidy-pulseaudio with sudo pip install Mopidy-PulseAudio. But there is no file found.

Downloading/unpacking Mopidy-PulseAudio Could not find any downloads that satisfy the requirement Mopidy-PulseAudio Cleaning up... No distributions at all found for Mopidy-PulseAudio

liamw9534 commented 9 years ago

This extension is not released outside GitHub (see README) because it depends on upstream changes to Mopidy that are unreleased. I have no timescale for the upstream changes, I made a pull request some months ago but it is yet to be reviewed.

If you have an urgent need to use this then let me know and I can try to expedite the Mopidy pull request with the repository owners (jodal and adamcik).

sunni2002 commented 9 years ago

Yes, have seen it in the readme but i thought i installed it 2 weeks ago on another pc. What ever ... I have this problem with mopidy and pulseaudio: https://discuss.mopidy.com/t/mopidy-pulseaudio-to-raspberrypi-with-module-tunnel-sink/434 Could these upstream changes solve my problems?

One more question. Is it possible to configure more then one audio-output in mopidy? I know with mpd its possible ...

Thanks for your fast responding!

Greetings sunni2002

Am 05.01.2015 um 11:33 schrieb Liam Wickins:

This extension is not released outside GitHub (see README) because it depends on upstream changes to Mopidy that are unreleased. I have no timescale for the upstream changes, I made a pull request some months ago but it is yet to be reviewed.

If you have an urgent need to use this then let me know and I can try to expedite the Mopidy pull request with the repository owners (jodal and adamcik).

— Reply to this email directly or view it on GitHub https://github.com/liamw9534/mopidy-pulseaudio/issues/1#issuecomment-68691271.

liamw9534 commented 9 years ago

My experience of multiple sinks with PulseAudio has been very mixed. Combining sinks works fine provided you don't have them dynamically added/removed, this does not work reliably in my experience. In fact, connecting the same source to multiple sinks works more reliably, for adding and removing dynamically, but you lose synchronization over time and audio buffers start to get too large and crash the application.

These problems are nothing to do with Mopidy. They are problems with PulseAudio.

I also find that the GStreamer sink support for PulseAudio is imperfect and not stable, especially if a stream contains seeking operations in async mode. The stream never recovers. Again this is not a Mopidy bug but rather an issue with the GStreamer sink adapter into PulseAudio.

The only way to really solve these problems is to get to their root cause in PulseAudio which would take a lot of effort, so I pretty much abandoned using PulseAudio altogether on my own project and looked instead at creating an alternative approach.

Part of the upstream changes I mentioned is to implement a GStreamer "Tee" element which allows audio outputs to be added and removed dynamically. It works rather well for ALSA audio sinks and you can add multiple ALSA sinks to the tee.

As part of the upstream changes, the "tee" component is invoked by setting audio-output, in the Mopidy configuration, to an empty string. Then there is a new class added called AudioOuput which can be called from Audio in order to add or remove an audio sinks in your extension class. You can find a few examples of audio sinks that are using this API here:

In particular, look at the files called sink.py which create a GstBin that contains what is needed to allow dynamic connection into the Mopidy AudioOutput class.

Note that the main role of mopidy-alsa is to enumerate and name all available ALSA devices such that they can be listed and added/removed via the HTTP interface. For example, you could run the following command over the websocket:

mopidy.alsa.get_devices()

to get a list of ALSA device names. And then:

mopidy.alsa.connect(<device name>)

Which will add that audio sink to the tee. Thus, anything output by Mopidy will then be heard on your audio sink.

There is also the autoconnect property. If this is enabled than all ALSA output devices are automatically added to the tee during start-up. So you don't need to send an HTTP command in that case.

sunni2002 commented 9 years ago

Hi again ,

Thank you for your detailed reply. My goal with mopidy is to build a simultaneous multi-room-system. 1 Mopidy-Server any many Clients (Raspberrys). If I understood you correctly for this goal the combination mopidy and pulseaudio is less suitable. So I think it would be better to wait for the upstream changes.

Sorry but my experience with commands over websocket are not available. Is it possible to add more then one sink with the current version of mopidy ? I have no idea how the mopidy.conf could be look like. Or is it currently only possible via the websocket commands?

The module mopidy-alsa is also not yet available. Is that correct?

Am 05.01.2015 um 15:16 schrieb Liam Wickins:

My experience of multiple sinks with PulseAudio has been very mixed. Combining sinks works fine provided you don't have them dynamically added/removed, this does not work reliably in my experience. In fact, connecting the same source to multiple sinks works more reliably, for adding and removing dynamically, but you lose synchronization over time and audio buffers start to get too large and crash the application.

These problems are nothing to do with Mopidy. They are problems with PulseAudio.

I also find that the GStreamer sink support for PulseAudio is imperfect and not stable, especially if a stream contains seeking operations in async mode. The stream never recovers. Again this is not a Mopidy bug but rather an issue with the GStreamer sink adapter into PulseAudio.

The only way to really solve these problems is to get to their root cause in PulseAudio which would take a lot of effort, so I pretty much abandoned using PulseAudio altogether on my own project and looked instead at creating an alternative approach.

Part of the upstream changes I mentioned is to implement a GStreamer "Tee" element which allows audio outputs to be added and removed dynamically. It works rather well for ALSA audio sinks and you can add multiple ALSA sinks to the tee.

As part of the upstream changes, the "tee" component is invoked by setting |audio-output|, in the Mopidy configuration, to an empty string. Then there is a new class added called |AudioOuput| which can be called from |Audio| in order to add or remove an audio sinks in your extension class. You can find a few examples of audio sinks that are using this API here:

In particular, look at the files called |sink.py| which create a GstBin that contains what is needed to allow dynamic connection into the Mopidy |AudioOutput| class.

Note that the main role of |mopidy-alsa| is to enumerate and name all available ALSA devices such that they can be listed and added/removed via the HTTP interface. For example, you could run the following command over the websocket:

mopidy.alsa.get_devices()

to get a list of ALSA device names. And then:

mopidy.alsa.connect()

Which will add that audio sink to the tee. Thus, anything output by Mopidy will then be heard on your audio sink.

There is also the |autoconnect| property. If this is enabled than all ALSA output devices are automatically added to the tee during start-up. So you don't need to send an HTTP command in that case.

— Reply to this email directly or view it on GitHub https://github.com/liamw9534/mopidy-pulseaudio/issues/1#issuecomment-68712780.

liamw9534 commented 9 years ago

Your project goals are similar to my own. I decided to use RTP from any Mopidy instance playing and encode the audio as FLAC over TCP/RTP to any other subscriber instance.

To accomplish your goals is not something that Mopidy can do out of the box which is why I worked on the upstream changes and also added Mopidy-RTP, for example.

Feel free to take a look at the repos in my GitHub account but it will require some customizations to meet your own requirements.

liamw9534 commented 9 years ago

Also, to answer an earlier question, the audio-output property can be set to any valid GStreamer pipeline text string that takes a single audio input. For example, you could send the audio output to both a local ALSA sink and a UDP multicast group IP address:

output = tee name=t ! queue ! alsasink device=hw:1 t. ! queue ! udpsink host=224.0.0.1 port=5050

Your listening devices can then join 224.0.0.1 in order to receive the UDP packets containing the audio data.