Hi, On Thu, Jul 15, 2010 at 5:35 PM, Colin Guthrie <gmane at 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 <gmane at 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 design. 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. Regards, Marco > > 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 at mail.0pointer.de > https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss >