Where can I modify the buffersize for the audio? I am trying to test the effect of bigger buffer sizes for my system
- Akash On Mar 11, 9:52 pm, Dave Sparks <davidspa...@android.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
