I started an implementation of the Audio MIO for streaming direct to a tunneled codec. The obstacle I ran into was that OpenCORE 1.0 does not support falling back to software if the hardware codec is busy.
The other difficult part is that stream type volume controls (i.e. media volume) are not available to the AudioSink. This means that the media volume needs to be propagated through AudioFlinger to the compressed audio driver (presumably through the kernel or a user space daemon). We will have a solution for this problem in a post-Cupcake release TBD. In fact, we are revisiting the entire audio architecture right now to fix some deficiencies that have become obvious as we try to accommodate additional use cases. On Mar 11, 3:49 pm, mahamannu <mahama...@gmail.com> wrote: > Thanks Dave > > I want to avoid mixing Music Stream [ from Pvplayer ] with other > Streams and re-direct the music stream to a different Audio H/W > Interface. Is it possible to send MIO buffers directly to H/W ? > Firstly what are the penalties for bypassing audio Flinger. As I > understand it is provifing Stream/Track based routing and Volume > control. MediaPlayerInterface.h recommends to implement > MediaplayerHWInterface to write directly to the HW. Are there changes > required in MediaPlayerService.cpp for this. I noticed that currently > it tries to get a Player Handle and since currently PvPlayer is of > type MediaPlayerInterface, it's audiosink object ends up forming > "tracks" to write to AudioFlinger. > Also, since AudioFlinger has the interface to AudioHardwareInterface ; > does another call to OpenOutputStream need to be made elsewhere if MIO > is to write buffers directly to H/W ? > > The other design that I can think of is to have a second AudioFlinger > object instantiated by AudioSystem which will only get Music Tracks > and write to its dedicated H/W. What issues do you see with this > design ? Does the AudioFlinger need to be made multi-threaded and > thread-safe fo this ? > > thanks, M > > On Mar 5, 9:55 pm, Dave Sparks <davidspa...@android.com> wrote: > > > AudioFlinger mixes into a small buffer which determines the latency > > (along with the underlying hardware latency). The source buffers can > > be any size. The mix buffer size has to be larger than the scheduler > > interval (typically 20ms) or audio will stutter under load. That means > > best case latency is around 40ms for a ping-pong buffer audio driver. > > > On Mar 5, 2:45 pm,mahamannu<mahama...@gmail.com> wrote: > > > > Hi, > > > > I'd like to know if the Audio Flinger uses the same mixer buffer for > > > combining Audio streams from Media Service playback [ Potentially > > > large buffer] , System sound [ ringtone , DTMF etc ] , Gaming Audio > > > [ Low latency ; small buffer ; ] at a given time. Usually Gaming Audio > > > might also use Media Service playback ; so essentially there may be 2 > > > or more PV playback inputs to Audio Flinger. The concern is that > > > although the MIO Audio component supports Flush [ in case of a seek/FF/ > > > Rewind on a stream] ; the next flush will be done at the DSP/H/W > > > level; which will not be able to distinguish between type of data if > > > it is mixed. It would be nice to not mix a Large Media Service output > > > buffer for optimization purposes with System sound ; as a flush at the > > > h/w will cause no system sound to be played or if the mixing is done > > > in serial fashion ; the time senstive System sound will play after a > > > large playback buffer has finished playing. > > > > Manu- Hide quoted text - > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to android-framework@googlegroups.com To unsubscribe from this group, send email to android-framework+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
