marqs85

@siwy102: so there is some relationship between audio frequency and occurrence of this issue? Sounds very strange, but I had similar problem with a PC sound card 20 years ago....

Sampling presets are already separate for 240p and 288p so I suppose you mean splitting "240p/288p proc" into two? It is like that on OSSC Pro, I can consider this...

It might be that the modes have different hsync width which may affect the position on a CRT while OSSC only uses leading sync edge as reference like many digitizers....

The sync in 256col mode is slightly shorter according to a measurement. If backporch has identical length in both modes, delay from leading sync edge to picture border is higher...

The upside with different hsync length is that it's possible to reliably detect which mode MD is outputting (unless the signal goes through a sync conditioner etc.). On OSSC Pro...

You can try reducing H.active in DTV 480p mode, but the TV may not like that either.

Any more details on the TV model? Also, could you try 0.79-0.81 to help pinpointing the change that might affect audio compatibility.

I checked that there was no audio related changes between 0.81 and 0.82 so I guess this might be related to timing. Have you tried enabling "Full TX setup" in...

I2C transactions are actually hw-controlled, but any delays between transactions and for other controls (e.g. HDMI TX chip) are generated using SW delays which indeed might have changed a bit...

I found a bug in the code where uninitialized data ends up in the audio infoframe. I made a test [firmware](http://www.niksula.hut.fi/~mhiienka/tmp/ossc_0.82-aud-t.bin) with the fix, feel free to test in your...