On 12/2/2010 4:32 AM, Carsten Munk wrote:
Hi,

In both N900 and MFLD hardware adaptations we are doing a horrible
hack to provide configuration / override the stock PulseAudio
configuration.

This is currently that we dump into /etc/skel/.pulse/ the daemon.conf
and default.pa files. In an image this will then be at image build
creation end up in /home/meego/.pulse/. PulseAudio picks it up when
started by uxlaunch at startup or falls back to

And this is naturally bad for reasons such as:

* It ruins upgrade-ability of these configurations (once /etc/skel has
been copied to a user's $HOME we can't touch it anymore)

* It's ugly.

* We should never ship something like this and ask device porters to
follow same pattern

So, I'd like to propose these changes:

* Establish hardware adaptation interface: provide package that contains:

/etc/pulse/default.pa
/etc/pulse/daemon.conf

and

Provides: pulseaudio-config

* In pulseaudio package, Add requires: pulseaudio-config

* Ship default /etc/pulse/default.pa and /etc/pulse/daemon.conf
currently in 'pulseaudio' package in pulseaudio-config-default

* Change existing hacks for N900 to ship /etc/pulse/default.pa and
/etc/pulse/daemon.conf and Provides: pulseaudio-config

If there's suggestions how we handle global detection of what device
we run and configure accordingily, especially inside PulseAudio
configuration. I'd like to know this as well - I don't think we can
rely on autodetect for something as complex as audio configuration
when modems etc are involved.

it's very simple actually

you make pulseaudio try

/etc/pulse/foo.conf.<machinename>
before it tries
/etc/pulse/foo.conf

<machinename> on x86 comes from sysfs: /sys/devices/virtual/dmi/id/board_name on ARM apparently it may come from cpuinfo or something (but that's a detail, if there is no board name you can do architecture name)

with that we can parallel ship a series of config files, and the right one gets picked at runtime automatically. but that also means that we can use the same image on multiple devices... something rather important on x86

_______________________________________________
MeeGo-packaging mailing list
[email protected]
http://lists.meego.com/listinfo/meego-packaging

Reply via email to