How to use audio in bash on windows?

[GERMANOCARELLA]

Please use the following bug reporting template to help produce actionable and reproducible issues.

I tried to start espeak on my bash on windows.

I received some errors regarding pulseaudio and the fact that is not installed.
I googled and I found that pulseaudio doesn't work on bash on windows.
There is an other way can I try to use audio on my bash on windows?
I need audio in order to improve tts system such as festvox...
Maybe I must install pulseaudio and start it as a service everytime I start bash?

[fpqc]

@therealkenc has a modified version of pulseaudio in a ppa that reconfigures it to run without an unimplemented futex. Then you can pipe pulseaudio over tcp to the Windows version of pulse.

[saivert]

Would there be any chance of emulating an ALSA device for simple audio in/out?
Or maybe once the lxdrv is documented properly someone might implement it.
piping via pulseaudio to external server incurs some latency

[therealkenc]

User voice for this is here. [BTW to answer @Admin over there, the "developer scenario" is vscode-typewriter (duh).]

You could do a lxdrv for it, but then you still need to create a service to marshal the audio bytes to the Windows side. All you'd be doing is changing the transport mechanism, and you'll have a tough time convincing me using LxBus versus ipv4 over localhost would make any difference discernible to the senses.

Curious: Are you seeing any actual latency, or did you mostly make that up. I was mildly surprised myself when video being streamed over X11 and audio over PA (completely independent software and IP channels) were in sync.

[fpqc]

@therealkenc Well, maybe if Microsoft ever decides to redo the audio device framework on Windows (shudder), they can also add an audio interface via lxdrv. Otherwise I don't much see the point. Audio on Linux is always the biggest nightmare.

[fpqc]

This looks promising though: https://www.linuxmusicians.com/viewtopic.php?t=12818

From what I can gather, you can also redirect Jack2 over tcp/ip, and that can network with the Windows version of Jack, which communicates with ASIO drivers in Windows.

[therealkenc]

Yes, all of the higher quality packages like ffmpeg (and by extension everything that uses ffmpeg) support Jack. Funny article referenced in your link, quote: "100mbit/s is a good start". Jesus that's sad. Goes to my comment on latency above. I can remember doing primitive VOIP around 1995 with a 28.8kbps modem and tolerable latency. These days you can probably stream 5.1 channel studio quality audio with 30ms latency and less than 500kbps bandwidth if you do it right.

[saivert]

@therealkenc I'm not talking about audio sync. That is no the issue. I'm talking about the initial buffer delay from you hit play button in music player software till you can hear it. Also seeking incurs a bit of delay.
I tested this myself using Pulseaudio over TCP/IP to a local Win32 Pulseaudio instance and using Deadbeef player on Bash on Windows side. There may be configuration options to reduce the amount of buffering needed which I have not investigated (but will do now after typing up this).
I agree that you would only be changing the transport mechanism with a ALSA/OSS device implemented using LxDrv but it would still be preferable over TCP/IP and would require no special setup on the Bash on Windows side. Software that speaks ALSA would just work. That is as long as there has to be marshalling as you say. MS could of course implement it more tightly into the lxss system so it would basically hook directly into the Windows sound system. Basically I'm talking zero-copy of samples which currently you can't avoid.

[therealkenc]

Ahh okay thanks for clarifying. It sure isn't TCP/IP latency; that's 0ms over localhost (rounded to the nearest ms). You're right, something is buffering somewhere. Which isn't surprising, but it is weird because sync does matter. When you play a youtube video on firefox or mp4 video with VLC, your Win32 XcXsrv server doesn't know what you are seeing on screen is supposed to show up at the same time as your Win32 PA server sends audio to the sound card. It gets there when it gets there. Any initial audio buffering would screw up the sync. But, the sync isn't screwed.

I haven't actually used PA since I got it to work (because of lack of sensible use cases), but if I get a chance I'll take a look at 0xdeadbeef.

[fpqc]

@saivert Supposedly the tcp loopback from WSL to Windows is actually zero-copy, if I remember correctly.

@therealkenc I got jack-dbus installed and configured as a slave following that guide. I did make an strace, dunno if you want to glance at it.

stracejackcontrol.txt

I wonder if that's because I pointed it at 127.0.0.1 and/or wasn't running a server on Windows in master mode.

Getting jack_control to work was as easy as just doing export $(dbus-launch). I installed the jack2-dbus package from Arch.

[therealkenc]

Yeah it's zero copy which helps bandwidth, though it would still be 0ms latency even if it wasn't zero-copy on the bits.

Is that with strace -ff? Probably one of the AF_UNIX problems making Dbus unhappy, but that's just a guess.

[saivert]

I have been testing this on a Windows 10 VM and doing it over RDP so my experiments are invalid. I set it all up locally and no delay on start of playback. Improving RDP sound is next up for MS I guess...

[fpqc]

@therealkenc Yep, with -ff.

[therealkenc]

https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/14017329-sound-card-support

#237 for ALSA, #486 for Pulse