Re: Tolerant Player



Alastair,

(I've copied this to the list in case others are interested since its
a sensible question).

The class might be more sensibly named:   SplicingIntoAudioBuffer

Your first set is correct:

> 1. Packet Receiver sends packet to SplicingAudioBuffer
> 2. SplicingAudioBuffer checks if packet has been played before or not
> 3. If it hasn't, write it to the AudioTrack

The AudioTrack maintains a buffer and so by trying to write your data
into the audio track it will most probably block the decoding thread
on that track until there is space in the buffer to write it.  What
then happens is as follows:

Thread A is playing audio and keeps on decoding the stream and writing
it into the audio buffer until the buffer is full and Thread A is
blocked waiting for space to be available (i.e. Thread A is throttled
to the audio playback rate)

Thread B comes along because of a disconnection and attempts to write
data to the SplicingAudioBuffer.  This has already been played and so
the buffer throws it away.  Thread B is not blocked and so tries the
next packet and so on until it gets to the one after the one that
Thread A is currently blocked on playing.  When it tries to write this
one out the SplicingAudioBuffer accepts it and tries to write it to
the audio device which in turn then blocks Thread B waiting for the
data  to play.

Thread A then becomes unblocked because its data has been written to
the audio device and so it decodes the next packet in the stream.
However, this packet has just been played by Thread B and so gets
thrown away by the SplicingAudioBuffer.  Thread A then tries the next
packet, this is accepted and it blocks on the write.

Therefore the two threads proceed in this manner writing alternating
packets to the audio device until one of them runs out of data from
its input (because the connection was closed).

Andy

On 1 November 2010 14:07, Alistair Stead <alistair.stead at gmail.com> wrote:
> Hi Andrew,
>
> Just a quick question (which is probably a silly one at that). Is the
> following pseudo code correct?
>
>
> 1. Packet Receiver sends packet to SplicingAudioBuffer
> 2. SplicingAudioBuffer checks if packet has been played before or not
> 3. If it hasn't, write it to the AudioTrack
>
> This is how it's implied to work from your comments. If so, the
> SplicingAudioBuffer isn't acting as a buffer? Surely the pseudo code
> should be...
>
> 1. Packet Receiver sends packet to SplicingAudioBuffer
> 2. SplicingAudioBuffer checks if packet has been played before or not
> 3. If it hasn't, write it to a local buffer
> 4. write the next packet that hasn't been played in the buffer
>
> I'm pretty sure the second one is correct i'd just like clarification.
>
> Many thanks,
>
> Alistair Stead
>




This archive was generated by a fusion of Pipermail (Mailman edition) and MHonArc.