[pulseaudio-discuss] why command_cork_playback_stream() will be invoked many times?

Mark Greenwood fatgerman at ntlworld.com
Wed Jan 21 15:19:44 PST 2009


>>The requirement that internal pause an application is a natural to
audio manager of embedded system.

That would be what you'd think but you would be surprised what a hack
some of these things are. It's what I do for a living. Certainly in the
products I work on, that kind of logic is left to the application layer
to work out. The audio manager is surprisingly dumb.

I'm not saying that's how Apple do it, but I wouldn't be surprised.

Mark


On Wed, 2009-01-21 at 15:55 -0600, pl bossart wrote:
> I don't disagree with technical findings. Still, it would be sad if we
> have no means to do what the iPhone does today. Cheers. Pierre
>  
> From the iPhone 'missing manual' book:
> If a phone call comes in, the music fades, and you hear your chosen
> ringtone―
> through your earbuds, if you're wearing them. Squeeze the clicker on
> the earbud cord, or tap the Sleep/Wake switch, to answer the call.
> When the
> call ends, the music fades back in, right where it had stopped.
> 
>  
> On Tue, Jan 20, 2009 at 8:51 PM, Zhang, Xing Z
> <xing.z.zhang at intel.com> wrote:
> 
>         Yes, I also agree with Lennart's point.
>         
>         >>I agree with you that pausing may create timing havoc on the
>         client; but we are missing a generic protocol to notify the
>         clients and implement this legitimate use case.
>         
>         
>         I am afraid there is no way to notify applications using ALSA
>         due to the PA client is libasound_module_pcm_pulse.so at this
>         time.
>         
>         IMO, PA is for general OS but not for embedded system now. The
>         requirement that internal pause an application is a natural to
>         audio manager of embedded system. I guess we can only cover
>         applications who will response the message "you should do
>         pause now" from audio manager.
>         ________________________________________
>         From: pulseaudio-discuss-bounces at mail.0pointer.de
>         [mailto:pulseaudio-discuss-bounces at mail.0pointer.de] On Behalf
>         Of pl bossart
>         Sent: 2009年1月21日 0:13
>         To: General PulseAudio Discussion
>         
>         Subject: Re: [pulseaudio-discuss] why
>         command_cork_playback_stream() will be invoked many times?
>         
>         
>         
>         Hi Lennart,
>         Here is the use case Xing is referring to: you are listening
>         to music, and a VoIP call starts. The user may not want to mix
>         the music and the speech call.
>         
>         So the idea is to pause the music while the call takes place,
>         and resume the music once the call finishes. PulseAudio
>         receives both streams, and it would seem natural to configure
>         said behavior in a PulseAudio module. So we either need the
>         ability to pause a stream within PulseAudio, or we need a
>         means to inform the client they need to pause.
>         
>         I agree with you that pausing may create timing havoc on the
>         client; but we are missing a generic protocol to notify the
>         clients and implement this legitimate use case.
>         Regards,
>         Pierre Bossart
>         On Sun, Jan 18, 2009 at 11:16 AM, Lennart Poettering
>         <lennart at poettering.net> wrote:
>         On Fri, 09.01.09 21:10, Zhang, Xing Z (xing.z.zhang at intel.com)
>         wrote:
>         
>         > Hi experts:
>         
>         > I worked on an audiomanager project based on PulseAudio. Now
>         I am
>         > blocked by a command_cork_playback_stream() issue.  In our
>         design,
>         > an application may be corked when connects to pulseaudio if
>         its
>         > priority is low. I set a hook on PA_CORE_HOOK_SINK_INPUT_PUT
>         and
>         > invoke pa_sink_input_cork(..., TRUE). Unfortunately it
>         doesn't
>         > work. By GDB, I found application will call
>         > command_cork_playback_stream() which invokes
>         pa_sink_input_cork(...,
>         > FALSE) several times, this make my hook is of no effect. I
>         don't
>         > look into PA for ALSA plugin, anyone know why
>         > command_cork_playback_stream() need be called so frequently
>         during
>         > app initialization?
>         
>         Hmm, I think you are confusing a few things here.
>         
>         command_cork_playback_stream() is the code that dispatches
>         client
>         requests for corking/uncorking (when done via the native
>         protocol). It
>         is not used when corking something internally as for example
>         by a hook
>         function.
>         
>         Pausing a stream (i.e. corking) should be something that is
>         controlled
>         exclusively by the client. You should not intefere with it
>         from inside
>         the server. There is a state machine in the PA client code
>         that
>         follows the cork state. If you change the state underneath it
>         might
>         become invalid. Also it might confuse client applications due
>         to
>         the paused timing.
>         
>         Lennart
>         
>         --
>         Lennart Poettering                        Red Hat, Inc.
>         lennart [at] poettering [dot] net         ICQ# 11060553
>         http://0pointer.net/lennart/           GnuPG 0x1A015CC4
>         _______________________________________________
>         pulseaudio-discuss mailing list
>         pulseaudio-discuss at mail.0pointer.de
>         https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>         
>         _______________________________________________
>         pulseaudio-discuss mailing list
>         pulseaudio-discuss at mail.0pointer.de
>         https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>         
> 
> 
> 
> _______________________________________________
> 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/20090121/f10c8dec/attachment.htm>


More information about the pulseaudio-discuss mailing list