[linux-dvb] Re: Strange problem with TT budget DVB-C - tuning ok but no data

[emard@softhome.net]

> That is not needed if you write the RPS code correctly as written above. I
> have implemented quite complex RPS code in my Windows driver which
> automatically fills a "hardware queue" of buffers and can be paused at any
> time (even while waiting for the right BRS state!) by setting an RPS
> signal, and acknowledges when it entered the paused state with another
> signal, so that the driver can fully synchronize the with RPS task at any
> time. Restarting after pause works in a similar fashion: Driver sets RPS
> signal, RPS task "wakes up", acknowledges "run" request and waits for the
> right BRS state, then starts filling the next buffer in the "hardware
> queue". While waiting for the right BRS state, it also waits for the
> "pause" RPS signal in case the driver tries to pause the streaming again
> before any data has been received from the demodulator.

Something like this but much simpler should be done for budget card
initialization, a small rps code synchornized with CPU with signals,
that initializes BRS waiting for right moments to upload.

> That code works 100% reliable for me. It took me months, if not years to
> figure out, though, and I must have completely rewritten it at least half a
> dozen times before I got it right ;)

It took me the similar time just to discover the source of problems with
autodetection, it's not continuous work but I had to leave things
aside and return later when I thought I could make some constructive
changes. With certain hints of Michael Hunold (he didn't told me this
exactly) but I started changing code like crazy, cut/pasting blocks of 
lines without thinking, reloading the modules I suddenly I observed this 
behaviour of how time after reset matters, and I though this must be
internal reg's running

Emard