Sound drop : sync issue, TV issue?
NewHome › Forums › OSSC, OSSC Pro and DExx-vd isl › OSSC – Discussion and support › Sound drop : sync issue, TV issue?
Tagged: audio sync drop
- This topic has 26 replies, 9 voices, and was last updated September 2, 2021 at 6:14 AM by Fed.
-
AuthorPosts
-
June 3, 2020 at 10:58 PM #38540
I was not able to reproduce the issue using a CRU profile with the attributes you provided… but they do make me question something… why have an horizontal active set to 1440 since running 480px2 mode through the OSSC results in a 1280 horizontal resolution on the TV ?
June 4, 2020 at 3:56 PM #38568Yout TV reports horizontal 1280px resolution when using OSSC with 480p AV1/AV2 input and 480p sampler set to “Auto” or “DTV 480p”? Did your TV then report the same as well with the 1440×960 CRU mode?
June 4, 2020 at 4:56 PM #38571I have tested with both VGA and SCART inputs using a Dreamcast. When using SCART input I am using a retrogamingcables UK RGB Scart set to 480p mode.
Auto, DTV 480p and VESA 640×480@60 are all reported as 1280×960/60Hz by the TV when using an H. active value of 640 and V. active 480.
DTV 480p does output in correct 4:3 format vs the narrower VESA 640×480@60 but reported resolution by TV is identical.
Increasing the H. active value to 687 on the OSSC using DTV 480p I am able to more the TV resolution up to 1374×960. Pushing the value beyond 687 does not cause the resolution to increase any further. (Not sure if this helps in any way but wanted to share just in case)TV reports 1440×960/60hz when using the CRU “profile” you provided.
Another way to get 1440×960/60Hz on the TV is through 480i source as it can be seen here and this also results in sound drops. But as I stated earlier 480p sources result in 1280×960/60Hz.Also wanted to reiterate that irrespective of the line multiplication and resolution output the sound drop can be constantly reproduced when H. Samplerate is of 858… my gut feeling is that troubleshooting should be focused around that point but my poor knowledge does not allow me to make any suggestion on what to look into exactly.
June 4, 2020 at 7:07 PM #38579Can you try this test image? It has IT6613E audio full packet mode enabled – I have a faint recollection that this caused issues in some setup but it’s worth trying if it’d help here.
June 4, 2020 at 9:53 PM #38587Gave it a try but the problem remains sadly.
In my opinion the problem is not coming from the audio data… if something was problematic with how the audio was sent to the TV the problem would be reproducible irrespective of what video settings are being used.
What we are observing here is that as soon as the H. samplerate is set to 858 the TV starts having problems with the incoming signal so for me the questions remains, why are Sony 4k TVs having difficulties with this particular H. samplerate value ? There is something the TV does not like about it but what ?June 4, 2020 at 10:42 PM #38589858 is the standard Htotal for 480p so it’s hard to understand why that would specifically cause problems. In that case you should be able to replicate the issue using the test pattern (which is 480p). To get audio playing on test pattern, connect some audio source to one of the 3.5mm plugs or SCART (without video), then select respective AV input and toggle TX mode to DVI and back to HDMI.
To answer your earlier question on 1440px width, I meant using the DTV mode with default sampling settings (720 H.active). That should be identified by 1440×960 by the TV like with that CRU mode or in the video on the thread you linked.
June 5, 2020 at 12:21 AM #38592You are right, the problem actually only occurs when we have a combination of 480px2, 858 and TX Mode HDMI (problem disappears when using DVI obviously), not simply when using 858. Here is my report posted back in March on GitHub issue #34 :
I would like to report I am experiencing the same audio cuts problem reported here running fw 0.85a.
More specifically when using 480p x2 with H.Samplerate value of 858.00, let me explain :If I switch to 480p passthru (still maintaining H.Samplerate value of 858.00) audio works perfectly fine.
If I stay in 480p x2 mode and change the H.Samplerate value by a few units, audio works perfectly fine but then obviously I get a blurry signal.
If I stay in 480p x2 mode and enable Allowupsample2x then change the H. Samplerate value to 857.95 or 858.25 audio works fine.
Tested on both AV1 and AV3 inputs.I like your idea of the using the test pattern but it seems it is not possible to set it to 480px2.
Regarding my previous statement of not being able to get 1440px width I found out that it was because of my particular Adv. timing settings. When I used the test image you provided that had default Adv. timing settings 480px2 was effectively identified as 1440px by the TV, apologies for the confusion caused by this.
Let me know if you have any other suggestions I could try to hopefully identify the root cause of this issue. For the time being I will happily continue playing the audio out of the OSSC through some external speakers rather than through HDMI.
Once again kiitos for taking the time to look into this particular issue, it is a true pleasure to be able to directly converse with you on this hardware gem you created.June 4, 2021 at 6:15 PM #47772Had the exact same issue with a new Dreamcast VGA cable and 480p x2. Changing the H.samplerate to 859 sorted the audio drops on my Sony TV and the annoying banner popping up so thanks for the tip. Not really sure what this has changed as the picture looks identical and can’t see any blurryness so far. How can I check to see what this has actually done to the image ?
June 5, 2021 at 1:02 AM #47778If you bring up the checkerboard pattern in the 240p test suite you will sadly notice that part of your picture is now blurry.
June 5, 2021 at 9:32 AM #47781I tried switching TX mode to DVI and bypass the OSSC for sound and plug the audio jack straight into my amp, seems fine in this mode so far. Megadrive seems fine in 5x mode and RGB scart, haven’t tried anything else yet though.
June 5, 2021 at 11:50 AM #47789Yep, DVI mode is the only workaround without compromising video quality.
September 2, 2021 at 6:14 AM #49078FYI this problem has disappeared for me using a Retrotink 5x
-
AuthorPosts
- You must be logged in to reply to this topic.