#930: Media players report 96khz, proc reports 44khz
  Reporter:  leafwiz  |       Owner:  lennart
      Type:  defect   |      Status:  closed 
 Milestone:           |   Component:  daemon 
Resolution:  invalid  |    Keywords:         
Changes (by coling):

  * status:  new => closed
  * resolution:  => invalid


 This is not a bug.

 PA will use a single sample rate for all audio played. If you wish this
 sample rate to be 96kHz you should adjust it in /etc/pulse/daemon.conf

 Changing sample rates on the fly is not feasible as it would result in an
 audible "pop" or "click" or "stutter" if multiple streams are playing
 (e.g. consider I'm playing a 8kHz sound effect and I start playing some
 96kHz audio, I'd have to change the native sample rate to 96Hz and then
 upsample the remainder of the 8kHz sound effect to 96kHz, mix the result
 and then play.

 Changing mid stream would be clearly audible.

 So an alternative strategy is to use the "first" sample rate. But using
 the same example as above, it means our nice 96kHz stream is downsampled
 to 8kHz.... certainly not what is desired.

 So at present, we have a "native" sample rate and everything is up/down
 mixed to suit that. If you set it to 96kHz but most of your audio sources
 are 44.1kHz, then you'll obviously waste a lot of CPU upsampling, so there
 is always a tradeoff.

 There is also an added complication, that ALSA cannot tell us what sample
 rates a card supports. We have to try them all at startup to "probe" the
 device. This obviously takes time and we already do a lot of probing at
 startup as it is :s

 We're experimenting with a "change on suspend" approach where we can
 switch sample rates (if supported) when the sink is suspended, but it
 could easily still lead to your card playing back the 96kHz file at
 44.1kHz depending on the circumstances of when you started playing. This
 non-deterministic behaviour feels a little ugly but it does still let
 people get full support under most circumstances.

 So I'm going to close this because it's not a bug (and I'm being
 particularly brutal with closing bug reports just now as we'll shortly
 move ot a new tracker and I'm not convinced we'll be migrating the
 existing bugs - so in short, don't take this personally!!!), and is in
 fact the (current) intended behaviour and patches already exist that will
 somewhat alleviate the problem.

 I hope you find this explanation sufficient for your needs.

Ticket URL: <http://pulseaudio.org/ticket/930#comment:1>
PulseAudio <http://pulseaudio.org/>
The PulseAudio Sound Server
pulseaudio-tickets mailing list

Reply via email to