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

[Colin Guthrie]

'Twas brillig, and Maarten Bosmans at 22/01/11 10:11 did gyre and gimble:
> 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)

Very interesting. I wonder if it relates to the use or implementation of
the DONT_INHIBIT_AUTO_SUSPEND flag... looking at the pavucontrol code,
it seems it doesn't actually even pass
PA_STREAM_DONT_INHIBIT_AUTO_SUSPEND, so perhaps the solution is really
simple... just add that flag (although perhaps we'd have to deal with it
a bit more intelligently).

I actually wonder if this is the cause of the vumeters sometimes not
initialising properly at times... (I presume other people see this
occasionally? It's never quite bothered me enough to look into it properly!)

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]