Thx Tanu. Will heed the advise. Conor On Wed, Jan 13, 2010 at 4:45 AM, Tanu Kaskinen <tanuk at iki.fi> wrote: > ti, 2010-01-12 kello 11:48 +0000, Forwind info kirjoitti: > > Hi all, > > > > > > I have some notes below I made about using the Pulse Audio > > asynchronous API. If you have a minute would you mind casting your > > eyes over my proposed strategy. Any comments are very welcome. > > > > > > thx, > > Conor > > > > > > > > > > 1. To obtain the volume of primary Output Device. > > ans: Fetch the sink info via pa_context_get_sink_info_by_index(). > > The return value will contain volume data type (pa_cvolume). > > I don't know what you mean by "primary output device". But if you > somehow already know the index for the primary sink, whatever that > means, then yes, use that function. In case you think pulseaudio > recognizes a "primary sink" concept, please read > http://pulseaudio.org/wiki/DefaultDevice > > > 2.Differentiate between headphone volume if plugged in and speaker > > volume > > ans: Detect headphone connection - PulseAudio intend to expose > > jack-sensing once it becomes available to them from below. Its in the > > pipeline apparently. I need to do some more investigation around this. > > Some devices expose individual headphone volumes as opposed to speaker > > volumes others don't. > > It's not clear why you need to differentiate between headphone volume > and the speaker volume - are you writing a volume control app that > should be able to change the volume independently for headphones and > speakers? You don't need jack sensing for this. Jack sensing is for > switching the mode automatically when eg. the headphones are plugged in. > > The mode can already be switched manually with current pulseaudio - the > concept is called "device ports". Sinks and sources can have multiple > ports, and one port is always active (but some devices don't have ports > at all!). There are functions in the client API for getting a list of > available ports for a device, and for switching the port. > > When the port is switched, pulseaudio will control the correct alsa > mixer element regardless whether the headphones and the speakers use the > same or different mixer elements. > > > 3. Detect no output devices(sinks) > > ans: pa_context_get_sink_info_list - if the returned array is empty > > then there are no output devices. > > The function doesn't return an array. It calls your callback multiple > times, and the last call has the eol parameter set to a positive value > and the info struct pointer set to NULL. But yes, in principle that's > how you do it. Note, though, that the default configuration loads > module-always-sink, which loads a null sink if no other sinks are > present, so usually the sink list won't be empty. If you want to treat > the lone null sink as equal to having no sinks at all (which may or may > not be sensible), you should probably check whether there is only one > sink present, and if that's the case, check whether the only sink's > module is "module-null-sink". > > > 4. If the sound is muted and some exterior application attempts to > > play sound then flag it > > ans: Subscribe to the PA_SUBSCRIPTION_EVENT_SINK_INPUT event and > > on the callback check to see if that sink is muted (boolean). Note if > > the client application is paused, the sink is then muted and the > > client app is restart the event will not be triggered. This might be > > not satisfy UI spec requirements. Check with MPT. > > This is correct, including the note about problems with unpausing. You > don't get any kind of a notification when a stream is unpaused (uncorked > in pulseaudio terminology). Maybe the cork status should be exposed in > the sink input and source output info structs, and events should be sent > whenever the status changes. > > This would still not work for applications that implement muting by > sending silence. I don't know how usual common that is. Rhythmbox seems > to use proper corking. > > > 5. Ability to mute all output sinks. > > ans: pa_context_set_sink_mute_by_index()- iterate through all > > sinks returned via pa_context_get_sink_info_list(). Maybe > > there is a mute all switch - could not see it in the docs right now - > > will ask on #pa on freenode. > > Correct. There is no mute all function. Personally, I think there should > be (perhaps not in the core API, but provided by an extension module). > > > 6. Unmute all outputs and return to previous volumes. > > ans: PA's module-stream-restore - more investigation. Apparently > > this will store previous volumes of all sinks and restore them when > > required. > > Sink volumes are restored by module-device-restore. > module-stream-restore restores stream volumes. But your objective sounds > misguided: muting a sink doesn't change the sink volume. Therefore > unmuting the sink restores the previous volume even without any helper > modules. > > > 7. Set individual output volumes to 0 (distinct from mute) > > pa_context_set_sink_volume_by_index() or by name. > > Yes. > > > 8. Set individual outputs volumes to max. > > ans: Set the sink (output device) in question to PA_VOLUME_NORM. > > pa_cvolume_reset() - should do this for the sink in question. > > PA_VOLUME_NORM roughly corresponds to 0DB => MAX volume without > > clipping. > > Use the base volume value that is stored in the sink info struct. That's > the level that the sound card reports as 0dB. Higher values may or may > not clip, depending whether the mixer element controls a digital or > analog amplifier. > > HTH. > > -- > Tanu Kaskinen > > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at mail.0pointer.de > https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20100113/e979b18a/attachment.htm>