3
I have a Docker that's running Alpine Linux. There is no hardware audio device at all.
I've managed to get pulseaudio running seemingly fine under the user.
I've been experimenting with trying to get PA to function as a virtual soundcard, with the intent of streaming the audio from the docker using ffmpeg. But so far without luck. And i've yet to come across examples that did not involve a machine that lacked audio hardware.
My main concern is getting VICE (x64 , The Commodore 64 emulator) to correctly utilize 'pulse' instead of 'dummy'. I've compiled VICE with '--with-pulse' , and 'pulse' does indeed show up in the settings menu.
Though, when i switch to 'pulse' instead of 'dummy' , x64 complains it can't initialize it and then disables it's own sound output.
pactl and pacmd seems to have no problem controlling the pulseaudio server though.
I've tried the following (and also module-pipe)
$ pacmd load-module module-null-sink sink_name=VirtSoundCard sink_properties=device.description=Virtual-Sound-Card
$ pacmd set-default-sink VirtSoundCard
Though without any luck so far. So hoping to hear from anyone who might know how it can be done, while i spend the rest of the night trying.
The 'default.pa' i'm using atm : https://bitbucket.org/duckhuntpr0/pyvice/src/pyvice_base/src/fs/home/pyvice/default.pa
Thanks for the tips. I'll try them out today.
As for why using a docker; Is so that i don't have to mess with my own system. And to make it easier for others to setup. The idea is to make a simple base solution for having an (python in my case) AI playing Commodore. Hence why it has telnet port to VICE's monitor,and vnc (for now) open. And ffmpeg would be useful for recording any "NEAT" evolution, to a remote machine is desire.
All of it hopefully making it to run for lengthy sessions without messing too much with the host- or the users personal computer. :) – DhP – 2018-07-14T15:48:17.727
"and they also get associated to real sound hardware" , I guess there is where the problem lies then. Cheers again – DhP – 2018-07-14T15:58:28.890
I'm not sure if I understand the second comment, but in case my phrasing was unclear: There are sources and sinks that get associated to real sound hardware (the modules have ALSA in their name), and there are sources and sinks that don't. I don't see any problem with this (except to get the terminology right). – dirkt – 2018-07-14T18:11:50.607
Yes you understood it correct i think. The modules i've been trying are even listed under Device Drivers , when there is no real device. Somehow i'd missed that. So i'm thinking using i.e the loopback network device combined with your tips of protocols (e.g using netcat) might be the best solution – DhP – 2018-07-14T19:44:17.080
The ALSA loopback device (if you mean that one) really sucks, I've tried it. And you'll incur a lot of delay. The loopback network device
lo
won't help you to get out of your container; after all, you want to reach your host to make it play audio. I'm not sure why you don't try to use any of the other solutions I've listed? But it's your problem... – dirkt – 2018-07-15T07:14:38.057No was refferring to the lo network device.
I think i've made some headway by using: `load-module module-null-sink sink_name=VirtSoundCard
load-module module-rtp-send source=VirtSoundCard.monitor loop=True inhibit_auto_suspend=always` , in default.pa . When using paplay (with a wav file) , i can now see trough pamon that something going trough it. Though pulseaudio seems to shut down after a while of idling, which then makes paplay and pamon no longer being able to connect. So i'm trying to figure out how to prevent that at the moment. – DhP – 2018-07-16T15:20:10.617
Though, by using the lo network , i think i can have ffmpeg take it from the lo network, as an input for ffmpeg, since it's then RTP . And do any (re)encoding trough ffmpeg. – DhP – 2018-07-16T15:29:05.087
I think problem solved :) Thanks again! https://imgur.com/a/pViCBPf
– DhP – 2018-07-16T16:38:30.387