[pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards

[Colin Guthrie]

'Twas brillig, and Marco Ballesio at 16/07/10 07:58 did gyre and gimble:
> 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.

Well right now there are several projects (outside of my own) going on
in this field, but there does seem to be a little bit of disparity with
upstream people.

One project specifically is coming from the ALSA side and will get
support in PA. This project is very likely to become the defacto method
of operation on embedded systems and thus I would hope that people at
MeeGo would talk more openly about what they are doing so as not to
reinvent the wheel.

I'm not against any kind of external system to deal with client routing
etc. but there is simply not the same level of hooks and controls
available to an external client. There will always be initial routing by
PA then a move from the client. Also, the APIs currently exposed mean
that certain side effects of calling certain API calls (e.g. the
move_sink_input calls) cannot be avoided.

Therefore I really feel that some built in routing management is the way
forward.

Developing a PA module is not hard and I don't really see the benefit of
deveoping several different external systems: one for MeeGo, one for
Gnome, one for KDE etc. etc. I'd rather build it once and let everyone
use it.

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/]