search

openairplay / goplay2

Airplay 2 Receiver written in Go
Apache License 2.0
384 stars 20 forks source link

Multi-architecture, runnable Docker image #19

Closed dubo-dubon-duponey closed 3 years ago

dubo-dubon-duponey commented 3 years ago

Fix #18

Title says all.

This is a dockerfile allowing one to cross-compile goplay2 and produce a usable, runnable multi-architecture image.

The invocation command is a bit of a mouthful though that could be made simpler.

The main "limitation" right now is that it expects pulseaudio to be running on the host or in another docker image (I really did not feel like cramming in pulseaudio here).

I'm running this in docker on a RPI 3.

dubo-dubon-duponey commented 3 years ago

I also updated the README to reflect these changes.

Specifically, I removed the mention about having to change the mDNS implementation to be able to use it in a container - I don't think that's true. Brutella is just fine running inside a container - it's more a matter of using the right networking mode (mac/ip vlan or host), since the protocol needs to be able to broadcast.

AlbanSeurat commented 3 years ago

About mdns it is specially true on Mac where docker run in a Vm. Anyhow, there is no pulseaudio file on Mac…

I was about to remove the Docker part (see features/audio-sync branch) but I will leave yours instead.

I have trouble with pulseaudio, I might come back to alsa.

dubo-dubon-duponey commented 3 years ago

About mdns it is specially true on Mac where docker run in a Vm.

Yeah, I can look more into the docker4mac side if this is useful - networking has always been a bit dark magic over there - but personally, I would rather focus more on providing a brew formula on mac.

I have trouble with pulseaudio, I might come back to alsa.

+1 on this. As far as I'm concerned, Pulse does not provide value to my use cases (RPI as audio receivers) and just adds a useless layer of complexity on top of alsa.

I understand why some people may want Pulse on the desktop.

Is there a world where goplay would have a concept of backends (alsa, stdout, pipe, pulse) that the user could select?

As far as Docker is concerned, using alsa is trivial. You just need to mount the appropriate device and group. This shows a concrete example with a shairport-sync image: https://github.com/dubo-dubon-duponey/docker-airplay#run

dubo-dubon-duponey commented 3 years ago

@AlbanSeurat I was also thinking about this: if you want to publish a multi-architecture version of your image to Docker Hub (of ghcr), let me know and I can just add a shell script / makefile (or more documentation) with the right buildctl/buildkit invocation to do so.

AlbanSeurat commented 3 years ago

Is there a world where goplay would have a concept of backends (alsa, stdout, pipe, pulse) that the user could select?

I would rather have one backend perfectly working than allow to choose from several options. Audio-sync require timing precision and it is not simple to ensure that with one backend…

For now, pulseaudio with the go lib I am using prevent me to have good timing, I will look at that in September.

AlbanSeurat commented 3 years ago

@AlbanSeurat I was also thinking about this: if you want to publish a multi-architecture version of your image to Docker Hub (of ghcr), let me know and I can just add a shell script / makefile (or more documentation) with the right buildctl/buildkit invocation to do so.

I am not in a phase where I focus on publishing binaries but any helps is welcomed !

dubo-dubon-duponey commented 3 years ago

Is there a world where goplay would have a concept of backends (alsa, stdout, pipe, pulse) that the user could select?

I would rather have one backend perfectly working than allow to choose from several options. Audio-sync require timing precision and it is not simple to ensure that with one backend…

For now, pulseaudio with the go lib I am using prevent me to have good timing, I will look at that in September.

Makes perfect sense to me. And my vote is for just alsa indeed.