[Gpephone-devel] functions of sound server

[Zhao Shichang]

Your VoIP stack is not LiPS compatible.

If I design the system, I think there're two portions: phone and media. either portion has its default event handler, and also let apps register their own event handlers.

phone: mobile phone, VoIP phone
   It should use audio device exclusively. When it enters phone mode, media playing should take its defaut action: mute, or app may take its own event handler.

media:  many audio streams with priority
	The highest priority audio streams should be mixed. 
	The lower priority streams should be muted, volume down, or let apps take its own event handler. The default action had better be configurable.

REGARDS
littertiger

>Hi Yu,
>
>I agree with you that the functionality that the sound server  
>provides is good and that it is ideal for all applications to use  
>it.  We still do use the qtopia sound server and most applications  
>make use of it.  This provides the mixing support that you mention.   
>However, we are using a binary VoIP stack that opens the sound device  
>directly.  The stack was not written as a qtopia application and so  
>it knows nothing about the qtopia sound server.  It opens the sound  
>device directly and we have no way of changing it.  Some would  
>probably say that this is the real problem, the fact that it's not an  
>open source stack, but sometimes this is a reality that we have to  
>deal with.
>
>Dirk
>
>
>
>On Feb 25, 2007, at 6:16 AM, Yu Yijun wrote:
>
>> Hi, Dirk,
>> It's good to know a different approach for the concurrent sound  
>> device access. However, I'm not very clear on your model.
>> Do you still need a sound server? if no, it's a pity that there is  
>> no sound mix functionality since some time we need to hear sound  
>> from different sources. e.g, we listen to a music and at the same  
>> time hear the alert sound of low battery signal. if yes, the model  
>> is a little bit complex, isn't it?  Moreover, if two apps open the  
>> sound device with different priorities, the lower priority app just  
>> keeps running but quitely. Some time it is not the expected  
>> behavior and a pause mechanism to the lower priority app should be  
>> provided.
>> BTW, I'm curious that what is the concrete scenario that an  
>> application want to use sound device directly, bypassing sound server.
>>
>> Regards
>> Yu Yijun
>>
>>
>> Dirk Sigurdson <dsigurdson at a-la-mobile.com> wrote:
>> My company has had some experience with this issue in the Qtopia
>> environment. Qtopia has a sound server that will mute applications
>> (example, media players) when there's a call in place as long as your
>> application is using the Qtopia sound API. Our problem has been that
>> there are some applications that want to access the sound device
>> directly, bypassing the Qtopia sound server. Rather than handling
>> this problem at the application level we decided to handle it in the
>> driver level. When the application opens the sound device it can
>> indicate a priority. If it's a high priority app then when two
>> applications are using the device the user would only hear the high
>> priority audio.
>>
>> As long as you're in control of all the applications that are in the
>> device and can modify them to use a single sound API or to listen for
>> the incoming call event, then that's probably the way to go.
>> However, I just wanted to point out a different approach that might
>> be able to handle a larger set of applications.
>>
>> Dirk
>>
>>
>> On Feb 13, 2007, at 2:34 AM, YU Yijun RD-ILAB-PEK wrote:
>>
>> >
>> >
>> >>>>
>> >>>> Thanks!
>> >>>> What happens when there comes a phone call,or user estiblish a  
>> call
>> > while
>> >> playing
>> >>>> music?
>> >>>> Normally, music playing will be paused( or just mute?).
>> >>>>
>> >>> Currently, sound server just mixes them up.
>> >>> We may use other mechanism to pause the music player. Say music
>> >>> player
>> > will
>> >> register an incoming call event and once it receives this event, it
>> > will pause
>> >> itself.
>> >>>
>> >>> There is no such mechanism in the current edition and we welcome
>> > suggestions
>> >> & contributions.
>> >>>
>> >>> Regards
>> >>> Yu Yijun
>> >>
>> >> Two ways I think:
>> >> 1, pause music playing
>> >> sound server should send messages to all playing processes to  
>> pause.
>> > perhaps
>> >> it will cause a long delay, and make applications that want to play
>> > music more
>> >> complicated.
>> >>
>> >> 2, mute all music
>> >> it's application transparent. sound server should have a timer to
>> > process
>> >> audio buffers periodically. perhaps it wasts too much resources.
>> >>
>> >> Any better suggestions?
>> > Hi,
>> > In fact, I mean that once there is an incoming call, phone server  
>> will
>> > broadcast this event and any application can register it.e.g., diaer
>> > application, music player application, etc.
>> > When music application receives this event it can then pause itself.
>> > Unfortunately, in the current code, phone server sends incoming call
>> > event directly to dialer app and music app has no chance to receive
>> > this
>> > event. Therefore, in the following version, I suggest we should  
>> revise
>> > phone server's ability.
>> >
>> >
>> >>
>> >> REGARDS
>> >> littertiger
>> >
>> > _______________________________________________
>> > Gpephone-devel mailing list
>> > Gpephone-devel at linuxtogo.org
>> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/gpephone-devel
>>
>>
>> _______________________________________________
>> Gpephone-devel mailing list
>> Gpephone-devel at linuxtogo.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/gpephone-devel
>>
>>
>> Don't be flakey. Get Yahoo! Mail for Mobile and
>> always stay connected to friends.
>
>
>_______________________________________________
>Gpephone-devel mailing list
>Gpephone-devel at linuxtogo.org
>http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/gpephone-devel
>