Re: [pulseaudio-tickets] [PulseAudio] #930: Media players report 96khz, proc reports 44khz
#930: Media players report 96khz, proc reports 44khz --+- Reporter: leafwiz | Owner: lennart Type: defect | Status: closed Milestone: | Component: daemon Resolution: invalid |Keywords: bitperfect,24bit,audiophile,resample,resampling --+- Changes (by ronalde): * keywords: = bitperfect,24bit,audiophile,resample,resampling Comment: I hope you find this explanation sufficient for your needs. Actually, having this explanation only in this bug and not in an obvious place like the wiki/FAQ draws a lot of (undeserved) negative attention and confusion with audio enthusiasts (and at the same time are not so interested in Linux knwowledge), like #293. I would advise to dedicate a special section in the documentation to this design choice and offer some advise on alternatives. For now maybe this link will help: [http://www.computeraudiophile.com/content/Bit-perfect-audio- Linux-882-and-1764-now-possible Computer Audiophile - Bit-perfect audio in Linux at 88.2 and 176.4 now possible] -- Ticket URL: http://pulseaudio.org/ticket/930#comment:2 PulseAudio http://pulseaudio.org/ The PulseAudio Sound Server ___ pulseaudio-tickets mailing list pulseaudio-tickets@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-tickets
Re: [pulseaudio-tickets] [PulseAudio] #930: Media players report 96khz, proc reports 44khz
#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 Comment: 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 (default-sample-rate). 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 pulseaudio-tickets@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-tickets
