Message ID | 42A3518F.4050408@syphir.sytes.net |
---|---|
State | New |
Headers |
Received: from wproxy.gmail.com ([64.233.184.203]) by www.linuxtv.org with esmtp (Exim 4.34) id 1Df0kM-0000JV-FE for vdr@linuxtv.org; Sun, 05 Jun 2005 21:25:22 +0200 Received: by wproxy.gmail.com with SMTP id 69so1569216wri for <vdr@linuxtv.org>; Sun, 05 Jun 2005 12:24:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:disposition-notification-to:date:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:x-enigmail-version:x-enigmail-supports:content-type:from; b=gK60ZNTAAMfoA2U3rkinTOFfEjbMyMn4GsVCFq8fBOmLNJFTyTqUx0fvqOIeGUQWpAz2YbDX+cVAeUEsqkFmzWriESYg50qlfSaMN/JIQC/m+7Jm4pGDN1eNXuF//iDMgS43lnXpYbtaEusnf0S6AN3HOzhBpeVYHPIZOxv8KoY= Received: by 10.54.3.68 with SMTP id 68mr2778015wrc; Sun, 05 Jun 2005 12:24:48 -0700 (PDT) Received: from nofear.bounceme.net ([4.246.250.255]) by mx.gmail.com with ESMTP id g12sm1162064wra.2005.06.05.12.24.46; Sun, 05 Jun 2005 12:24:48 -0700 (PDT) Received: from [10.1.1.66] (hades [10.1.1.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by nofear.bounceme.net (Postfix) with ESMTP id CE83073534 for <vdr@linuxtv.org>; Sun, 5 Jun 2005 12:24:40 -0700 (PDT) Message-ID: <42A3518F.4050408@syphir.sytes.net> Date: Sun, 05 Jun 2005 12:25:03 -0700 Organization: CooLNeT User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Klaus Schmidinger's VDR <vdr@linuxtv.org> Subject: Re: [vdr] Bug/patch in transfer.c, 1.3.25 References: <200506052103.20520.wolfgang@rohdewald.de> <200506052108.28971.wolfgang@rohdewald.de> In-Reply-To: <200506052108.28971.wolfgang@rohdewald.de> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------060806090503010007030503" From: "C.Y.M" <syphyr@gmail.com> X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: syphir@syphir.sytes.net, Klaus Schmidinger's VDR <vdr@linuxtv.org> List-Id: Klaus Schmidinger's VDR <vdr.linuxtv.org> List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> X-List-Received-Date: Sun, 05 Jun 2005 19:25:22 -0000 Status: O X-Status: X-Keywords: X-UID: 2804 |
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
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.
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,
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
>> >>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.
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
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 >
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
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 >
--- 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) {