On Fri, May 23, 2008 at 12:00:26PM +0200, Rui Pereira wrote: > So, another idea is using pipe-sinks. In theory, I could set up N different > pipe-sinks for N running clients and move each stream to a separate pipe. > Then, since FFMPEG can get its input from a pipe, I could have N instances > of FFMPEG running and encoding in real-time. > > But here's my problem - when reading the pipe that PA creates, I get an > enormous data rate out of it. I configure it for 22050Hz, s16le and 2 > channels, so I expect around 705kb/s.. > Even without anything playing, it seems that the output is just flooding > with zeros. To do a quick test, if I "cat pipname > grabbed" for a couple of > seconds, the file reaches 200, 300 MB easily. So - my guess is that > pipe-sink module seems to be outputting data as fast as it can, even if it > is just 0s. > > Is is this case? Is it on purpose? Can someone explain what's going on? (or > perhaps have better suggestions on how to achieve the same goal)? I don't know how exactly the pipe sink is supposed to work, so I'll skip to the last question. One solution would be using null sinks instead of pipes, and recording from their monitor sources, like this: parec -d null_sink1.monitor | encoder1 parec -d null_sink2.monitor | encoder2 etc... If you record while nothing is played, zeros are generated just like with the pipe sink too, but at least the timing is sensible. See parec --help for available options and the default values for the stream format. -- Tanu Kaskinen
