Thanks for making this a reality! Requests: Multiple instances, Audio output routing, Volume Control about goplay2 HOT 13 CLOSED

I actually already added vol control but I can't find my code. I have a machine I've reloaded several times the past month working on various projects and I'm guessing that is where I had my code changes. I added a --alsamixer option and also saved the volume state to the disk so it didn't default to -999 every time you reconnected. I will rewrite it and then put in a pull request. I will set it up so that it only does volume control if the --alsamixer option is supplied.

from goplay2.

@mattvv Here is the configuration for SPS : mikebrady/shairport-sync#1250

About pulseaudio, I have a quick look, it might be possible to implement it in the futur but If I do, I will remove alsa and keep only one output sink. I see the benefits to using the server rather than the low level api.

Let's see how the project goes.

from goplay2.

@mattvv I just update the repository with support to pulseaudio.
It will be "simpler" for me to manage audio sync with the pulseaudio as alsa as some limitation on how to handle async audio.
Anyhow, you can choose from the command line the pa sink you would like to use.

It is just the first step to have a proper audio sync anyway. Multiroom full support is not there yet.

from goplay2.

Multiple instances is difficult do to PTP needing to be on ports 319/320. The work around is virtualization we're each VM has its own IP.

AirPlay2 added what is called buffered audio. Basically it hands a URL to the speaker and it pulls the audio on its own. AirPlay2 also supports what is called real-time audio which is similar to AirPlay1 where the phone is the one streaming the audio to the speaker. Spotify is ridiculous and hasn't implemented buffered audio yet so it only supports real-time and goplay2 hasn't implemented realtime yet. Spotify has that voting system for requesting new features and buffered audio is one of the feature requests that was popular enough to get their attention. They claim they are looking into implementing it.

FYI, shairport-sync also supports AirPlay2 but supports buffered and realtime mode but has the same multi instance limitation due to PTP on port 319/320. I have multiple instances of it running on my Debian server using LXC containers and it's been working well for a few weeks of heavy use.

from goplay2.

Hello, thanks for your interest !

To add to @noelhibbard comments and answer specifically to your questions :

1 - There is a limitation indeed on PTP protocol (clock syncing needed for multi-room), one way to get around that would be to have a dedicated process to handle PTP and share the info to others goplay2 instance (via other means than PTP).
It would be less consuming that using several VMs to expose several goplay2 or shareport-sync for the matter.
Not sure goplay2 or shareport-sync will implement that any time soon.

2. On linux you can already specify the ALSA device you want to direct goplay2 (-alsa XXXX) as referred in the README.MD

3. I have not supported - yet - the volume as I do not need it in my setup (Raspi with analogique output). It is one of the things I would probably add in the future.

There the list of things I will be focusing on in the coming weeks/months :

P1 - Improve multi-room support (audio sync)
P2 - Play ALAC
P3 - Supports Spotify (RTP over UDP, type 96)
P4 - NIC hardware timestamp (linux)
P5 - Better alsa integration (linux)

The goal is to have only a subset of Airplay2 Features but having them working perfectly.
Therefore I won't necessary add for instance other output audio system or windows build support, etc...

As for spotify sake, it is on my list but I might improve sync to the expense of spotify support (so P3 could become P5 along the way ...)

from goplay2.

Thanks for the detailed responses. @noelhibbard I believe shairport-sync only supports airplay 1 which is why I'm excited about this project. I was able to get multiple instances of shairport-sync running via the port param. Main issue is that since it's only airplay 1, you can't connect to multiple instances from 1 device simultaneously i.e. if each instance is a 'zone', you can't play to multiple zones at the same time.

Glad to hear volume control is on the way.

It sounds like if I want to do output routing I'll have to use Linux instead of OSX?

from goplay2.

Thanks for the detailed responses. @noelhibbard I believe shairport-sync only supports airplay 1 which is why I'm excited about this project.

FYI, within the past few weeks, AirPlay2 support was added to the dev branch of shairport-sync. It also relies on PTP which has to run on 319/320 so to run multiple instances you need virtualization. I've been running it for a few weeks now and it's been stable. I have a Debian server with 4 instances in LXC containers running and it's been solid. The only issue I have is it doesn't sync well with a few Roku's I have but they don't even sync well with my Apple TV or goplay2 so I think it's the Rokus that are at fault.

Check the discussions section on the shairport-sync repo, I have some detailed instructions on setting up shairport-sync with AP2 in LXC containers. LXC containers are similar to dockers where it's not a full VM so they don't add much overhead. Once you get one container going and get shairport-sync running in it, all you do is create a copy of the container and it will have a new host name and IP. All you need to do then is change the shairport-sync config to your liking.

from goplay2.

Oh also, I already put in a pull request for volume control. So if you want volume you can wait for a merge or test my fork now.

from goplay2.

Ah awesome! I'll try out AP2 with shairport-sync + LXC. Are there specific things shairport-sync doesn't do well that this project aims to improve upon?

from goplay2.

I expect that audio sync to be very hard to do while supporting many output , so my goal is to have “pixel perfect” multiroom audio.

Only supporting alsa natively and adding hardware timestamp my hope is to have perfect sync.

Not sure it will worth it compare to sharepoint-sync but worth learning and trying ;)

oh and it worth mentioning that i start the projet before shaireport-sync release their development branch …

from goplay2.

@AlbanSeurat Awesome & makes sense. So basically you could have a bunch of rPi devices each running goplay2 and then from your sender device (iphone for example) select them and keep them in sync.

from goplay2.

Yeah goplay2 is streamlined where as shairport-sync has been around a long time and supports many different audio backends, multiple mDNS backends, ALAC, MQTT, convolution, ect, ect. I'm running Frigate (a surveillance NVR with object recognition) with 4 cameras, Homebridge, Zigbee2MQTT, Mosquito, 4 LXCs for shairport-sync and several other random services all on an i5 3rd gen with 8GB of RAM. I haven't had any sync issues other than with the Roku's. I ran the AP2 build of SPS on an RPi 3B and it was running about %20 so I wouldn't expect good sync with LXCs on something like that but on a more dedicated server it seems to be fine.

Before I went the LXC route I was planning to buy a bunch of RPi's. I speced out a way to mount them in a cluster. Got a 4 way USB splitter and a 10amp 5v power supply that I spliced into the 4 way USB spliter to power 4 RPi's. I found some cheap USB sound cards. Was going to cost right at $300 for 4 of them. I ordered 2 of them to start and then discovered LXCs. So now I have 2 RPi's waiting for a new task. Hahaha.

from goplay2.

@noelhibbard I'm interested in how you did the container setup, did you use docker-compose? I'm considering a similar approach as I have a bunch of older sonos devices that I wouldn't mind upgrading to airplay2. Of course I'd have to use pulseaudio-dlna sink's as outputs rather then alsa out, I feel like this repo would be lighter weight then sharepoint-sync but it doesn't have the pa support.

from goplay2.