[pulseaudio-discuss] a sounding program with several output streams

Colin Guthrie gmane at colin.guthr.ie
Thu Jan 5 02:53:50 PST 2012


'Twas brillig, and Roman Beslik at 05/01/12 00:24 did gyre and gimble:
> On 03.01.12 14:37, Colin Guthrie wrote:
>> 'Twas brillig, and Roman Beslik at 02/01/12 22:55 did gyre and gimble:
>>> them) for enhanced user experience. E.g., Skype outputs incoming call
>>> ringing to speakers and talk to a handset. Because programs do not chose
>> Yes, programs can create as many streams as they want (each sink will
>> only support (I think) 32 streams, but that's just to prevent too much
>> craziness! :)
> Yeah, that's good. Actually incoming call ringing is not visible because
> it is included into "System Sounds", I was perplexed and read other
> perplexed users' discussions, and decided that there is some defect in
> PulseAudio or Skype.

Yeah, this is intentional. Event sounds, like a buddy signing in, are
very short lived, so as was mentioned in your other thread, they are
simply grouped up under "Event Sounds" such that the user does actually
have a real chance of adjusting their volume to suit their tastes. I
appreciate it might not be as transparent as it could be however.
Perhaps there is something we can do about that in the GUIs. Such as
show the names+icons of the 5 most recent applications that have
produced an event sound, just so that it's a bit more obvious to users
looking to adjust the volume.

This "last 5" list wouldn't be perfect tho' - it would be up to the
client side to track them and thus if you quit/restart the GUI it would
likely have a blank list. Anyway, just a not-thought-through suggestion
to see what people think.

>> Over all this metadata allows for interesting things to happen
>> automatically. For example if someone has a headset (USB or Bluetooth)
>> we can automatically use it for phone calls which is (with ~90%
>> liklihood) what the user wants. Obviously the user should still have
>> manual control over this, but if we can "do the right thing"(tm) out of
>> the box by using this additional metadata then all is well.
> This would be cool. It seems to me that this metadata is different from
> the case with Skype. This metadata is more like "preferred sink for a
> stream." Suppose a game sends audio to 2 gamers. 2 streams, but all have
> "headset" as their preferred sink.

Hmmm, not sure what you mean... are there cases where two people play on
the same machine when they are sharing the same h/w? I appreciate there
a multi-headed systems but usually the sound h/w is partitioned too and
thus each user would be logged in separately and run their own instance
of the software - i.e. two game processes, two separate PA daemon, two
separate USB headsets etc.

I can't quite think when a single game process would need to support two
separate players? Perhaps in some kind of co-op mode I guess, but even
still, on the same machine seems a little strange to me (I'm not a
massive gamer tho', so please do feel free to enlighten me!).

Anyway, even if this was needed, the game itself just needs to provide
suitable metadata such that we consider the streams are treated
independently such that their device can be mapped independently. e.g.
rather than just "My Game" it would present itself as "My Game (Player
One)" (I'm glossing over the real implementation here for general
concept clarity). This would allow us to map things separately.

And also, the metadata supplied is typically to allow for out-of-the-box
functionality - i.e. sensible defaults. Users will always be able to
customise things to taste. Yes, in your example both streams may be
tagged as "headset" but this is just metadata that *can* be used for
routing, it's not the actual routing decision itself. It's just hints
that can be used in lieu of any actual, user-selected choice.

The application should rarely actually dictate a device to use. That
decision should be made at the PA end (of course PA can and does
remember the manual choices users make in order to do the same thing
next time).

All the best

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/



More information about the pulseaudio-discuss mailing list