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