Did we try the Audio Infoframe again after updating flexspin?
Too much sample jitter (maybe try a non-resampled 48kHz signal)
???
To test the latter, you'd replace both uses of video.CLK_MULTIPLIER*3*4*6*6 with video.SAMPLE_OUT_PERIOD in vgatest. However, that isn't properly handled by the init code currently, so you additionally need to make sure to add
@Wuerfel_21 , I just checked your sample rate in the output capture. Seems good for 48kHz so buffers shouldn't be overflowing.
I captured 524200 pixels worth and your pixel clock frequency is 24167829 * 14/10 = 33.8349606MHz
524200/33834960.6 = 15.49285ms
With 48kHz LPCM audio we should get 48000*0.01549285 stereo samples in this time which is 743.66 stereo samples. When I grepped the output for each audio "Sample" line I see a count of 744. So pretty much as expected and seems your code is computing sample rates well. Inter-arrival time also seems okay with samples arriving at fairly regular intervals vs the pixel sample number shown as the first number on the "DataGuard" line after each sample in the final log below. Looks good.
Still want to figure out why it's not working. I wonder if there is something else needed in the channel status block...? Like which samples are being sent for this channel status block e.g L+R. (bits 20-23 of byte two) See : https://law.resource.org/pub/in/bis/S04/is.iec.60958.3.2003.pdf
Also checked the clock regen packet arrival times. Seems like they are being sent at regularly spaced intervals too ~35k pixels apart or ~1ms which would be what we wanted.
@rogloh said:
Still want to figure out why it's not working. I wonder if there is something else needed in the channel status block...? Like which samples are being sent for this channel status block e.g L+R. (bits 20-23 of byte two)
The spec certainly doesn't require those bits, but feel free to try them out.
Did we try the Audio Infoframe again after updating flexspin?
I'm still using that in my test code instead of the Video AVI InfoFrame. I'm running flexspin
Version 7.0.0-beta-v6.9.7-65-g3914edfd Compiled on: Sep 9 2024
Too much sample jitter (maybe try a non-resampled 48kHz signal)
???
To test the latter, you'd replace both uses of video.CLK_MULTIPLIER*3*4*6*6 with video.SAMPLE_OUT_PERIOD in vgatest. However, that isn't properly handled by the init code currently, so you additionally need to make sure to add
into the init code to make sure the resampler is bypassed.
One thing I noticed just now which seemed weird. These were the sample times in pixels at which you sent out audio frames. Most are sent every 1075 pixels which is your line rate. Once you didn't send a packet making it 2150 which I guess is fine and one time the count was 1070 pixels. I don't really get the second case as to why it would be 1070 pixels.
Oh, looks like just prior to this we lost clock sync somehow and accumulated 60 "10b" bits which is 50 extra or 5 pixels worth. I see this is happening a few times in the file. So something is causing a capture problem - maybe my compression is messing up somewhere at boundaries... will have to check this.
Hmm, so everything's to spec, back to square one. I really have nothing else. Maybe try different bits in the channel status... (most of the audio infoframe HAS to be zero according to spec)
Plasma TVs are kind of ancient these days, right?
Was googling and find people are having problems with the HDMI inputs going bad.
Or, maybe only takes encrypted inputs?
My OLED is sometimes picky, but seemed to take this fine (although does need the 5V)
Plasma TVs are kind of ancient these days, right?
Was googling and find people are having problems with the HDMI inputs going bad.
Or, maybe only takes encrypted inputs?
I guess that could be possible? If I can find a device that doesn't encrypt audio that works that would kill that theory, but I've only got a PS3, Bluray/DVD a PVR and AppleTV plus Apple laptop to feed it. I'm guessing all of those would encrypt everything. If I can find something to capture an unencrypted bitstream that I know works with audio somehow I might be able to find out what the difference is that stops it from working. I also can't get my AVR to decode the audio from the P2 HDMI either - just video only is displayed.
My OLED is sometimes picky, but seemed to take this fine (although does need the 5V)
Yes my AVR needs the 5V to detect the signal. The plasma works without it.
Does it have other hdmi inputs to try?
It does, perhaps I can try them. Or dig up and read the manual and see if there are any inputs that work differently to others. The menu system options are very limited on it.
Computers normally don't have HDCP enabled because the handshake takes forever etc. But I wouldn't trust an Apple machine to do the sane thing, so shrug. If you have a computer that can run Linux, I think that normally can't do HDCP at all. DVD player also kinda shouldn't do it if the disc doesn't have copy protection (-> just burn one), but that's a maybe. PS3 OTOH is always HDCP because Sony hates you. (no other game console does this - PS4, Nintendo Switch, etc should be fine, might need to set it in the settings). The real way though is to grab a certain kind of chinesium 1-to-2 cable splitter box. The handshake protocol is only designed for a single sink, so the box does the handshake with the source and then just doesn't bother encrypting the output again. People used to buy these to make youtube vids of PS3 games.
@Wuerfel_21 said:
The real way though is to grab a certain kind of chinesium 1-to-2 cable splitter box. The handshake protocol is only designed for a single sink, so the box does the handshake with the source and then just doesn't bother encrypting the output again. People used to buy these to make youtube vids of PS3 games.
This is interesting. I used to have a 1 input to 2 output cable splitter that might have worked like that but it fried, I've since replaced it with a 2 output from 4 inputs independently selectable per output which I guess is probably able to do the handshake all the way through. https://www.jaycar.com.au/concord-4x2-4k-hdmi-matrix-switcher-splitter/p/AC5012
I do have this too, but I think it's likely mostly dumb and passes through to both somehow with a simple amplifier but I might be wrong. I'll add it into the path to see if it helps. https://www.aliexpress.com/item/1005007174659162.html
I found the cause of that occasional clock sync loss in the TMDS frame capture. It was happening on 256kB boundaries and was due to a couple of lines of code in the streamercog code I'd removed by mistake in some edits. These were originally there to align the FIFO streamer input buffers to the 64 byte block boundary. This used to work fine before with that code but regressed recently after that was changed. Now fixed in this update. After capturing again, the 10b input patterns per channel are now always 10 bits in length apart from the first couple of samples while it aligns itself initially to the stream using the rising edge of the TMDS clock channel signal as the reference.
Just figured out that Raspi HDMI doesn't use HDCP by reading some forums on Raspi. So I should be able to feed that into the Pioneer plasma TV HDMI input to see if I can get audio from it. Will report back on the finding in this post once I do that test.
"HDCP support is not implemented on the SoC used in the Raspberry Pi SBC, nothing has changed in 8 years.
It was only implemented on other devices like the ROKU which used the BCM2835 SoC."
UPDATE: yep, sound is working - I hear system sounds in the Raspi audio settings and test menu etc.
This proves this TV can take unencrypted streams. I just wish I knew what was so different about this vs the P2 output. I need to find a way to capture the HDMI symbols from the Pi now. My Adafruit HDMI to LCD board based on the TFP401 chip has arrived but that only decodes to RGB24 and doesn't expose the control or TERC4 symbols AFAIK. Maybe I can reverse engineer it from the LSnibble of the colour?
I wouldn't assume that you get any kind of valid outputs from the RGB pins during a data period. Also, take care of the EDID ROM. If it doesn't indicate HDMI/Audio support, no data will be sent.
@Wuerfel_21 said:
I wouldn't assume that you get any kind of valid outputs from the RGB pins during a data period. Also, take care of the EDID ROM. If it doesn't indicate HDMI/Audio support, no data will be sent.
Yeah I think this TFP401 chip is DVI aware only. So I'm not sure what it'll do with TERC4 10b symbols if they are different from regular RGB encoded bytes. I'm going to start looking into the EDID stuff. I think there are some examples supplied by Adafruit.
UPDATE: in fact I reckon I could pretend this device was my PlasmaTV by using its EDID. The Pi driving it should then think it talks to a plasma, but at the default resolution setup by the Pi which might be too high a speed to capture. I sort of want it to use SDTV or 640x480p type resolutions so I could clock it into the P2 and store to PSRAM so I'll need to figure that out first.
This is actually looking pretty promising. I just programmed the EDID I2C EEPROM on that new Adafruit TFP401 translation board I received recently with my plasma TV settings that I extracted previously. I then fed this board with @Wuerfel_21 's HDMI video driver output from the P2 Edge.
Until I fully wire in the parallel RGB data lines I won't know what exactly the TFP401 is sending out here but I do see it drop the DE signal at the back end of the HSYNC region and this is very likely to be where the data island exists IMO. In theory if DE is high the chip should decode the TERC4 symbols as video and try to output 24 bit RGB in this portion but I will have to wait to prove it by wiring it up fully. If true this should let me capture the Raspi HDMI output and see what on earth its audio stream looks like compared to Ada's audio format. That's the dream anyway.
Here's a quick scope image I took of the DE signal (yellow) and Hysnc pin (+ve sync) output (blue) by the TFP401 chip. I also checked the clock signal and got something around 33.8MHz which is expected too.
This second image has me very excited as it shows bit 2 of the TMDS channel 0 (BLUE[2]) in the data island which is meant to start out as a serial bitstream of 10111111.... with a bunch of 1's following and I can sort of see that here. If the data is valid I'll be able to capture it nicely assuming my signal integrity is okay at 33MHz or thereabouts. I plan to use 3 lots of 2x6 IDE ribbon cables plugged into P2-EVAL headers in 3 groups for RGB plus the clock and sync stuff on another 4th header. If it's too noisy to capture like this I'll have to spin a simple PCB to fanout the FPC into the P2 IO pins.
Posting here in particular as it relates to your HDMI audio driver. I was able to get the HDMI audio related items of interest captured on a RasPi for analysis. Here's a big dump of info:
Guess what @Wuerfel_21 ? For HDMI audio output from the RasPi the CTS value actually changes in the clock regen packet by a few clocks here and there, it's not static! This could be important for locking/jitter issues. The "N" value does remain the same throughout the capture though. Interestingly it's not using the recommended N value for 48kHz audio but something exactly 11/12 of it. Weird. Maybe something internal to Broadcom. Not sure.
❯ grep -A1 CTS out | more
SubPkt0 N = 5632 CTS = 26938
SubPkt1 N = 5632 CTS = 26938
SubPkt2 N = 5632 CTS = 26938
SubPkt3 N = 5632 CTS = 26938
23768 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
--
SubPkt0 N = 5632 CTS = 26940
SubPkt1 N = 5632 CTS = 26940
SubPkt2 N = 5632 CTS = 26940
SubPkt3 N = 5632 CTS = 26940
51040 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
--
SubPkt0 N = 5632 CTS = 26937
SubPkt1 N = 5632 CTS = 26937
SubPkt2 N = 5632 CTS = 26937
SubPkt3 N = 5632 CTS = 26937
77824 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
--
SubPkt0 N = 5632 CTS = 26940
SubPkt1 N = 5632 CTS = 26940
SubPkt2 N = 5632 CTS = 26940
SubPkt3 N = 5632 CTS = 26940
104640 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
--
SubPkt0 N = 5632 CTS = 26939
SubPkt1 N = 5632 CTS = 26939
SubPkt2 N = 5632 CTS = 26939
SubPkt3 N = 5632 CTS = 26939
132256 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
--
Also I captured the line after each clock regen packet which shows the sample number and can be used to see how often it's sent. Most of the time it's the last packet in the island, but occasionally it has another TERC4 encoded packet after it as shown by the single different line below.
❯ grep -A1 CTS out | grep Data
23768 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
51040 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
77824 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
104640 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
132256 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
159040 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
185824 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
212608 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
239424 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
266208 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
293824 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
320608 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
347392 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
374176 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
400992 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
428608 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
455392 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
482176 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
508960 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
535604 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
562544 Data:-> DataGuard +V +H 01010101 01010101 10111010 11010 5555ba
590176 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
616960 Data:-> TERC4 0000_0000_1011 +V +H 01011011 01011011 10110101 11110 5b5bb5
643744 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
670528 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
697344 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
Here are the times in pixel clocks at which these regen packets get send out and gaps between them. About 1msec.
Here's an Audio InfoFrame being sent. Only channel count is set here and encoded as %001 = 2 channels.
Here's the accumulated channel status being sent (LSbit=last of the 192 bits printed in this output). Its data remained static throughout the capture (repeating 66 times over).
❯ grep "count=191" -A 8 out | more
Sample 0 right = FFE300, left = 000000, flags=80 Pr=1 Cr=0, Pl=0 Cl=0 ParityR=1 ParityL=0 Channel status count=191
L Channel Status:
00000000_00000000_00000000_00000000_00000000_00000000_00000000_00000000_
00000000_00000000_00000000_00000000_00000000_00000000_00000000_00000000_
00000000_00000000_00000000_00000010_00000010_00000000_10000010_00000100_
R Channel Status:
00000000_00000000_00000000_00000000_00000000_00000000_00000000_00000000_
00000000_00000000_00000000_00000000_00000000_00000000_00000000_00000000_
00000000_00000000_00000000_00000010_00000010_00000000_10000010_00000100_
I looked up the bits that were set.
No copyright, consumer LPCM. Category code= 130
Doesn't take source or channel numbers into account
Sampling freq=0010 =48kHz, level2 clock
16bit samples, sampling frequency not indicated.
These might also be rather important to set correctly for some devices that use them....? Unfortunately think your driver code currently limits the SPDIF channel status data source bits to 32 bits only, otherwise I could try to setup this same channel status and try feeding my Plasma again. Maybe it's important for it to know the sample size before it tries to play the data and keeps it muted until then...?
Attached is the raw 32 bit LOGFILE I used for this. The decoded output is a massive 752MB so I didn't bother to include it but if you want to also take a look you can generate the decoded output text file with my latest tm.c file posted in Video capture thread using ./tm -l < LOGFILE > out Note the minus L option (lowercase) is required to decode P2 RGB longs instead of TMDS bits.
Also for fun here is the first video frame in the screen grab from the Pi400 Ubuntu HDMI output after I clicked the GUI mouse button and collected the digital HDMI audio that played from it. grep -A 720 Video out | grep Data: | grep -v VideoGuard | cut -c 95-102 | ./ppm 720 576 > roger2.ppm
Found a quick way to hack NeoVGA.spin to send a 34th bit of 1 in the S/PDIF channel status - only needed one instruction and the Z flag. Hopefully the path isn't compromised by the extra instruction and flag use, didn't want to have to go count clocks etc to see how tight it is. Hardcoded bit 33 for now as a "1" as shown in the capture above. Relies on the fact that bit0 is treated same as bit32 in the S/PDIF status long.
After some mods to the code and applying 5V I can hear an audio tone on my Plasma but it is chopped up and mutes randomly. Sounds like Morse code signalling about 100-800ms bursts of audio. Something is still not correct.
I also backed out these changes and again send only a video InfoFrame and the original SPDIF pattern and I still hear the random audio tone bursts (constant frequency tone but also quite a bit of noise). Huh? Can't figure it out as I've already applied 5V to the HDMI board in the past to see if that made a difference and at the time I did that I find it only let me get a video signal through the AVR to a projector (no sound) and had no effect on the Plasma TV at the time. Now it seems to have an effect. Maybe one of the later github updates actually made a difference but I didn't retest with 5V after taking it perhaps. Will retest the AVR now to see if I get audio from that too with 5V running the same code and report back....
Update:
Just tested the AVR, and I do get sound there too now which is certainly different to my testing before, but I get the same choppy Morse code output effect as the Plasma does.
I'm attaching the exact versions of vgatest.spin2, NeoVGA.spin2 and config.spin2 in this zip file below to see if they are somehow different to what you use and what works for you @Wuerfel_21
At least there is some sort of progress here. Could be packet timing related with jitter or PLL lock issues.
Update2:
In reading through some of the older posts I noticed this, which I've not yet tried as I didn't understand that code. Perhaps it may relate to the problem I have?
@Wuerfel_21 said:
Too much sample jitter (maybe try a non-resampled 48kHz signal)
???
To test the latter, you'd replace both uses of video.CLK_MULTIPLIER*3*4*6*6 with video.SAMPLE_OUT_PERIOD in vgatest. However, that isn't properly handled by the init code currently, so you additionally need to make sure to add
into the init code to make sure the resampler is bypassed.
Update3:
THAT'S IT!!!!! I now have a solid tone on both Plasma and AVR. Needed 5V and this resampler bypass change and something else that must have happened along the way.
I guess some HDMI devices can compensate for your resampling stuff while others don't like it so much.
@rogloh So it's just bit33 that needs setting? Try applying just that to the plain video-nextgen branch. Resample bypass making it work sounds more like your code got shreked along the way.
(EDIT: Though the correct thing would be to indicate 24 bit sample length - that's what comes out after resampling)
It's good to get audio at all, but the resampler needs to be enabled for actual use, you probably shouldn't rawdog 55kHz from the YM2610 into the HDMI link.
@Wuerfel_21 said:
@rogloh So it's just bit33 that needs setting? Try applying just that to the plain video-nextgen branch. Resample bypass making it work sounds more like your code got shreked along the way.
I don't think any SPDIF changes are needed at all unless the value in the clock regen branch differed from next-gen (ok just checked - it's the same). After hearing something initially following a change I backed them all out in the end and it still worked. What cleaned up the audio was the resampler removal along with 5V being present and maybe some other recent change. But I will try your latest next-gen branch to see if that works now.
(EDIT: Though the correct thing would be to indicate 24 bit sample length - that's what comes out after resampling)
I expect if it specifies 16 or defaults to 16 bits it just takes the upper bits of the 24 bit value of the sample. So you may lose little quality but should still work okay.
@rogloh said:
After hearing something initially following a change I backed them all out in the end and it still worked.
???????? Magic TV gremlins are laughing at us right now.
@rogloh said:
I expect if it specifies 16 or defaults to 16 bits it just takes the upper bits of the 24 bit value of the sample. So you may lose little quality but should still work okay.
Nope top of video-nextgen branch which I just downloaded clean from GitHub still doesn't work with 5V and my Plasma. No audio at all. So it's seems to be something to do with the resampling or clock regen timing stuff. I'll try to nominate 16 and then 24 bit audio in the SPDIF to see what that does just in case...
Update: set bit 33 in SPDIF channel status for this video-nextgen branch and got broken audio tone again. Will now try setting bits 35-32 to %1011 (24 bit samples)
Also starting to think there might be some randomness to this if variables are not being cleared at the start and some initial phases might work and some might not...initializing those 3 variables to zero seemed to massively help before.
Ah, enlightening, I guess it just has to be set once and then it rember 💀
Also, verify behaviour with the actual full fat NeoYume running. In terms of sample arrival timing, there's this line: incmod temp3,#2-1 wc ' This limits it to encoding 2 samples per scanline, which ought to be enough. If you set 3-1, that might change something.
@Wuerfel_21 said:
Ah, enlightening, I guess it just has to be set once and then it rember 💀
Yeah that seems to be the outcome. I change it and it fixes the TV, then I revert it and it still works. LOL.
I just tried to set bits 35-32 to %1101 pattern with this code and now no audio again. Bizarro. Maybe the channel status is the culprit in the end...? Or maybe I introduced too many instructions.
This was my change to your code:
Also, verify behaviour with the actual full fat NeoYume running. In terms of sample arrival timing, there's this line: incmod temp3,#2-1 wc ' This limits it to encoding 2 samples per scanline, which ought to be enough. If you set 3-1, that might change something.
That is too many instructions. When you add a scanfunc call you need to change the time compensation.
I'll make a proper change to that end later(TM) (aka in a few hours). Sadly very localized busy-ness here.
@Wuerfel_21 said:
That is too many instructions. When you add a scanfunc call you need to change the time compensation.
I'll make a proper change to that end later(TM) (aka in a few hours). Sadly very localized busy-ness here.
Ok, yeah wasn't sure about that. I just tried the incmod suggestion in NeoYume and it didn't make a difference (was using the bit33=1 in that test too in the hopes it might help as well). No audio.
Comments
So back to square one.
Possibly remaining issues:
To test the latter, you'd replace both uses of
video.CLK_MULTIPLIER*3*4*6*6withvideo.SAMPLE_OUT_PERIODin vgatest. However, that isn't properly handled by the init code currently, so you additionally need to make sure to addmov resample_ratio_int,#0 mov resample_ratio_frac,#0 mov resample_dejitter_period,#0into the init code to make sure the resampler is bypassed.
@Wuerfel_21 , I just checked your sample rate in the output capture. Seems good for 48kHz so buffers shouldn't be overflowing.
I captured 524200 pixels worth and your pixel clock frequency is 24167829 * 14/10 = 33.8349606MHz
524200/33834960.6 = 15.49285ms
With 48kHz LPCM audio we should get 48000*0.01549285 stereo samples in this time which is 743.66 stereo samples. When I grepped the output for each audio "Sample" line I see a count of 744. So pretty much as expected and seems your code is computing sample rates well. Inter-arrival time also seems okay with samples arriving at fairly regular intervals vs the pixel sample number shown as the first number on the "DataGuard" line after each sample in the final log below. Looks good.
Still want to figure out why it's not working. I wonder if there is something else needed in the channel status block...? Like which samples are being sent for this channel status block e.g L+R. (bits 20-23 of byte two) See : https://law.resource.org/pub/in/bis/S04/is.iec.60958.3.2003.pdf
Done
Sample 0 right = A66096, left = A66096, flags=00 Pr=0 Cr=0, Pl=0 Cl=0 ParityR=0 ParityL=0 Channel status count=0
136 10 :-> DataGuard +V +H 0100110011 0100110011 1011000011 0000011111
137 10 :-> DataGuard +V +H 0100110011 0100110011 1011000011 0000011111
Sample 0 right = B165AB, left = B165AB, flags=88 Pr=1 Cr=0, Pl=1 Cl=0 ParityR=1 ParityL=1 Channel status count=1
Sample 1 right = BD7255, left = BD7255, flags=00 Pr=0 Cr=0, Pl=0 Cl=0 ParityR=0 ParityL=0 Channel status count=2
1211 10 :-> DataGuard +V +H 0100110011 0100110011 1011000011 0000011111
1212 10 :-> DataGuard +V +H 0100110011 0100110011 1011000011 0000011111
Sample 0 right = CA5E72, left = CA5E72, flags=88 Pr=1 Cr=0, Pl=1 Cl=0 ParityR=1 ParityL=1 Channel status count=3
2286 10 :-> DataGuard V- +H 0100110011 0100110011 1001110001 0000011111
2287 10 :-> DataGuard V- +H 0100110011 0100110011 1001110001 0000011111
Sample 0 right = D7FCA1, left = D7FCA1, flags=88 Pr=1 Cr=0, Pl=1 Cl=0 ParityR=1 ParityL=1 Channel status count=4
Sample 1 right = E6210D, left = E6210D, flags=00 Pr=0 Cr=0, Pl=0 Cl=0 ParityR=0 ParityL=0 Channel status count=5
3361 10 :-> DataGuard V- +H 0100110011 0100110011 1001110001 0000011111
3362 10 :-> DataGuard V- +H 0100110011 0100110011 1001110001 0000011111
Sample 0 right = F49C37, left = F49C37, flags=00 Pr=0 Cr=0, Pl=0 Cl=0 ParityR=0 ParityL=0 Channel status count=6
4436 10 :-> DataGuard V- +H 0100110011 0100110011 1001110001 0000011111
4437 10 :-> DataGuard V- +H 0100110011 0100110011 1001110001 0000011111
Sample 0 right = 033DD6, left = 033DD6, flags=00 Pr=0 Cr=0, Pl=0 Cl=0 ParityR=0 ParityL=0 Channel status count=7
Sample 1 right = 11D519, left = 11D519, flags=00 Pr=0 Cr=0, Pl=0 Cl=0 ParityR=0 ParityL=0 Channel status count=8
5511 10 :-> DataGuard V- +H 0100110011 0100110011 1001110001 0000011111
5512 10 :-> DataGuard V- +H 0100110011 0100110011 1001110001 0000011111
Sample 0 right = 203090, left = 203090, flags=88 Pr=1 Cr=0, Pl=1 Cl=0 ParityR=1 ParityL=1 Channel status count=9
6586 10 :-> DataGuard V- +H 0100110011 0100110011 1001110001 0000011111
6587 10 :-> DataGuard V- +H 0100110011 0100110011 1001110001 0000011111
Sample 0 right = 2E1F0D, left = 2E1F0D, flags=00 Pr=0 Cr=0, Pl=0 Cl=0 ParityR=0 ParityL=0 Channel status count=10
Sample 1 right = 3B7339, left = 3B7339, flags=00 Pr=0 Cr=0, Pl=0 Cl=0 ParityR=0 ParityL=0 Channel status count=11
7661 10 :-> DataGuard V- +H 0100110011 0100110011 1001110001 0000011111
7662 10 :-> DataGuard V- +H 0100110011 0100110011 1001110001 0000011111
Sample 0 right = 480163, left = 480163, flags=88 Pr=1 Cr=0, Pl=1 Cl=0 ParityR=1 ParityL=1 Channel status count=12
8736 10 :-> DataGuard V- +H 0100110011 0100110011 1001110001 0000011111
8737 10 :-> DataGuard V- +H 0100110011 0100110011 1001110001 0000011111
Also checked the clock regen packet arrival times. Seems like they are being sent at regularly spaced intervals too ~35k pixels apart or ~1ms which would be what we wanted.
❯ grep regen -A5 out2 |more
Clock regen packet
SubPkt0 N = 6400 CTS = 35245
SubPkt1 N = 6400 CTS = 35245
SubPkt2 N = 6400 CTS = 35245
SubPkt3 N = 6400 CTS = 35245
10886 10 :-> DataGuard V- +H 0100110011 0100110011 1001110001 0000011111
Clock regen packet
SubPkt0 N = 6400 CTS = 35245
SubPkt1 N = 6400 CTS = 35245
SubPkt2 N = 6400 CTS = 35245
SubPkt3 N = 6400 CTS = 35245
45281 10 :-> DataGuard V- +H 0100110011 0100110011 1001110001 0000011111
The spec certainly doesn't require those bits, but feel free to try them out.
I'm still using that in my test code instead of the Video AVI InfoFrame. I'm running flexspin
Version 7.0.0-beta-v6.9.7-65-g3914edfd Compiled on: Sep 9 2024
One thing I noticed just now which seemed weird. These were the sample times in pixels at which you sent out audio frames. Most are sent every 1075 pixels which is your line rate. Once you didn't send a packet making it 2150 which I guess is fine and one time the count was 1070 pixels. I don't really get the second case as to why it would be 1070 pixels.
@rogloh oh can you shoot the log for that one?
Yeah here it is:
Damn too large. 2.3MB zip. Let me truncate a bit.
Oh, looks like just prior to this we lost clock sync somehow and accumulated 60 "10b" bits which is 50 extra or 5 pixels worth. I see this is happening a few times in the file. So something is causing a capture problem - maybe my compression is messing up somewhere at boundaries... will have to check this.
The 2150 one is because your grep missed the packet at 10854 because there's a clock regen packet after it, not a data guard.
Ok good. Problem solved.
Hmm, so everything's to spec, back to square one. I really have nothing else. Maybe try different bits in the channel status... (most of the audio infoframe HAS to be zero according to spec)
Plasma TVs are kind of ancient these days, right?
Was googling and find people are having problems with the HDMI inputs going bad.
Or, maybe only takes encrypted inputs?
My OLED is sometimes picky, but seemed to take this fine (although does need the 5V)
Does it have other hdmi inputs to try?
I guess that could be possible? If I can find a device that doesn't encrypt audio that works that would kill that theory, but I've only got a PS3, Bluray/DVD a PVR and AppleTV plus Apple laptop to feed it. I'm guessing all of those would encrypt everything. If I can find something to capture an unencrypted bitstream that I know works with audio somehow I might be able to find out what the difference is that stops it from working. I also can't get my AVR to decode the audio from the P2 HDMI either - just video only is displayed.
Yes my AVR needs the 5V to detect the signal. The plasma works without it.
It does, perhaps I can try them. Or dig up and read the manual and see if there are any inputs that work differently to others. The menu system options are very limited on it.
Computers normally don't have HDCP enabled because the handshake takes forever etc. But I wouldn't trust an Apple machine to do the sane thing, so shrug. If you have a computer that can run Linux, I think that normally can't do HDCP at all. DVD player also kinda shouldn't do it if the disc doesn't have copy protection (-> just burn one), but that's a maybe. PS3 OTOH is always HDCP because Sony hates you. (no other game console does this - PS4, Nintendo Switch, etc should be fine, might need to set it in the settings). The real way though is to grab a certain kind of chinesium 1-to-2 cable splitter box. The handshake protocol is only designed for a single sink, so the box does the handshake with the source and then just doesn't bother encrypting the output again. People used to buy these to make youtube vids of PS3 games.
This is interesting. I used to have a 1 input to 2 output cable splitter that might have worked like that but it fried, I've since replaced it with a 2 output from 4 inputs independently selectable per output which I guess is probably able to do the handshake all the way through.
https://www.jaycar.com.au/concord-4x2-4k-hdmi-matrix-switcher-splitter/p/AC5012
I do have this too, but I think it's likely mostly dumb and passes through to both somehow with a simple amplifier but I might be wrong. I'll add it into the path to see if it helps.
https://www.aliexpress.com/item/1005007174659162.html
I found the cause of that occasional clock sync loss in the TMDS frame capture. It was happening on 256kB boundaries and was due to a couple of lines of code in the streamercog code I'd removed by mistake in some edits. These were originally there to align the FIFO streamer input buffers to the 64 byte block boundary. This used to work fine before with that code but regressed recently after that was changed. Now fixed in this update. After capturing again, the 10b input patterns per channel are now always 10 bits in length apart from the first couple of samples while it aligns itself initially to the stream using the rising edge of the TMDS clock channel signal as the reference.
❯ grep - out2 | grep -v "10 :"
1 * 0 :-> RGB (FD_30_FD)
2 * 6 :-> RGB (A1_A1_A1) 110101 110101 110101 000001
Just figured out that Raspi HDMI doesn't use HDCP by reading some forums on Raspi. So I should be able to feed that into the Pioneer plasma TV HDMI input to see if I can get audio from it. Will report back on the finding in this post once I do that test.
"HDCP support is not implemented on the SoC used in the Raspberry Pi SBC, nothing has changed in 8 years.
It was only implemented on other devices like the ROKU which used the BCM2835 SoC."
UPDATE: yep, sound is working - I hear system sounds in the Raspi audio settings and test menu etc.
This proves this TV can take unencrypted streams. I just wish I knew what was so different about this vs the P2 output. I need to find a way to capture the HDMI symbols from the Pi now. My Adafruit HDMI to LCD board based on the TFP401 chip has arrived but that only decodes to RGB24 and doesn't expose the control or TERC4 symbols AFAIK. Maybe I can reverse engineer it from the LSnibble of the colour?
I wouldn't assume that you get any kind of valid outputs from the RGB pins during a data period. Also, take care of the EDID ROM. If it doesn't indicate HDMI/Audio support, no data will be sent.
Yeah I think this TFP401 chip is DVI aware only. So I'm not sure what it'll do with TERC4 10b symbols if they are different from regular RGB encoded bytes. I'm going to start looking into the EDID stuff. I think there are some examples supplied by Adafruit.
UPDATE: in fact I reckon I could pretend this device was my PlasmaTV by using its EDID. The Pi driving it should then think it talks to a plasma, but at the default resolution setup by the Pi which might be too high a speed to capture. I sort of want it to use SDTV or 640x480p type resolutions so I could clock it into the P2 and store to PSRAM so I'll need to figure that out first.
This is actually looking pretty promising. I just programmed the EDID I2C EEPROM on that new Adafruit TFP401 translation board I received recently with my plasma TV settings that I extracted previously. I then fed this board with @Wuerfel_21 's HDMI video driver output from the P2 Edge.
Until I fully wire in the parallel RGB data lines I won't know what exactly the TFP401 is sending out here but I do see it drop the DE signal at the back end of the HSYNC region and this is very likely to be where the data island exists IMO.
In theory if DE is high the chip should decode the TERC4 symbols as video and try to output 24 bit RGB in this portion but I will have to wait to prove it by wiring it up fully. If true this should let me capture the Raspi HDMI output and see what on earth its audio stream looks like compared to Ada's audio format. That's the dream anyway.
Here's a quick scope image I took of the DE signal (yellow) and Hysnc pin (+ve sync) output (blue) by the TFP401 chip. I also checked the clock signal and got something around 33.8MHz which is expected too.
This second image has me very excited as it shows bit 2 of the TMDS channel 0 (BLUE[2]) in the data island which is meant to start out as a serial bitstream of 10111111.... with a bunch of 1's following and I can sort of see that here. If the data is valid I'll be able to capture it nicely assuming my signal integrity is okay at 33MHz or thereabouts. I plan to use 3 lots of 2x6 IDE ribbon cables plugged into P2-EVAL headers in 3 groups for RGB plus the clock and sync stuff on another 4th header. If it's too noisy to capture like this I'll have to spin a simple PCB to fanout the FPC into the P2 IO pins.
Posting here in particular as it relates to your HDMI audio driver. I was able to get the HDMI audio related items of interest captured on a RasPi for analysis. Here's a big dump of info:
Guess what @Wuerfel_21 ? For HDMI audio output from the RasPi the CTS value actually changes in the clock regen packet by a few clocks here and there, it's not static!
This could be important for locking/jitter issues. The "N" value does remain the same throughout the capture though. Interestingly it's not using the recommended N value for 48kHz audio but something exactly 11/12 of it. Weird. Maybe something internal to Broadcom. Not sure.
❯ grep -A1 CTS out | more
SubPkt0 N = 5632 CTS = 26938
SubPkt1 N = 5632 CTS = 26938
SubPkt2 N = 5632 CTS = 26938
SubPkt3 N = 5632 CTS = 26938
23768 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
--
SubPkt0 N = 5632 CTS = 26940
SubPkt1 N = 5632 CTS = 26940
SubPkt2 N = 5632 CTS = 26940
SubPkt3 N = 5632 CTS = 26940
51040 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
--
SubPkt0 N = 5632 CTS = 26937
SubPkt1 N = 5632 CTS = 26937
SubPkt2 N = 5632 CTS = 26937
SubPkt3 N = 5632 CTS = 26937
77824 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
--
SubPkt0 N = 5632 CTS = 26940
SubPkt1 N = 5632 CTS = 26940
SubPkt2 N = 5632 CTS = 26940
SubPkt3 N = 5632 CTS = 26940
104640 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
--
SubPkt0 N = 5632 CTS = 26939
SubPkt1 N = 5632 CTS = 26939
SubPkt2 N = 5632 CTS = 26939
SubPkt3 N = 5632 CTS = 26939
132256 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
--
Also I captured the line after each clock regen packet which shows the sample number and can be used to see how often it's sent. Most of the time it's the last packet in the island, but occasionally it has another TERC4 encoded packet after it as shown by the single different line below.
❯ grep -A1 CTS out | grep Data
23768 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
51040 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
77824 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
104640 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
132256 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
159040 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
185824 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
212608 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
239424 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
266208 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
293824 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
320608 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
347392 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
374176 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
400992 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
428608 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
455392 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
482176 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
508960 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
535604 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
562544 Data:-> DataGuard +V +H 01010101 01010101 10111010 11010 5555ba
590176 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
616960 Data:-> TERC4 0000_0000_1011 +V +H 01011011 01011011 10110101 11110 5b5bb5
643744 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
670528 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
697344 Data:-> DataGuard +V +H 01010101 01010101 10111010 11110 5555ba
Here are the times in pixel clocks at which these regen packets get send out and gaps between them. About 1msec.
Here's an Audio InfoFrame being sent. Only channel count is set here and encoded as %001 = 2 channels.
❯ grep "Audio Infoframe" -A 5 -B 6 out |more
TERC4 Packet Decoded:
Pkthdr: 0A0184 ECC=4A ComputedECC=4A
Subpkt0: 00000000000170 ECC=7D ComputedECC=7D
Subpkt1: 00000000000000 ECC=00 ComputedECC=00
Subpkt2: 00000000000000 ECC=00 ComputedECC=00
Subpkt3: 00000000000000 ECC=00 ComputedECC=00
Audio Infoframe packet
Version:1
Length :10
Chksum :70
Data: (LSB First) 01 00 00 00 00 00 00 00 00 00
535795 Data:-> DataGuard V- +H 01010101 01010101 01101100 10010 55556c
--
Here's how often Audio Infoframes are being sent out. Once per frame by the looks of it. In 14.5 frames of total data captured I observed 14 of these.
❯ grep "Audio Infoframe" -A 5 -B 6 out | grep DataGuard
535795 Data:-> DataGuard V- +H 01010101 01010101 01101100 10010 55556c
1075795 Data:-> DataGuard V- +H 01010101 01010101 01101100 10010 55556c
1615795 Data:-> DataGuard V- +H 01010101 01010101 01101100 10010 55556c
2155795 Data:-> DataGuard V- +H 01010101 01010101 01101100 10010 55556c
2695795 Data:-> DataGuard V- +H 01010101 01010101 01101100 10010 55556c
3235795 Data:-> DataGuard V- +H 01010101 01010101 01101100 10010 55556c
3775795 Data:-> DataGuard V- +H 01010101 01010101 01101100 10010 55556c
4315795 Data:-> DataGuard V- +H 01010101 01010101 01101100 10010 55556c
4855795 Data:-> DataGuard V- +H 01010101 01010101 01101100 10010 55556c
5395795 Data:-> DataGuard V- +H 01010101 01010101 01101100 10010 55556c
5935795 Data:-> DataGuard V- +H 01010101 01010101 01101100 10010 55556c
6475795 Data:-> DataGuard V- +H 01010101 01010101 01101100 10010 55556c
7015795 Data:-> DataGuard V- +H 01010101 01010101 01101100 10010 55556c
7555795 Data:-> DataGuard V- +H 01010101 01010101 01101100 10010 55556c
Here's the accumulated channel status being sent (LSbit=last of the 192 bits printed in this output). Its data remained static throughout the capture (repeating 66 times over).
❯ grep "count=191" -A 8 out | more
Sample 0 right = FFE300, left = 000000, flags=80 Pr=1 Cr=0, Pl=0 Cl=0 ParityR=1 ParityL=0 Channel status count=191
L Channel Status:
00000000_00000000_00000000_00000000_00000000_00000000_00000000_00000000_
00000000_00000000_00000000_00000000_00000000_00000000_00000000_00000000_
00000000_00000000_00000000_00000010_00000010_00000000_10000010_00000100_
R Channel Status:
00000000_00000000_00000000_00000000_00000000_00000000_00000000_00000000_
00000000_00000000_00000000_00000000_00000000_00000000_00000000_00000000_
00000000_00000000_00000000_00000010_00000010_00000000_10000010_00000100_
I looked up the bits that were set.
No copyright, consumer LPCM. Category code= 130
Doesn't take source or channel numbers into account
Sampling freq=0010 =48kHz, level2 clock
16bit samples, sampling frequency not indicated.
These might also be rather important to set correctly for some devices that use them....? Unfortunately think your driver code currently limits the SPDIF channel status data source bits to 32 bits only, otherwise I could try to setup this same channel status and try feeding my Plasma again. Maybe it's important for it to know the sample size before it tries to play the data and keeps it muted until then...?
Attached is the raw 32 bit LOGFILE I used for this. The decoded output is a massive 752MB so I didn't bother to include it but if you want to also take a look you can generate the decoded output text file with my latest tm.c file posted in Video capture thread using
./tm -l < LOGFILE > outNote the minus L option (lowercase) is required to decode P2 RGB longs instead of TMDS bits.Also for fun here is the first video frame in the screen grab from the Pi400 Ubuntu HDMI output after I clicked the GUI mouse button and collected the digital HDMI audio that played from it.
grep -A 720 Video out | grep Data: | grep -v VideoGuard | cut -c 95-102 | ./ppm 720 576 > roger2.ppmFound a quick way to hack NeoVGA.spin to send a 34th bit of 1 in the S/PDIF channel status - only needed one instruction and the Z flag. Hopefully the path isn't compromised by the extra instruction and flag use, didn't want to have to go count clocks etc to see how tight it is. Hardcoded bit 33 for now as a "1" as shown in the capture above. Relies on the fact that bit0 is treated same as bit32 in the S/PDIF status long.
cmp spdif_phase, #33 wcz '<<< added (rogloh) 'cmp spdif_phase,#32 wc '<<< removed (rogloh) if_c testb spdif_status,spdif_phase wc if_z modc _SET wc '<<< added (rogloh) bitc spleft,#26 bitc spright,#26After some mods to the code and applying 5V I can hear an audio tone on my Plasma but it is chopped up and mutes randomly. Sounds like Morse code signalling about 100-800ms bursts of audio. Something is still not correct.
I also backed out these changes and again send only a video InfoFrame and the original SPDIF pattern and I still hear the random audio tone bursts (constant frequency tone but also quite a bit of noise). Huh? Can't figure it out as I've already applied 5V to the HDMI board in the past to see if that made a difference and at the time I did that I find it only let me get a video signal through the AVR to a projector (no sound) and had no effect on the Plasma TV at the time. Now it seems to have an effect. Maybe one of the later github updates actually made a difference but I didn't retest with 5V after taking it perhaps. Will retest the AVR now to see if I get audio from that too with 5V running the same code and report back....
Update:
Just tested the AVR, and I do get sound there too now which is certainly different to my testing before, but I get the same choppy Morse code output effect as the Plasma does.
I'm attaching the exact versions of vgatest.spin2, NeoVGA.spin2 and config.spin2 in this zip file below to see if they are somehow different to what you use and what works for you @Wuerfel_21
At least there is some sort of progress here. Could be packet timing related with jitter or PLL lock issues.
Update2:
In reading through some of the older posts I noticed this, which I've not yet tried as I didn't understand that code. Perhaps it may relate to the problem I have?
Update3:
THAT'S IT!!!!! I now have a solid tone on both Plasma and AVR. Needed 5V and this resampler bypass change and something else that must have happened along the way.
I guess some HDMI devices can compensate for your resampling stuff while others don't like it so much.
@rogloh So it's just bit33 that needs setting? Try applying just that to the plain
video-nextgenbranch. Resample bypass making it work sounds more like your code got shreked along the way.(EDIT: Though the correct thing would be to indicate 24 bit sample length - that's what comes out after resampling)
It's good to get audio at all, but the resampler needs to be enabled for actual use, you probably shouldn't rawdog 55kHz from the YM2610 into the HDMI link.
I don't think any SPDIF changes are needed at all unless the value in the clock regen branch differed from next-gen (ok just checked - it's the same). After hearing something initially following a change I backed them all out in the end and it still worked. What cleaned up the audio was the resampler removal along with 5V being present and maybe some other recent change. But I will try your latest next-gen branch to see if that works now.
I expect if it specifies 16 or defaults to 16 bits it just takes the upper bits of the 24 bit value of the sample. So you may lose little quality but should still work okay.
???????? Magic TV gremlins are laughing at us right now.
That's what it ought to do, yes.
Nope top of video-nextgen branch which I just downloaded clean from GitHub still doesn't work with 5V and my Plasma. No audio at all. So it's seems to be something to do with the resampling or clock regen timing stuff. I'll try to nominate 16 and then 24 bit audio in the SPDIF to see what that does just in case...
Update: set bit 33 in SPDIF channel status for this video-nextgen branch and got broken audio tone again. Will now try setting bits 35-32 to %1011 (24 bit samples)
Also starting to think there might be some randomness to this if variables are not being cleared at the start and some initial phases might work and some might not...initializing those 3 variables to zero seemed to massively help before.
Ah, enlightening, I guess it just has to be set once and then it rember 💀
Also, verify behaviour with the actual full fat NeoYume running. In terms of sample arrival timing, there's this line:
incmod temp3,#2-1 wc ' This limits it to encoding 2 samples per scanline, which ought to be enough. If you set 3-1, that might change something.Yeah that seems to be the outcome. I change it and it fixes the TV, then I revert it and it still works. LOL.
I just tried to set bits 35-32 to %1101 pattern with this code and now no audio again. Bizarro. Maybe the channel status is the culprit in the end...? Or maybe I introduced too many instructions.
This was my change to your code:
' Set sample as valid in header alts temp3,#8 bith packet_header,#0-0 incmod spdif_phase,#191 wc if_c alts temp3,#20 if_c bith packet_header,#0-0 call scanfunc ' <<< ADDED ' Add S/PDIF status bit cmp spdif_phase,#33 wcz << changed from cmp spdif_phase, #32 wc if_c testb spdif_status,spdif_phase wc if_z modc _SET wc <<< ADDED cmp spdif_phase,#35 wz <<ADDED if_z modc _SET wc << ADDED cmp spdif_phase,#32 wz << ADDED if_z modc _SET wc << ADDED bitc spleft,#26 bitc spright,#26That is too many instructions. When you add a scanfunc call you need to change the time compensation.
I'll make a proper change to that end later(TM) (aka in a few hours). Sadly very localized busy-ness here.
Ok, yeah wasn't sure about that. I just tried the incmod suggestion in NeoYume and it didn't make a difference (was using the bit33=1 in that test too in the hopes it might help as well). No audio.