On Fri, 2010-04-23 at 13:36 +0200, Rafal Wojtczuk wrote: > Hello, > On Apr 5, Lennart wrote (about native protocol): > > Note that the protocol is kinda complex, both because it grew > > historically and because some parts have to be complex. i.e. the > > timing/flow control logic is non-trivial. Reimplementing that won't be > > fun. > > > > tbh I don't think the native protocol while it works quite well these > > days is something that deserves to be reimplemented by other projects. > > The problem is that for some tasks the complexity of the native protocol is > prohibitive. Consider the following scenario (that I am trying to solve > now): > There are two [virtual btw] machines, VM_USER and VM_HOST. We want to allow > users in VM_USER to play sound on the soundcard attached to VM_HOST. So, the > obvious method is to run pulseaudio daemon in VM_HOST, and prepare client.conf > in VM_USER so that it connects pa clients to VM_HOST over the network. However, > VM_HOST does not want to trust VM_USER more than necessary. VM_HOST does not > want to give VM_USER full access to the native protocol capabilities (like > PA_COMMAND_LOAD_MODULE), nor to give it a chance to exploit a potential bug > (logic one, or buffer overflow) in this 150K C-code protocol. How about getting a cheap or free used computer running pulseaudio that you hook the speakers to? Then use that via TCP from VM_USER. That way you don't need to run pulseaudio on a top security machine. -- Tanu
