How can i can create a virtual pulseaudio soundcard on Linux with no audio hardware?

Question

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

Solution

Pulseaudio can create various sinks (what you call "virtual soundcards", but sinks are for output, sources are for input, and they also get associated to real sound hardware).

Have a look at the module list which includes the sinks, and syntax examples. You have the choice between using RTP/SDP, ROAP.

You can also access a pulseaudio server on the host via the native procotol, in that case you don't need to run a pulseaudio server in the docker client.

So far there was no need to use ffmpeg. If you really want to use ffmpeg, you can also create a null sink, and connect its monitor source up to ffmpeg. That would come closest to your idea of a "virtual soundcard", but it's also the least efficient alternative.

Finally, I don't really understand why you have to run VICE (an emulator) inside a docker image - as it's already an emulator, you can just run it on the host; there's no danger of the emulated C64 program doing something bad.

Comments

[DhP]

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]

"and they also get associated to real sound hardware" , I guess there is where the problem lies then. Cheers again

[dirkt]

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).

[DhP]

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

[dirkt]

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...

[DhP]

No 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]

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]

I think problem solved :) Thanks again! imgur.com/a/pViCBPf

[That Brazilian Guy]

@dhp can you share you working solution, please? I've been looking for the same thing, without much success.