Re: [pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
On 2011-02-09 17:13, Maarten Bosmans wrote: 2011/1/26 Colin Guthriegm...@colin.guthr.ie: 'Twas brillig, and Maarten Bosmans at 26/01/11 10:49 did gyre and gimble: 2011/1/22 Colin Guthriegm...@colin.guthr.ie: 'Twas brillig, and Maarten Bosmans at 22/01/11 10:11 did gyre and gimble: 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!) Well, I was pleasantly surprised to see that pavucontrol from git master worked a lot better than the version packaged on Ubuntu (0.9.9). I'll use the newest version for a while and look out for little problems like you described. Yeah I've been meaning to push out a new release at some point (Lennart asked me a while back to handle that but I said I'd happily hack on it and let him do the releases, but I'll probably just take over the releases now :D) If you'd care to add my patch and make a release, I'll poke whoever is the maintainer of pavucontrol to include a newer version. That would probably be Sjoerd Simmons sjo...@debian.org. Now that Debian 6.0 is out I guess getting stuff in that way will be easier, hopefully. Btw, we all seem to be busy with our own stuff only, but we all would like others to test the stuff we do, so do you want to make a deal? :-) I'll test some of your patches (tell me which ones) if you test my pulse-mixer patches. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
2011/1/22 Colin Guthrie gm...@colin.guthr.ie: 'Twas brillig, and Maarten Bosmans at 22/01/11 10:11 did gyre and gimble: 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). Yup, adding that flag does the trick, see attached patch. Thanks for the pointer. I couldn't resist removing some duplicate code, I hope that's OK. If not, I'll prepare a patch which only adds the flag. 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!) Well, I was pleasantly surprised to see that pavucontrol from git master worked a lot better than the version packaged on Ubuntu (0.9.9). I'll use the newest version for a while and look out for little problems like you described. Col Maarten 0001-Add-DONT_INHIBIT_AUTO_SUSPEND-flag-to-monitor-stream.patch Description: Binary data ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
'Twas brillig, and Maarten Bosmans at 26/01/11 10:49 did gyre and gimble: 2011/1/22 Colin Guthrie gm...@colin.guthr.ie: 'Twas brillig, and Maarten Bosmans at 22/01/11 10:11 did gyre and gimble: 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). Yup, adding that flag does the trick, see attached patch. Thanks for the pointer. I couldn't resist removing some duplicate code, I hope that's OK. If not, I'll prepare a patch which only adds the flag. I've not looked properly yet, but I'm sure it's fine to de-dupe the code a bit. I've only really hacked on top and not really done any major re-factoring myself. 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!) Well, I was pleasantly surprised to see that pavucontrol from git master worked a lot better than the version packaged on Ubuntu (0.9.9). I'll use the newest version for a while and look out for little problems like you described. Yeah I've been meaning to push out a new release at some point (Lennart asked me a while back to handle that but I said I'd happily hack on it and let him do the releases, but I'll probably just take over the releases now :D) I spent some time adding support for automatic reconnection in the event the daemon disappears (as it's handy to debug and closing and reopening pavucontrol was always a pain!) and I also added a rename option allow for device.description to be edited (and with module-device-manager, this should be saved permanently). So a few nice features in there. But I'm surprised Ubuntu has 0.9.9... 0.9.10 has been out for ages... 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/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
Tanu Kaskinen tanuk at iki.fi writes: 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. So it seems that there is still room for my original suggestion and that's that the target of a stream should be able to request just peak samples of the stream rather than the whole stream. b. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
On Mon, 2011-01-24 at 17:02 +, Brian J. Murrell wrote: Tanu Kaskinen tanuk at iki.fi writes: 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. So it seems that there is still room for my original suggestion and that's that the target of a stream should be able to request just peak samples of the stream rather than the whole stream. Well, wasn't the supposed problem with transferring the whole stream that the data rate is needlessly high that way? If you use a sufficiently low sample rate, then the data rate is just fine. It just turned out that monitoring a tunnel sink can prevent the sink from suspending, which hopefully is fixable. The current peak detection mechanism smells a lot like a hack, but I think it actually works quite well, so I don't see the need for adding separate peak detection features to the pulseaudio protocol. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
2011/1/22 Colin Guthrie gm...@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) Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
2011/1/22 Maarten Bosmans mkbosm...@gmail.com: 2011/1/22 Colin Guthrie gm...@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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
'Twas brillig, and Maarten Bosmans at 22/01/11 10:11 did gyre and gimble: 2011/1/22 Maarten Bosmans mkbosm...@gmail.com: 2011/1/22 Colin Guthrie gm...@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/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
Maarten Bosmans mkbosmans at gmail.com writes: It looks like you have pavucontrol open on the laptop Yes, I do. (twice). Heh. You are right. As it connects to all the sources to display a vumeter, an audio stream from the desktop to the laptop is necessary. Ahhh. Of course. This is an interesting use case. It seems that it would be useful to have a sound level RPC in the PA protocol for things just like a vumeter. Surely it's much more efficient for the sending side to send sound level measure- ments than to send the actual audio stream for the receiving side to simply measure. It looks like also all the sinks and sources from a third computer jenny are forwarded to the laptop, further contributing to the bandwidth. Heh. Yup. It's an audio free-for-all here. :-) Do you still see excessive bandwidth usage with pavucontrol (and possibly other programs) closed? No, I don't. Things are wonderful now. :-) I would like to be able to keep pavucontrol open though, obviously without the vumeter penalty, hence my suggestion above. Many many thanx for your persistence in this Maarten. I really do appreciate it. Cheers, b. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
'Twas brillig, and Brian J. Murrell at 21/01/11 13:34 did gyre and gimble: Ahhh. Of course. This is an interesting use case. It seems that it would be useful to have a sound level RPC in the PA protocol for things just like a vumeter. Surely it's much more efficient for the sending side to send sound level measure- ments than to send the actual audio stream for the receiving side to simply measure. Actually there is. it's a flag when opening the sync for recording, that only does PEAK detect rather than a full read. This should be done in pavucontrol, but IIRC it's not done in pavumeter (because it's really old). Do you still see excessive bandwidth usage with pavucontrol (and possibly other programs) closed? No, I don't. Things are wonderful now. :-) I would like to be able to keep pavucontrol open though, obviously without the vumeter penalty, hence my suggestion above. I could probably add a command line switch that disables the vumeters easily enough. 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/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
'Twas brillig, and Colin Guthrie at 21/01/11 17:01 did gyre and gimble: Actually there is. it's a flag when opening the sync for recording, that only does PEAK detect rather than a full read. My goodness. You can tell it's the end of a busy week! sync whould be monitor source 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/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
'Twas brillig, and Brian J. Murrell at 21/01/11 17:10 did gyre and gimble: A GUI widget would be more useful I think so that one could twiddle it without having to drop to a command line. Yeah fair point. But even more useful still would be to just use the peak reading mode and/or make the peak reading mode not consume 2-3Mb/s of bandwidth. I'm pretty sure it is set in pavucontrol (it certainly is in the code I have here), but perhaps something is preventing it from working in an ideal way. Keep in mind it'll be active for all the vumeters... so that is every sink, source, sink input and source output all in all that's quite a lot of vumeter! 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/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
On Fri, 2011-01-21 at 17:13 +, Colin Guthrie wrote: 'Twas brillig, and Brian J. Murrell at 21/01/11 17:10 did gyre and gimble: A GUI widget would be more useful I think so that one could twiddle it without having to drop to a command line. Yeah fair point. But even more useful still would be to just use the peak reading mode and/or make the peak reading mode not consume 2-3Mb/s of bandwidth. I'm pretty sure it is set in pavucontrol (it certainly is in the code I have here), but perhaps something is preventing it from working in an ideal way. Keep in mind it'll be active for all the vumeters... so that is every sink, source, sink input and source output all in all that's quite a lot of vumeter! 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. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
'Twas brillig, and Tanu Kaskinen at 21/01/11 19:34 did gyre and gimble: On Fri, 2011-01-21 at 17:13 +, Colin Guthrie wrote: 'Twas brillig, and Brian J. Murrell at 21/01/11 17:10 did gyre and gimble: A GUI widget would be more useful I think so that one could twiddle it without having to drop to a command line. Yeah fair point. But even more useful still would be to just use the peak reading mode and/or make the peak reading mode not consume 2-3Mb/s of bandwidth. I'm pretty sure it is set in pavucontrol (it certainly is in the code I have here), but perhaps something is preventing it from working in an ideal way. Keep in mind it'll be active for all the vumeters... so that is every sink, source, sink input and source output all in all that's quite a lot of vumeter! 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. 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/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
I have a laptop (Ubuntu 10.10) who's sound I would like to go to my workstation (also Ubuntu 10.10) so on the laptop in paprefs I have selected Make discoverable PulseAudio network sound devices available locally enabled. The moment I select that, watching a packet dump (i.e. tcpdump) reveals a huge amount of traffic between the machines. By huge I mean a constant spew of hundreds of packets per second. This happens regardless of whether there is sound being played or not. Is this really normal and expected? Cheers, b. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
2011/1/20 Brian J. Murrell br...@interlinx.bc.ca: I have a laptop (Ubuntu 10.10) who's sound I would like to go to my workstation (also Ubuntu 10.10) so on the laptop in paprefs I have selected Make discoverable PulseAudio network sound devices available locally enabled. This alone should not result in a significant amount of packets, only a couple of mDNS requests. The moment I select that, watching a packet dump (i.e. tcpdump) reveals a huge amount of traffic between the machines. By huge I mean a constant spew of hundreds of packets per second. I assume you also loaded module-zeroconf-publish on the other machine. Looking at the traffic with wireshark reveals a bit of mDNS chat between the machines and a short burst of packets every 10 seconds. By no means a constant spew. The burst of packets every 10 seconds is probably due to module-tunnel requesting the latency of each sink. It's not a lot of traffic though. This happens regardless of whether there is sound being played or not. Hmm, this really sound more like you have activated rtp-send. Is this really normal and expected? Well, other than what I described above, I can't reproduce it here, so it would probably not be expected. Could you look with wireshark to see a bit more clear what the packets are? BTW, a wireshark protocol analyzer for the native pulse tcp protocol would be awesome. Cheers, b. Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
Maarten Bosmans mkbosmans at gmail.com writes: This alone should not result in a significant amount of packets, only a couple of mDNS requests. Indeed, that was my expectation also. I assume you also loaded module-zeroconf-publish on the other machine. No, in fact it appears to be commented out in the /etc/pulse/default.pa of the workstation (where I hear the audio from the laptop): #load-module module-zeroconf-publish Looking at the traffic with wireshark reveals a bit of mDNS chat between the machines and a short burst of packets every 10 seconds. By no means a constant spew. The burst of packets every 10 seconds is probably due to module-tunnel requesting the latency of each sink. It's not a lot of traffic though. No, I'd be quite happy with that level of traffic. Hmm, this really sound more like you have activated rtp-send. I don't think I have. How can I verify? Well, other than what I described above, I can't reproduce it here, so it would probably not be expected. Could you look with wireshark to see a bit more clear what the packets are? Well, of course since there isn't a decode module for the pulse protocol I can't really tell what they all are, but in terms of statistics a capture of just port 4713 between the two machines over a period of 205 seconds resulted in 234130 packets which was an avg. pps of 1141, with an avg. packet size of 568 bytes yielding an avg. bandwidth use of 5Mb/s! BTW, a wireshark protocol analyzer for the native pulse tcp protocol would be awesome. Way awesome. :-) b. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
2011/1/20 Brian J. Murrell br...@interlinx.bc.ca: Maarten Bosmans mkbosmans at gmail.com writes: I assume you also loaded module-zeroconf-publish on the other machine. No, in fact it appears to be commented out in the /etc/pulse/default.pa of the workstation (where I hear the audio from the laptop): #load-module module-zeroconf-publish Well, that's the static configuration script loaded at the start of the daemon. As noted in the comment just above that line, ticking the box in paprefs can also load this module. If you are able to stream audio over the network, obviously some modules facilitating that are loaded somehow. Can you provide the output of pactl list on both machines (clearly indicating which is which)? Be careful, the list only accepts messages 40kB. Most helpful would be the output when there is no music playing, but you are seeing high network utilisation. Hmm, this really sound more like you have activated rtp-send. I don't think I have. How can I verify? with pactl list, look for a loaded rtp module. Well, other than what I described above, I can't reproduce it here, so it would probably not be expected. Could you look with wireshark to see a bit more clear what the packets are? Well, of course since there isn't a decode module for the pulse protocol I can't really tell what they all are, but in terms of statistics a capture of just port 4713 between the two machines over a period of 205 seconds resulted in 234130 packets which was an avg. pps of 1141, with an avg. packet size of 568 bytes yielding an avg. bandwidth use of 5Mb/s! That most certainly looks like raw audio bitrate. Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Make discoverable PA network sound devices available locally results in huge network traffic
It looks like you have pavucontrol open on the laptop (twice). As it connects to all the sources to display a vumeter, an audio stream from the desktop to the laptop is necessary. It looks like also all the sinks and sources from a third computer jenny are forwarded to the laptop, further contributing to the bandwidth. Do you still see excessive bandwidth usage with pavucontrol (and possibly other programs) closed? Maarten 2011/1/20 Brian J. Murrell br...@interlinx.bc.ca: Maarten Bosmans mkbosmans at gmail.com writes: It looks like both are from your PC. You probably SSH'ed into your laptop with the -X option. Doh! Yes, I forgot that convenience of PA. Corrected. My apologies. FWIW, that 5Mb/s appears to be 2Mb/s in one direction and 3Mb/s in the other, not all in one direction. Cheers, b. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
