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