Hi, On Apr 17, 2011 8:10 AM, "Nick Holloway" <<a href="mailto:ourmeal@hotmail.com">ourmeal@hotmail.com</a>> wrote: > > > Hi, > > I'm very new to Pulseaudio (and linux generally), so apologies if my query is a bit muddled . > > I have spent the past few days successfully setting up Pulseaudio to relay bi-directional sound from my Debian machine with sound hardware to a "virtual" machine without sound hardware (Virtualbox), all on my LAN. > > I did this by installing Pulseaudio on both machines, then running padevchooser on the "virtual" machine and configuring the server, sink and source to point towards my Debian machine with sound hardware. All works perfectly, both playing and recording sound. > > Having achieved that I then replicated exactly the same setup, but this time from my local Debian machine to a hosted server on the Internet, over my cable broadband connection (10 Mb downstream, 512K upstream). The sound plays fine FROM the remote hosted server on my local Debian machine's speakers (via that fast 10 Mb connection) , but when I try to record TO the server (using my local machine's recording device relayed by Pulseaudio) then I hit a "latency" problem (via that much slower 512K upstream). In this scenario, if I open the recording device volume monitor on the remote server, it picks up a very small amount of audio initially, then the volume "bursts" after a short period, then slowly fails to zero, and then I receive an error message detailing the latency problem, and it crashes. > > Presumably this is related to bandwidth. > > My question is: Is there a way to configure Pulseaudio so that it perhaps compresses the stream from the local recording device *before* sending it over the Internet to the remote server? Might this get around the bandwidth/latency problem? Or perhaps there is another way of resolving this kind of problem? > > The default for the sampling rate on my local machine's recording device is 2 channel, 16 bit, 44100Hz... (I looked for a way to reduce that sample rate down as a possible solution in the first instance, but haven't yet worked out how to do that). I don't know if pulseaudio supports any kind of protocol compression these days, but traditionally it does not. And due to that, it is generally unsuitable for use over the public internet. Lossy compression such as mp3, and protocols such as RTP and Icecast, exist for this purpose. Even if both nodes are dedicated servers with symmetric 100mbps, your transport latency over the internet is too high for most uses of PA. I've heard about lots of interest in extending the PA protocol to support lossy, non-PCM formats, but I don't *think* that has been added quite yet. PA shouldn't have crashed for you though, so if you can get a backtrace from gdb with debugging symbols and provide steps to reproduce, I'm sure someone could triage why it happened. > > I'll provide any other information of the machines, configuration etc... if that will assist. > > Thanks for any help offered. > > Cheers, > > Nick > > > > > > > > _______________________________________________ > pulseaudio-discuss mailing list > <a href="mailto:pulseaudio-discuss@mail.0pointer.de">pulseaudio-discuss@mail.0pointer.de</a> > <a href="https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss">https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss</a> >