Rockbox mail archive
Subject: Re: Feature freeze - silent play (wasRe: #673350 'Improvements for status line')
From: Mike Holden (rockbox_at_mikeholden.uklinux.net)
Björn Stenberg said:
> Mike Holden wrote:
>> My remaining issue is "Silent Play".
> I believe silent play is an mpeg issue (misinterpreting vbr headers etc)
> and not a disk reading issue. I also haven't seen any reports about this
> since Linus fixed some problems in the mpeg code a while ago. Feel free
> to brief us if this happens to you.
Yes, I have still been seeing silent play. It ALWAYS happens towards the
end of a track, and continues into the beginning of the next track.
I see that a fix has just gone in for byte swapping, so I will investigate
that, and report back if that doesn't fix it!
>> The code comment has 5 * nop, and the comments says 400ms. Where did
>> this figure come from? Is it the ATA spec? How long does a nop take,
> Yes, the 400ns is defined in the PIO protocol part of the ATA
> "HPIOI1: Check_Status State:
> This state is entered when the host has written a PIO data-in command to
> the device and nIEN is set to one, or when INTRQ is asserted. When in
> this state, the host shall read the device Status register. When
> entering this state from the HI4 state, the host shall wait 400 ns
> before reading the Status register."
> A nop instruction takes one clock cycle, and since the cpu is clocked at
> 12 MHz each cycle is 83ns long.
Fair enough. Makes sense. Of course the FM has a slower CPU (11Mhz), so a
NOP is therefore more like 90ns! Can't see that making any difference
How much leeway do you get on the 400ns? Is it any time after that period?
I assume it must be - it's just a minimum period to wait to give the
hardware time to perform the operation and populate the register.
Page was last modified "Jan 10 2012" The Rockbox Crew