Hi
Just a heads up to some changes;
http://lists.opensuse.org/opensuse-factory/2011-07/msg00356.html
–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.4 (x86_64) Kernel 2.6.37.6-0.5-desktop
up 12 days 10:45, 4 users, load average: 0.29, 0.29, 0.24
GPU GeForce 8600 GTS Silent - Driver Version: 270.41.19
I’m struggling a bit with the technical sense of that, but from what I can read, it will ensure a more uniform application/installation of pulse audio packages, and yet will still be possible for those who want to disable pulse audio to do so.
I’m hoping they make things a bit more clear in the release submission that will be included on this for openSUSE-12.1.
There are also OTHER changes coming with audio (not pulse), but in this OTHER case with wrt the application ‘wine’, and a lot of wine being re-written with a view toward windows7 apps. From Phoronix: [Phoronix] Wine 1.3.25 Presents Rewritten Audio Support](http://www.phoronix.com/scan.php?page=news_item&px=OTY5OA)
and from WineHQ - Wine Announcement
The Wine development release 1.3.25 is now available.
What’s new in this release (see below for details):
- Rewrite of the audio support, using the Win7 architecture
.- Old-style sound drivers for Jack, NAS and ESD are removed.
- Graphics driver architecture changes for the DIB engine.
- Improved handling of the shell recycle bin.
- Better joystick support in DirectInput.
- Initial stub for VBScript support.
- Various bug fixes.
Currently factory on openSUSE has the older 1.3.24-1-1, so its something I am watching to see if it appears in Tumbleweed or in Factory (and then openSUSE-12.1 Milestone-TBD).
I note version 1.3.25 IS in the emulator/wine repository (for example for openSUSE-11.4) :
http://download.opensuse.org/repositories/Emulators:/Wine/openSUSE_11.4/
Personally i never used PulseAudio on openSUSE because ALSA does things pretty good with no struggle. Is nice to hear that the user can make a choice between having or not having PulseAudio enabled.
Well PA did cause some pain on introduction, but now I’m seeing the fruits, with Kmix offering application specific volume controls which I find useful enough. They’re actually talking about this kind of Global config variable being a less desirable option, to looking whether a session is under PA or not. That way you could run applictions that benefit from direct ALSA access at same time as others that play well with a sound daemon that tries to save power and reduce system interrupts.
A knock on benefit is with upstreams concentrating on the PA “safe” ALSA calls, there ought in long term be reliability benefits, due to a less sprawling & complicated API. Focussing applications will mean code paths are better tested and application developers can follow “patterns”.