Hofmann, Laurent wrote: > > I think it is not only a nice feature but a key feature ! All modern > soundcards are able to do resampling in a better way than any other program, > without costing any CPU time. When I read a sound not resampled, pulseaudio > takes 20% CPU. If it must be resampled, even with the most basic algorithm, > pulsaudio takes more than 50% CPU (On my box). Well, ALSA, EsounD and even Microsoft Windows has had this for ages and I haven't seen the angry mobs with pitch forks quite yet. ;) The problem is that it cannot be done in a generic manner. It's an optimization that can be used when you have only one sound stream (or all the streams have the same rate). > > Even with a powerfull computer, resampling for nothing costs a lot. Let's > imagine a video game with nice sound FX and music at 48Khz whereas pulsaudio > is set up at 44Khz : depending on the priority, either the 3D image or the > sound will be hashed... > On a machine capable of modern games, the cost of resampling is negligible. The problem is on really low end stuff (embedded and things like it). > Since I can switch the sample rate in the conf and stop/start pulseaudio, > why this couldn't be done automatically ? Because you need to completely restart the device. It's not a trivial operation and it adds (unknown) latency. Again, it's doable but the complexity is high enough that it isn't a priority. It would be better to spend time optimizing the resampler. > >> If you have two sound devices representing front and back, then combining > them with the default channel map should work. >> In the longer run, the internal channel remapper should be taught how to > handle such cases. > > I Have not two sound devices, I have one with 6 channels... > Then the remapper needs to be fixed for things to behave as you want. > > Apart from that, seeing support of ESD in VLC (ESD is already supported in > unix version but not on the win32 version) or a native pulseaudio support in > VLC (both unix and win32) would be a good start. > Indeed. As usual, it's a question of having the time. Rgds -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20070403/5c16677b/attachment.pgp>