From: Mike Holden <rockbox_at_mikeholden.uklinux.net>
Date: Tue, 25 Mar 2003 09:28:28 -0000 (GMT)

Björn Stenberg said:
> Mike Holden wrote:
>> but i do sometimes still get "silent playback", which is the
>> symptom of this problem.
>
> Silent play can be caused by a lot of other things too, such as
> miscalculation of the buffer watermark for example.
>
>> I will continue to dig, however!
>
> Please do.
>
>> Also, should the READ_TIMEOUT be max(5*HZ,<anti_skip_buffer_size>),
>> since if anti-skip buffer is set to 7 seconds, we are giving up the
>> ata read 2 seconds before the anti-skip buffer empties, and abandoning
>> 2 seconds of successfully read mpeg data.
>
> The read timeout has nothing to do with how much data has successfully
> been read. As I explained earlier, each read operation is atomic. It
> either succeeds completely or fails completely. It cannot fail yet
> report some amount of data as read.

Yes, I appreciate this - we are "on the same page" on this! My point is
that we are giving up and returning an error, even though we still have 2
seconds of mpeg data that we can continue playing. We can therefore
continue to try for a complete read for a further 2 seconds without the
user noticing anything amiss. I am not saying that we should return less
data than was requested and return success (maybe we should, but this
would require rewriting the code to return how much was read!).

Also, after a failed read, we attempt to read ata data from the beginning
of the request again, but we have already successfully read this data -
should we perform subsequent "re-gets" at the next unsuccessful sector?
With the current system, we could successfully read the 1st sector many
times, but always fail at the 2nd or subsequent sector. If we restarted at
the next unread sector, we could possibly get the whole data set, but
spread over several partial read attempts.

For example, we request 10 sectors, from sector 1 to sector 10. Read 1
reads sectors 1-3, but fails during sector 4. Read 2 should start at
sector 4, rather than starting at sector 1 again - we already have sectors
1-3 in the buffer and do not need to read it again.

>
> Giving up the read 2 seconds before the buffer runs out simply means we
> have 2 seconds to (try to) read the next file before playback stops.
>

Yes, but this forces a skip on the user (skip to next track), when there
is still the possibility that we could read the correct data from the
current track during those 2 seconds, and continue playing for the user
with no skip. IMHO we should attempt to read the "correct" data for as
long as the user has said they want to try (by setting the antiskip buffer
size). We should only abandon the current track and skip to the next track
when the ASB is completely empty (again IMHO).

-- 
Mike Holden

Received on 2003-03-25