'Twas brillig, and Tanu Kaskinen at 21/01/11 19:34 did gyre and gimble: > On Fri, 2011-01-21 at 17:13 +0000, 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/]
