Bug/patch in transfer.c, 1.3.25

Message ID 42A3518F.4050408@syphir.sytes.net
State New
Headers

Commit Message

C.Y.M June 5, 2005, 7:25 p.m. UTC
  Wolfgang Rohdewald wrote:
> On Sonntag 05 Juni 2005 21:03, Wolfgang Rohdewald wrote:
> 
>>this might explain why vdr often dies when switching from/to a channel with DD sound -
>>like ZDF and Pro 7, at least I hope so. Not tested yet, but the bug seems clear enough:
> 
> 
> Nope, the problems are still there:

Maybe you want to give the latest revision of the firmware a try:

http://www.suse.de/~werner/test_av.tar.bz2

The recommended change to transfer.c for the new firmware is attached.

Best Regards,
  

Comments

Wolfgang Rohdewald June 6, 2005, 1:24 p.m. UTC | #1
On Sonntag 05 Juni 2005 21:25, C.Y.M wrote:
> Maybe you want to give the latest revision of the firmware a try:
> 
> http://www.suse.de/~werner/test_av.tar.bz2

I am already using that one. It makes no difference to 261d regarding
the errors. However when changing channels the tone comes much faster.
 
> The recommended change to transfer.c for the new firmware is attached.

The net result seems to be the same for me: use 288k instead of 576.
I don't have the 4MB extension. So this cannot help.

But I could get rid of the error messages by inserting an msleep(30)
somewhere in the driver (2.6.12-rc5 unmodified). They still happen but
much more seldom. See my post on the linux-dvb mailing list.
  
C.Y.M June 6, 2005, 2:36 p.m. UTC | #2
Wolfgang Rohdewald wrote:
> On Sonntag 05 Juni 2005 21:25, C.Y.M wrote:
> 
>>Maybe you want to give the latest revision of the firmware a try:
>>
>>http://www.suse.de/~werner/test_av.tar.bz2
> 
> 
> I am already using that one. It makes no difference to 261d regarding
> the errors. However when changing channels the tone comes much faster.
>  

OK, just as long as you updated the firmware from within a few weeks ago then
you should have the new one.  The version inside the "new" firmware did not
change from 26d (so it may be a little confusing from just looking at it).

> 
>>The recommended change to transfer.c for the new firmware is attached.
> 
> 
> The net result seems to be the same for me: use 288k instead of 576.
> I don't have the 4MB extension. So this cannot help.
> 

If you notice that patch I sent in the previous mail, it undefines
"FW_NEEDS_BUFFER_RESERVE_FOR_AC3", so, the line you are changing would not even
be used.  It seems that the "new" version of 26d does not need preset buffer
reserves.

--SNIP--

 #ifdef FW_NEEDS_BUFFER_RESERVE_FOR_AC3
   bool GotBufferReserve = false;
-  int RequiredBufferReserve = KILOBYTE(DvbCardWith4MBofSDRAM ? 288 : 576);
+  int RequiredBufferReserve = KILOBYTE(DvbCardWith4MBofSDRAM ? 576 : 288);
 #endif

--SNIP--

> But I could get rid of the error messages by inserting an msleep(30)
> somewhere in the driver (2.6.12-rc5 unmodified). They still happen but
> much more seldom. See my post on the linux-dvb mailing list.
> 

2.6.11.11 with latest CVS of dvb-kernel would be my recommendation.

Regards,
  
Dr. Werner Fink June 6, 2005, 3:26 p.m. UTC | #3
On Mon, Jun 06, 2005 at 07:36:47AM -0700, C.Y.M wrote:
> Wolfgang Rohdewald wrote:
> > On Sonntag 05 Juni 2005 21:25, C.Y.M wrote:
> > 
> >>Maybe you want to give the latest revision of the firmware a try:
> >>
> >>http://www.suse.de/~werner/test_av.tar.bz2
> > 
> > 
> > I am already using that one. It makes no difference to 261d regarding
> > the errors. However when changing channels the tone comes much faster.
> >  
> 
> OK, just as long as you updated the firmware from within a few weeks ago then
> you should have the new one.  The version inside the "new" firmware did not
> change from 26d (so it may be a little confusing from just looking at it).

Hmmm ... there _are_ changes between 0x261d and
http://www.suse.de/~werner/test_av.tar.bz2 which is a first
public test for a 0x261e ;)

AV Synchronization should go much faster even within transfer mode.


       Werner
  
C.Y.M June 6, 2005, 3:55 p.m. UTC | #4
>>
>>OK, just as long as you updated the firmware from within a few weeks ago then
>>you should have the new one.  The version inside the "new" firmware did not
>>change from 26d (so it may be a little confusing from just looking at it).
> 

Sorry, when I said "26d", I meant "261d". :) But I did not notice a change in
the version string with the latest public test.

> 
> Hmmm ... there _are_ changes between 0x261d and
> http://www.suse.de/~werner/test_av.tar.bz2 which is a first
> public test for a 0x261e ;)
> 
> AV Synchronization should go much faster even within transfer mode.
> 

Yes, it seems to work great. :) I guess this new version of the firmware uses a
different method for A/V sync.  It uses the same technology as the PCM sync now?

Thanks.
  
Dr. Werner Fink June 6, 2005, 4:20 p.m. UTC | #5
On Mon, Jun 06, 2005 at 08:55:21AM -0700, C.Y.M wrote:
> 
> >>
> >>OK, just as long as you updated the firmware from within a few weeks ago then
> >>you should have the new one.  The version inside the "new" firmware did not
> >>change from 26d (so it may be a little confusing from just looking at it).
> > 
> 
> Sorry, when I said "26d", I meant "261d". :) But I did not notice a change in
> the version string with the latest public test.
> 
> > 
> > Hmmm ... there _are_ changes between 0x261d and
> > http://www.suse.de/~werner/test_av.tar.bz2 which is a first
> > public test for a 0x261e ;)
> > 
> > AV Synchronization should go much faster even within transfer mode.
> > 
> 
> Yes, it seems to work great. :) I guess this new version of the firmware uses a
> different method for A/V sync.  It uses the same technology as the PCM sync now?

Yes and no.  Depends on the situation, e.g. sources with low
rates (e.g. transfer mode) is handled different as sources with
high rates (e.g. from HD with UDAM enabled).

         Werner
  
Wolfgang Fritz June 6, 2005, 5:36 p.m. UTC | #6
Dr. Werner Fink wrote:

> 
> AV Synchronization should go much faster even within transfer mode.
> 
> 

Does this apply to stereo too? From a thread in the VDR portal I got the
impression it improves AC3 only.

And would it improve the problem with desynced A/V when starting a
replay in VDR?

Wolfgang

>        Werner
>
  
Dr. Werner Fink June 6, 2005, 5:45 p.m. UTC | #7
On Mon, Jun 06, 2005 at 07:36:29PM +0200, Wolfgang Fritz wrote:
> Dr. Werner Fink wrote:
> 
> > 
> > AV Synchronization should go much faster even within transfer mode.
> > 
> > 
> 
> Does this apply to stereo too? From a thread in the VDR portal I got the
> impression it improves AC3 only.
> 
> And would it improve the problem with desynced A/V when starting a
> replay in VDR?


You may test this and report then, feedback is required :)


      Werner
  
Wolfgang Fritz June 6, 2005, 7:23 p.m. UTC | #8
Dr. Werner Fink wrote:
> On Mon, Jun 06, 2005 at 07:36:29PM +0200, Wolfgang Fritz wrote:
>>Dr. Werner Fink wrote:
>>
>>>AV Synchronization should go much faster even within transfer mode.
>>>
>>>
>>Does this apply to stereo too? From a thread in the VDR portal I got the
>>impression it improves AC3 only.
>>
>>And would it improve the problem with desynced A/V when starting a
>>replay in VDR?
> 
> 
> You may test this and report then, feedback is required :)
>

First impression is promising. I could not see/hear a A/V desync when
starting a VDR in first tests, but my number of recordings is quite
small. The jitter at the beginning seems to be shorter too (but this has
already improved a lot since I switched to kernel 2.6 and DVB CVS).

I often had desynced A/V with recordings of the Tagesschau which I
record daily but delete after viewing, so I'll check that the next days.

Thank you for the good work,

Wolfgang

>
>       Werner
>
  

Patch

--- vdr-1.3.25/transfer.c.orig	2005-05-30 11:31:05.000000000 -0700
+++ vdr-1.3.25/transfer.c	2005-05-30 11:32:13.000000000 -0700
@@ -54,12 +54,12 @@ 
      }
 }
 
-#define FW_NEEDS_BUFFER_RESERVE_FOR_AC3
-#ifdef FW_NEEDS_BUFFER_RESERVE_FOR_AC3
+//#define FW_NEEDS_BUFFER_RESERVE_FOR_AC3
+//#ifdef FW_NEEDS_BUFFER_RESERVE_FOR_AC3
 //XXX This is a very ugly hack to allow cDvbOsd to reduce the buffer
 //XXX requirements in cTransfer if it detects a 4MB full featured DVB card.
 bool DvbCardWith4MBofSDRAM = false;
-#endif
+//#endif
 
 void cTransfer::Action(void)
 {