Heads-up: the routing patches will start to get merged soon

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hiya,

'Twas brillig, and David Henningsson at 22/04/14 09:41 did gyre and gimble:
> On 2014-04-17 12:41, Tanu Kaskinen wrote:
>> On Fri, 2014-04-04 at 15:50 +0200, David Henningsson wrote:
>>> On 04/04/2014 11:31 AM, Tanu Kaskinen wrote:
>>>> I'm heading towards "a generic solution to our current routing issues",
>>>> but that solution will depend on Murphy, which will provide the
>>>> configurability and the default routing rules. In my opinion,
>>>> implementing another solution with good configurability and
>>>> better-than-current default routing without Murphy should be
>>>> implemented
>>>> by someone else, if a non-Murphy-based solution is desired.
>>>
>>> (Just summing up what we discussed on IRC)
>>>
>>> So the result from all this work is that normal desktop users will get
>>> nothing, except an API and quite some infrastructure to maintain.
>>>
>>>> If I understood correctly, you wish that I'd implement a full generic
>>>> non-Murphy-based solution before merging the node infrastructure, but
>>>> it's unclear to me whether that wish is a minimum requirement or not,
>>>> and if it's not, what's the minimum requirement?
>>>
>>> I'm not sure what to answer to this question right now. I'd like to hear
>>> what others have to say as well.
>>
>> Others were silent, so in the absence of permission from you to do
>> anything else I think I'll have to work with the assumption that I will
>> need to provide some kind of configurable non-Murphy-based routing
>> module before the routing infrastructure can be accepted to master.
> 
> Well, I'd much prefer to hear more opinions about it. It's difficult for
> me to know as well.

Sorry, I've been somewhat slow to comment on this.


Is there a simple summary of the hooks etc. added by the Murphy patches
that would be available to said alternative routing system?

As you know there is routing functionality built into the
module-device-manager module which is used under KDE.

With not too much effort, (I've recently done some of this work in
unpushed changes), I wanted to adapt this current device-centric routing
to be more device-port based (allowing priority list of:

1. Headphones (via built in jack)
2. USB Speakers
3. Laptop speakers

where 1 & 3 are the same sink, just different ports)


Once this is done, I think it could also be the default routing module
used on GNOME (and would solve
https://bugzilla.gnome.org/show_bug.cgi?id=728592 too in the process).

With this in place, it would only take a little effort to port some of
the specific functionality modules (e.g. using BT/USB headsets for phone
calls etc) to inject device into the routing tables used by m-d-m
appropriately rather than actively moving streams.

Obviously if the Murhphy patches add nice APIs for "rerouting" and such
like then m-d-m should be ported across to it at the same time.

I know I'm not really active these days, but if this is something you
want to discuss, I can make myself available for a meeting to discuss
more and also potentially commit to doing some more work on it if there
was a very specific goal and plan in mind with a view to merging etc.

Also happy to make the necessary API changes on the KDE and GNOME sides
too to interface with this as appropriate (likely quite minimal changes
on both sides).

Let me know if you want to chat more.

Cheers

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux