[pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic

[Maarten Bosmans]

2011/1/22 Maarten Bosmans <mkbosmans at gmail.com>:
> 2011/1/22 Colin Guthrie <gmane at colin.guthr.ie>:
>> 'Twas brillig, and Tanu Kaskinen at 21/01/11 19:34 did gyre and gimble:
>>> I had a look at some point at the peak detection resampler... I think
>>> the peak detection flag that you mentioned earlier doesn't do anything
>>> else than force the resampler of the source output to be the peak
>>> detection resampler. The peak detection resampler is almost identical to
>>> the trivial resampler - the main difference is that it applies abs() to
>>> all samples, so the receiving end doesn't have to do that. Therefore,
>>> the data rate is equal to normal streams. Maybe pavucontrol could use
>>> some ridiculously low sample rate for the vumeter streams? I don't know
>>> what it uses currently - does it use the source sample rate or what.
>>
>> Yeah after sending my previous mail I actually had a look same as you
>> and came to much the same conclusion.
>>
>> I didn't look at the sample rates but I'll certainly have a look at
>> setting it to e.g. 8kHz Mono if it's not already the case.
>
> pavucontrol uses the peak resamples in combination with a 25 Hz sample
> rate for the stream.
>
> The problem here is that when used on a tunnel-sink, the full bitrate
> is send over the network and the resampling is is only done on the
> computer with the virtual end of the tunnel running pavucontrol. A
> good enhancement would be to have the tunnel only stream audio over
> the network with the rate of the highest connect stream (I'm not sure
> if this would also be good in the general case, but at least when
> there is only a vumeter stream this would be good)

I experimented a bit more with a manually set up module-tunnel sink.
The tunnel is from the client (tunnel sink) to the server (real sink).

In my previous mail I was assuming that the vumeter of pavucontrol (on
the client) would monitor the audio from the real sink on the server.
But apparantly it monitors the tunnel sink on the client. That's OK,
but makes it even more misterious why a full audio stream is sent over
the network.

It turns out that (without pavucontrol loaded) starting an audio
stream on the client on the tunnel sink, makes the audio stream over
the network and stopping the program that is playing the music stop
the network usage again. So far so good, nothing unexpected. When
pavucontrol is opened, there is still no network usage. After playing
audio and then stopping the playback, the network usage does not stop,
however, until alsa pavucontrol is closed.

So it seems that the source ouput of pavucontrol on the tunnel sink
monitor keeps the sink from suspending. (but only when the sink had
been running before, so the transition running -> idle is prevented)

Maarten