On Thu, Jul 15, 2010 at 5:35 PM, Colin Guthrie <gm...@colin.guthr.ie> wrote:
> 'Twas brillig, and Colin Guthrie at 08/07/10 10:40 did gyre and gimble:
>> 'Twas brillig, and Marco Ballesio at 08/07/10 09:37 did gyre and gimble:
>>> Hi,
>>> On Wed, Jun 16, 2010 at 10:59 AM, Colin Guthrie <gm...@colin.guthr.ie> 
>>> wrote:
>>>> Now, incorporating what you suggest, I guess I have nothing against a
>>>> specific module that actually manipulates a given priority list for you.
>>>> e.g. you could have a module-prefer-usb-for-music module that actually
>>>> implements your desired behaviour in a purely modular fashion by
>>>> automatically rearranging your music priority list for you. Personally I
>>>> think most users would not want it, but for those who do they can load it.
>>> sorry for jumping in the thread so late, but having worked on
>>> something similar I think a suitable project already exists. It is the
>>> "resource policy", based on ohm, the git repo is at:
>>> http://meego.gitorious.org/maemo-multimedia/ohm
>>> Through this tool it's possible to seamlessly handle whatever we can
>>> consider a resource (CPU, memory, audio sink/source) depending on the
>>> system state, which may change after particular events occur (e.g.
>>> audio jack insertion or removal).
>>> Many meta-informations like a proper wiki page are missing there
>>> though, but still it's worth a consideration imho, as the project can
>>> be considered as already quite stable (let's say it's at production
>>> level for some targets).
>> Thanks for the info.
>> I'm actually having a meeting next week to discuss some thing on this
>> general topic (loosely speaking) so I'll try and find out a bit more
>> about this before then.
> Hmm, interesting:
> http://meego.gitorious.org/maemo-multimedia/ohm/commit/3274a3dca2069865de3ace9a6cef658ee7b521d1
> "this project is obsolete and will be replaced with something more
> functional in the near future."
> Wonder what that "more interesting" project could be!

Actually, the level of interest couldn't be higher than the current
one from my pov :), what the improvements will focus on is the "more
functional" part. The idea is to keep a similar level of features
(among them automatic audio routing like on the N900) with a smarter

Obviously the project needs wiki page, mailing list and many other
bells and whistles, but nowadays almost everybody's on vacation, so I
guess we'll have to wait at least some weeks for those to arrive.

In the meanwhile, reading this interesting discussion I thought that
before adding complexity to pulseaudio and reinventing the wheel (it's
meant to be a constructive critic), an evaluation about routing audio
from a separate entity should be made, as this approach already works
on existing systems.


> Col
> --
> Colin Guthrie
> gmane(at)colin.guthr.ie
> http://colin.guthr.ie/
> Day Job:
>  Tribalogic Limited [http://www.tribalogic.net/]
> Open Source:
>  Mandriva Linux Contributor [http://www.mandriva.com/]
>  PulseAudio Hacker [http://www.pulseaudio.org/]
>  Trac Hacker [http://trac.edgewall.org/]
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss@mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
pulseaudio-discuss mailing list

Reply via email to