Tivo losing sound - comes back after reboot

[T1voZA]

I did not know that. I had an email from someone who said they had distorted and/or no sound through the PAL tuner using the OzTiVo palmod and found there was a modded version for South Africa on the TiVoZA image which fixed things

The TivoZA image is a modified version of the OzTiVo 1.4 image and contains the oztivo palmod 3.1.

If you have a look at line 470 (palmod.c) of the attached code (in particular the few lines commented out before it) then you will see what could be done to fix the situation. There are basically two options... we could sit in a loop trying to autodetect, or default to NICAM.

Sitting in an autodetect loop may be worthwhile as in areas where there is a poor signal this could help the situation but I think the simpler and possibly better option would be to allow the user to specify their format (using palmod_config as per Peters suggestion) and when the autodetect fails, rather then defaulting to Zweiton Stereo, it could default to the users specified format. Another option could be to allow the users to specify a forced option or alternatively select autodetect which would then run in a loop.

I think the whole PAL-B/G (5.5MHz offset) versus PAL-I (6.0MHz offset) is a red herring as this is only required for the RF Output support.

It's only when using RF that the audio drop-outs occur.

Although if you wish to have a PAL-I (6.0MHz offset) RF Output signal then a change on line 714 (palmod.c) from 0x8a480004 to 0x8a500004 would be required.

It would be nice to be able to set the preferred setting (e.g. PAL-I, PAL-B, etc) via palmod_config. If we were to have a list of available PAL formats, could we base the audio selection on this or would it be best to leave that as a separate setting?

I can recompile the source with these changes if required.

I'm more then happy to help with the compilation but if you're happy to do it then yes please as you're far more familiar with palmod than me.

Just as an aside, would it not be worth pulling out the "tuner_chans.h" file and storing the each countries settings in a separate text file? Going this route would mean that palmod doesn't need to be recompiled whenever new channels are added and users could automatically receive channel updates via the 'upgrade_oztivo' script. The palmod_config could then be adjusted to allow users to specify the file containing the tuner settings for their area.

To make version control easier, would it not be possible just to have the one palmod for all regions with the offsets controlled by palmod_config ?

I think a unified version for all countries with the necessery settings configurable via palmod_config would be a great idea.

It looks like thompson has a different version to the current oztivo palmod 3.2, would be interesting to know what differences there are aside from the "Mark 2" adjustments and the "tuner_chans.h" file. Something else I spotted in thompson's palmod (not sure if it's in palmod 3.2) is the ability to set the widescreen setting via palmod_config

[Darren King]

Yes I agree a fully unified palmod would be great.

Just bear in mind that there has been a lot of tweaking with sound detection for Australian conditions as per post #18 of this thread. Before this there was a real headache of the TiVo losing complete sound when it stayed on the same channel and began to record.

I have the source for this version, included in this post, which was tweaked by Keith Wilkinson (the author of palmod in Australia) who does not frequent these forums but is on the OzTiVo email list.

This extract is what Keith had to say to me in the email that accompanied the updated source about what the important bits are relevant to squashing the sound bug I refer to in post#18 of this thread:

// do sound standard and stereo detection for MSP3410D
if (mspType == MSP3410D && channel >= 0 && a3 == 0x10000) {
if (detect) {
do {
udelay(50000); // wait a bit
I2CReadMsp(MSP_CHIP, READ_DEMOD, 0, AUTODETECT, &standard); // get detection result
} while (standard > 0x7ff); // still active?

if (standard == 0) { // was a standard found?
iicw4(MSP_CHIP, WRITE_DSP, IDENTIFICATION_MODE | 0x003f); // no, reset ident-filter
iicw4(MSP_CHIP, WRITE_DEMOD, STANDARD_SELECT | BG_DUAL_FM); // set sound standard to B/G Dual FM
iicw4(MSP_CHIP, WRITE_DEMOD, AUTO_FM | 0x0800); // select AM/FM sound
iicw4(MSP_CHIP, WRITE_DSP, I2S_SOURCE_MODE | 0x0020); // select I2S source & AM/FM stereo
udelay(100000);
printk("PALMOD: No TV sound standard was detected, default to B/G Dual FM\n");
}
else if (standard <= 0x07ff) // if a standard was found
printk("PALMOD: Sound standard %s was detected\n", soundStandard[standard]);

CheckStereoSource(); // check for stereo source
detect = 0;
}
else if (d_bypass) {
iicw4(MSP_CHIP, WRITE_DSP, IDENTIFICATION_MODE | 0x003f); // reset ident-filter
iicw4(MSP_CHIP, WRITE_DEMOD, STANDARD_SELECT | BG_DUAL_FM); // set sound standard to B/G Dual FM
iicw4(MSP_CHIP, WRITE_DEMOD, AUTO_FM | 0x0800); // select AM/FM sound
CheckStereoSource(); // check for stereo source
write_log = 0;
}
}

For the vast majority of TiVo users there is no change to how palmod operates. For the few people who are experiencing loss of sound on recordings, this does seem to fix the problem.


Apparently the last six lines of code are the vital ones regarding the bugfix.

[sikkie]

Posted by Thomson:
I can recompile the source with these changes if required.

Forgive me if I am impatient, but can we please get a compiled version with the changes. Unfortunately I do not have a Linux box with the correct set-up to be able to do it myself.
Much appreciated.

[thomson]

Forgive me if I am impatient, but can we please get a compiled version with the changes.

We really need to figure out what is going wrong as my version is not the legitimate binary but more of a "tool" to figure out what changes are required to the version being used in the distribution.

If you wish to run the attached binary and then if you experience problems try and make a record of the date/time when you think it occurred and email/post the PALMOD entries from the /var/log/kernel file. Then I can make some changes to the logic and we can test those... and if all works well then we can get Keith to test and update his version.

[sikkie]

Posted by Thomson

I think the whole PAL-B/G (5.5MHz offset) versus PAL-I (6.0MHz offset) is a red herring as this is only required for the RF Output support. Although if you wish to have a PAL-I (6.0MHz offset) RF Output signal then a change on line 714 (palmod.c) from 0x8a480004 to 0x8a500004 would be required.

Thanks for the help, but I think the above change was not done before the attached Palmod compilation. I get a perfect picture, but no sound.
In the Oz palmod version, it is on line 645.
Thanks.

[thomson]

Thanks for the help, but I think the above change was not done before the attached Palmod compilation. I get a perfect picture, but no sound.

You are correct, the previous attached compiled Palmod was more to diagnose the temporary missing sound issue as it has debugging that I use. I have attached a compiled version that should be configured for PAL-I and default to NICAM if a sound source could not be located. (NOTE: This is a different/older codebase to the one supplied with the image).

[sikkie]

Thanks a lot - installed and working, but still do not know whether it will solve all the problems.
Just an interesting point - to download and "reboot" in Puttytel does not reload completely - only a switch off and on does that?

[Darren King]

Shouldn't be. You are effectively resetting the TiVo and causing it to reload all software. Have you got a proven example (ie can you replicate it) where just issuing a "reboot" command acts differently to doing a power cycle?

[sikkie]

A good example was when I have installed the palmod.o above (renamed previous palmod to old and then ftp'd the new palmod), I reboot. I end up having no sound at all. I then switched off and on again and the sound was back!

[petestrash]

That sounds more like a flakey 8v regulator.

Peter.