[pulseaudio-discuss] Does pulseaudio resample when source and sink sample rate / bits are identical?

[Colin Guthrie]

Hi Josh,

'Twas brillig, and Joshua Redstone at 16/07/11 18:50 did gyre and gimble:
> I'm running pulseaudio 0.9.22-24-g67d18 on Ubuntu 11.04, with a source
> at  "s16le 2ch 44100Hz" and a USB card that is configured the same way.
>  I see CPU usage at 25% - I would have thought that if the source/sink
> sample rates are identical and there is nothing else going on in the
> system, that pulseaudio would have no sample conversion work to do.  
>  Is there a setting to get more info on what it's doing?  I've tried
> 'pulseaudio -vv' and I see:

...sniped...

>     D: alsa-util.c:   rate         : 44100
>     D: alsa-util.c:   exact rate   : 44100 (44100/1)
> 
>     and later on, when I play a stream:
> 
>     I: sink-input.c: Created input 0 "ALSA Playback" on
>     alsa_output.usb-Burr-Brown_from_TI_USB_Audio_CODEC-00-default.analog-stereo
>     with sample spec s16le 2ch 44100Hz and channel map
>     front-left,front-right
>     I: sink-input.c:     media.name <http://media.name> = "ALSA Playback"
>     I: sink-input.c:     application.name <http://application.name> =
>     "ALSA plug-in [chrome]"
>     I: sink-input.c:     native-protocol.peer = "TCP/IP client from
>     192.168.0.200:46969 <http://192.168.0.200:46969>"
> 
> It seems like they match up exactly, or am I missing something?

This is interesting.....

The rates match up directly but it seems you are using TCP for
communications. This means that the client application (Chrome in this
case) is talking over a network socket to the daemon.

This method is inefficient if you don't *have* to use it like this.

In a typical setup PA client and server will both be run by the same
user. When this happens, the client can talk to the server via a local
domain socket which is more efficient. But more importantly than TCP vs.
local domain, one of the key things the latter enables is SHM data
transfer. Rather than copying audio data over the "wire" to the server,
SHM, allows the client to just share it's memory space with the server
allowing for lower overhead.

I suspect you are using padevchooser which is basically cocking this all
up. This is one of the many reasons we deprecated padevchooser many
years ago and do not recommend it's usage.

I still wouldn't expect such high CPU usage rates, so perhaps PA is
waking up more than it needs to to service your USB speakers still, but
getting a proper connection working is a good first step all the same.

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/]