On Mon, Jan 6, 2014 at 9:45 PM, Devin Heitmueller <dheitmueller@xxxxxxxxxxxxxx> wrote: > > On Mon, Jan 6, 2014 at 11:29 PM, Tim Mester <ttmesterr@xxxxxxxxx> wrote: > > The demodulator can get in a state in ATSC mode where just > > restarting the feed alone does not correct the corrupted stream. The > > demodulator reset in addition to the feed restart seems to correct > > the condition. > > > > The au8522 driver has been modified so that when set_frontend() is > > called with the same frequency and modulation mode, the demodulator > > will be reset. The au0282 drives uses this feature when it attempts > > to restart the feed. > > What is the actual "corruption" that you are seeing? Can you describe > it in greater detail? The original fix was specifically related to > the internal FIFO on the au0828 where it can get shifted by one or > more bits (i.e. the leading byte is no longer 0x47 but 0x47 << X). > Hence it's an issue unrelated to the actual au8522. > > I suspect this is actually a different problem which out of dumb luck > gets "fixed" by resetting the chip. Without more details on the > specific behavior you are seeing though I cannot really advise on what > the correct change is. > > This patch should not be accepted upstream without more discussion. > > Regards, > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com The patch really address two issues: 1) The driver reports that the TS sync byte has not been found (the 0x47), and that it is attempting to restart streaming. However, this message gets repeated indefinitely, and the streaming can never begin. Eventually, Mythtv gives up on the recoding. When I reset the demodulator, the streaming immediately starts. I have not examined the data to see if it is a shifted sync byte or not, but the symptom seems similar. 2) Occasionally, the au8522 report that it lost lock, and the TS stream stops flowing. The au8522_set_frontend(), gets called, but because we are already tuned to the same frequency, nothing happens, and lock is never re-established until we tune to a different channel, then back to the original one where lock was lost. I have only seen this behavior in ATSC mode. Back when I was using the device in QAM256 mode, I did not observe the Lock lost or the unable to start streaming issues. Thanks, Tim -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
