I haven't read the code (not even the Java side). I can only guess
that in streaming mode it allocates a buffer it manages as a ring
buffer, or something like that.
But I'd expect that to only happen at startup. Any delays in write()
calls I'd expect to be simply waiting for room to copy the data,
rather than driver issues. You should be able to save away the times
the write calls return in an array, and see if they're approximately
one buffer time apart. If you're seeing significant variance, then you
have reason to wonder why. GC would be one possibility. I don't know
the details of the dalvik GC, but it may need to do some operations in
a separate thread, or some operations of significant size (an an audio
time scale), which might be happening in other threads, making it
impossible to return to your thread in as timely a way as you'd like.
I can't think of why a driver, directly, would cause spurious delays,
but it might have to wait on a lock somewhere, for which there's
contention.
If you want to know, I'd start with collecting the timing data, and
seeing what you can correlate any anomalies with.
I'd take a look at the code, but I don't have my hands on it. My first
attempt ran afoul of it expecting to create symlinks, which weren't
supported on the filesystem I set up for the purpose, so I'll have to
come back to that when I clear higher-priority items from my queue.
Sometimes I google up this or that bit of system source code, but that
doesn't exactly make for good reading.
So you shouldn't take anything I say as being based on deep knowledge
of the system. I have deep historical knowledge of a wide array of
systems, which helps orient me, but that has its limits.
It's easy to seem smarter than you are on the Internet, by just
keeping your mouth shut when you don't know anything, and speaking up
when you do. I try to take a slightly riskier approach, and risk
overstepping my knowledge occasionally. You learn a lot more that way!
On Feb 21, 1:19 am, ani <anish198519851...@gmail.com> wrote:
> > Things like ring buffers are still the same idea, but I won't explain
> > how they're the same, because it would make the explanation more
> > confusing. Just hold onto the core idea -- the receiver and sender of
> > data each have their own buffers.
>
> Heartfelt thanks for this great explanation.
>
> I am a driver guy and i fully understand the concept of ring buffer
> mechanism and how it used in ALSA.What i don't understand is that
> sometimes write(){called by audioflinger} function call takes some
> time to return(probably because of driver bug or latency) and
> sometimes it doesn't return at all causing problem as shown below:
> "obtainBuffer timed out (is the CPU pegged?)" in audiotrack.cpp
>
> Is this buffer same as what is being allocated in the case of
> streaming(sharebuffer = 0) in audioflinger.cpp file(constructor of
> trackbase)
> mCblkMemory = client->heap()->allocate(size);
> If not then which buffer is this and where was it allocated.How can i
> avoid getting this error other than solving it in driver?I don't mind
> dropping some frames.
>
> In the static case i guess when we call write() of audioflinger the
> java pointer is directly passed to audiodriver by copying and we don't
> maintain any buffers in this case?
>
> And what is this track(audioflinger point of view)?How many tracks are
> going to be created if i am playing music and what will be it's size??
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
