[opensuse-factory] Coming change: PulseAudio configuration enforcedby default

Just a heads up to some changes;

Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.4 (x86_64) Kernel
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) :


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”.