>On some embedded devices, applications may play audio on some specific H/W >that does not >fit into ALSA/PA model. For managing those streams, we provide >some API so that applications >can register the "special" streams with the >policy engine. This results in am_stream structures >being created also.
Yes, on some embeded devices which may have chip which could directly decode encoded audio data and directly throw to sound card. This kind of audio stream will never go into Alsa or PA, that's why am_stream_struct is introduced, it is a higher level abstraction of audio stream. The stream state of this kind of audio stream is not awared by PA, so the stream state change need app to explicitly notify policy engine so that policy engine could correctly perform re-evaluation base on the correct set of audio streams. Best Regards, Zheng, Huan(ZBT) OTC/SSD/SSG Intel Aisa-Pacific Research & Developement Ltd Tel: 021-6116 6435 Inet: 8821 6435 Cub: 3W035 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bu, Long Sent: Friday, February 06, 2009 4:28 PM To: General PulseAudio Discussion Subject: [pulseaudio-discuss] Policy engine(was RE: why command_cork_playback_stream() will be invoked many times?) The policy engine basically mute/unmute/pause/resume some streams or migrate some streams from one device to another according to some configuration script. Each stream has some properties like IS_MIXABLE, PRIORITY, ACTION and FAVORITE_DEVICE etc. For now, ACTION could be mute or pause, which means that a stream would be muted or paused respectively when the priority is not high enough to playback. When priority allows, the previously muted/paused stream would be unmuted/resumed automatically. Since this is targeted for various platforms not limited to PC, their may have diverse audio devices, so with FAVORITE_DEVICE, applications can specify one stream to be played back on which device. For example, a VOIP application is working through Bluetooth Headset while a MP3 player is playing music through speaker. With a UI, user can adjust stream properties run-time. ---------------------------------------------------------------------------- Here are more details: A data structure am_stream represents a stream. (Of course, we can use pa_pstream with some additional members; we will do this after the idea has been accepted by community.) When an ordinary PA stream is created, some hook function will create an am_stream structure with properties being set according the configuration. On some embedded devices, applications may play audio on some specific H/W that does not fit into ALSA/PA model. For managing those streams, we provide some API so that applications can register the "special" streams with the policy engine. This results in am_stream structures being created also. Basically there are 3 queues of am_stream structures, Active Q, Internal_Q and User_Q. Active Q contains all streams that is currently being played; Internal Q contains all streams that is muted/paused due to policy reason; and User Q contains all streams that is paused explicitly by users. So if a stream comes in and wants to be played, policy engine will evaluate the permission with streams in Active Q. If permission allows, put that stream in Active Q, otherwise mute that stream and send a signal indicating muted or paused(if action is pause) to the application. If the application cooperates, it will update UI and do the pause work. If a stream stopped playing, policy engine will examine the Active Q and the Internal Q to see which streams in internal Q can be played. If there are some, put them into Active Q and send a signal indicating resume to the application which updates UI and do the resume work. When a removable device is available or unavailable, the policy engine will migrate streams in active Q from their current device to the more favorable device. Now all logics are put into modules(one module for H/W independent common logic and one module for platform specific tasks such as device management, stream migration) for quick implementation. Once those ideas are accepted by community, some code should be moved into PA core which is more proper IMHO. It's little bit lengthy.:-) Hope this can help you understand our ideas. Any thoughts are appreciated. Regards. Long >-----Original Message----- >From: [email protected] >[mailto:[email protected]] On Behalf Of Colin >Guthrie >Sent: 2009年2月5日 17:39 >To: [email protected] >Subject: Re: [pulseaudio-discuss] why command_cork_playback_stream() will be >invoked many times? > >'Twas brillig, and Zhang, Xing Z at 05/02/09 06:01 did gyre and gimble: >> Sorry for late reply, I am just back from holidays. >> Yes, we are on the similar way as you said. >> Now we are working on enhance PA to introduce policy engine to it. To avoid >> do changes on PA core code, we implement the engine as a individual module. >> We hope the module is expandable and flexible. The engine is not only suit >for PC but also for embedded system which has specific audio hardware. >> Now we are in heavy developing, once codes are ready I will send out the >> patch >for review. Thanks. > >The policy engine sounds interesting. > >Have you got any details of what it would do and it's general principle >of operation? > >I presume this is all discussed with Lennart, but I'd be interested to >know what's cooking in this area :) > >Col > >-- > >Colin Guthrie >gmane(at)colin.guthr.ie >http://colin.guthr.ie/ > >Day Job: > Tribalogic Limited [http://www.tribalogic.net/] >Open Source: > Mandriva Linux Contributor [http://www.mandriva.com/] > PulseAudio Hacker [http://www.pulseaudio.org/] > Trac Hacker [http://trac.edgewall.org/] > >_______________________________________________ >pulseaudio-discuss mailing list >[email protected] >https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss _______________________________________________ pulseaudio-discuss mailing list [email protected] https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss _______________________________________________ pulseaudio-discuss mailing list [email protected] https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
