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:
--- xx 2005-06-05 20:59:08.000000000 +0200 +++ transfer.c 2005-06-05 20:59:16.000000000 +0200 @@ -68,7 +68,7 @@ int Result = 0; #ifdef FW_NEEDS_BUFFER_RESERVE_FOR_AC3 bool GotBufferReserve = false; - int RequiredBufferReserve = KILOBYTE(DvbCardWith4MBofSDRAM ? 288 : 576); + int RequiredBufferReserve = KILOBYTE(DvbCardWith4MBofSDRAM ? 576 : 288); #endif active = true; while (active) {
Program received signal SIGILL, Illegal instruction. [Switching to Thread 557063 (LWP 15183)] 0xb7db542e in main_arena () from /lib/libc.so.6 (gdb) bt #0 0xb7db542e in main_arena () from /lib/libc.so.6 #1 0x0811db65 in cTransfer::Action (this=0xac88870) at transfer.c:84 #2 0x08114d9e in cThread::StartThread (Thread=0xac88990) at thread.c:233 #3 0xb7ea7e51 in pthread_start_thread () from /lib/libpthread.so.0 #4 0xb7ea7ecf in pthread_start_thread_event () from /lib/libpthread.so.0 #5 0xb7d5c92a in clone () from /lib/libc.so.6 (gdb) up #1 0x0811db65 in cTransfer::Action (this=0xac88870) at transfer.c:84 84 if (ringBuffer->Available() < RequiredBufferReserve) { // used to be MAXFRAMESIZE, but the HDTV value of KILOBYTE(512) is way too much here Current language: auto; currently c++ (gdb) p RequiredBufferReserve $1 = 589824 (gdb) p DvbCardWith4MBofSDRAM $4 = false
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:
un 5 21:03:43 mm kernel: DVB: registering frontend 1 (ST STV0299 DVB-S)... 06/05 21:04:11 vdr[19977]: switching to channel 2 Jun 5 21:04:11 mm kernel: dvb-ttpci: warning: timeout waiting in BlitBitmap: -512, 1 06/05 21:04:11 vdr[20098]: transfer thread started (pid=20098, tid=262151) 06/05 21:04:11 vdr[20099]: receiver on device 1 thread started (pid=20099, tid=278536) 06/05 21:04:11 vdr[20100]: TS buffer on device 1 thread started (pid=20100, tid=294921) Jun 5 21:04:16 mm kernel: dvb-ttpci: warning: timeout waiting in BlitBitmap: -512, 1 06/05 21:04:14 vdr[19977]: switching to channel 3 06/05 21:04:14 vdr[20098]: transfer thread ended (pid=20098, tid=262151) 06/05 21:04:14 vdr[20100]: TS buffer on device 1 thread ended (pid=20100, tid=294921) 06/05 21:04:14 vdr[20099]: buffer stats: 92308 (4%) used 06/05 21:04:14 vdr[20099]: receiver on device 1 thread ended (pid=20099, tid=278536) 06/05 21:04:14 vdr[19977]: buffer stats: 317156 (15%) used 06/05 21:04:16 vdr[19977]: switching to channel 4 06/05 21:04:16 vdr[20126]: transfer thread started (pid=20126, tid=311303) 06/05 21:04:16 vdr[20127]: receiver on device 1 thread started (pid=20127, tid=327688) 06/05 21:04:16 vdr[20128]: TS buffer on device 1 thread started (pid=20128, tid=344073) Jun 5 21:04:17 mm kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE Jun 5 21:04:17 mm kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -1 Jun 5 21:04:17 mm kernel: dvb-ttpci: av7110_fw_cmd error -1 Jun 5 21:04:18 mm kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE Jun 5 21:04:18 mm kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -1 06/05 21:04:18 vdr[19983]: channel 7 (ProSieben) event 20:16 'Tiger & Dragon' status 4 06/05 21:04:20 vdr[20126]: clearing device because of consecutive poll timeouts 06/05 21:04:21 vdr[20126]: clearing device because of consecutive poll timeouts
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,
--- 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) {
On Sonntag 05 Juni 2005 21:25, C.Y.M wrote:
Maybe you want to give the latest revision of the firmware a try:
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:
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:
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
-
C.Y.M -
Dr. Werner Fink -
Wolfgang Fritz -
Wolfgang Rohdewald