Shop OBEX P1 Docs P2 Docs Learn Events
Console Emulation - Page 63 — Parallax Forums

Console Emulation

16061636566

Comments

  • So back to square one.

    Possibly remaining issues:

    • 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

                mov resample_ratio_int,#0
                mov resample_ratio_frac,#0
                mov resample_dejitter_period,#0
    

    into the init code to make sure the resampler is bypassed.

  • roglohrogloh Posts: 5,607

    @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. :star:
    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

    AES_CLOCK = 24_167_829
    MASTER_CLK = AES_CLOCK
    CLK_MULTIPLIER = 14
    VIDEO_CLKFREQ = MASTER_CLK*CLK_MULTIPLIER
    

    tail out2

    524192     10 :->  RGB (FF_00_FF)                   0011111111  1111111111  0011111111      0000011111  
    524193     10 :->  RGB (FF_00_FF)                   1000000000  0100000000  1000000000      0000011111  
    524194     10 :->  RGB (FF_00_FF)                   0011111111  1111111111  0011111111      0000011111  
    524195     10 :->  RGB (FF_00_FF)                   1000000000  0100000000  1000000000      0000011111  
    524196     10 :->  RGB (FF_00_FF)                   0011111111  1111111111  0011111111      0000011111  
    524197     10 :->  RGB (FF_00_FF)                   0011111111  0100000000  0011111111      0000011111  
    524198     10 :->  RGB (FF_00_FF)                   1000000000  0100000000  1000000000      0000011111  
    524199     10 :->  RGB (FF_00_FF)                   0011111111  1111111111  0011111111      0000011111  
    524200     10 :->  RGB (FF_00_FF)                   1000000000  0100000000  1000000000      0000011111  
    

    Done

    grep Sample out2 | wc

     744   13392   88018
    

    grep Sample -A2 out2 |more

    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

  • roglohrogloh Posts: 5,607
    edited 2024-09-13 13:52

    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

    grep regen -A5 out2 |grep Data

     10886     10 :->  DataGuard            V-  +H      0100110011  0100110011  1001110001      0000011111  
     45281     10 :->  DataGuard            V-  +H      0100110011  0100110011  1001110001      0000011111  
     81823     10 :->  DataGuard            V-  +H      0100110011  0100110011  1001110001      0000011111  
    116218     10 :->  DataGuard            V-  +H      0100110011  0100110011  1001110001      0000011111  
    151689     10 :->  DataGuard            V-  +H      0100110011  0100110011  1001110001      0000011111  
    186080     10 :->  DataGuard            V-  +H      0100110011  0100110011  1001110001      0000011111  
    222626     10 :->  DataGuard            V-  +H      0100110011  0100110011  1001110001      0000011111  
    257021     10 :->  DataGuard            V-  +H      0100110011  0100110011  1001110001      0000011111  
    292487     10 :->  DataGuard            V-  +H      0100110011  0100110011  1001110001      0000011111  
    327958     10 :->  DataGuard            V-  +H      0100110011  0100110011  1001110001      0000011111  
    363429     10 :->  DataGuard            V-  +H      0100110011  0100110011  1001110001      0000011111  
    397820     10 :->  DataGuard            V-  +H      0100110011  0100110011  1001110001      0000011111  
    433290     10 :->  DataGuard            V-  +H      0100110011  0100110011  1001110001      0000011111  
    468761     10 :->  DataGuard            V-  +H      0100110011  0100110011  1001110001      0000011111  
    504227     10 :->  DataGuard            V-  +H      0100110011  0100110011  1001110001      0000011111  
    

  • @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.

  • roglohrogloh Posts: 5,607

    @Wuerfel_21 said:
    So back to square one.

    Possibly remaining issues:

    • 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

                mov resample_ratio_int,#0
                mov resample_ratio_frac,#0
                mov resample_dejitter_period,#0
    

    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.

  • @rogloh oh can you shoot the log for that one?

  • roglohrogloh Posts: 5,607
    edited 2024-09-13 14:13

    Yeah here it is:
    Damn too large. 2.3MB zip. Let me truncate a bit.

  • roglohrogloh Posts: 5,607

    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.

  • roglohrogloh Posts: 5,607

    @Wuerfel_21 said:
    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)

  • RaymanRayman Posts: 14,386
    edited 2024-09-13 21:34

    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?

  • roglohrogloh Posts: 5,607

    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.

  • roglohrogloh Posts: 5,607
    edited 2024-09-13 22:54

    @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

  • roglohrogloh Posts: 5,607
    edited 2024-09-14 01:50

    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

  • roglohrogloh Posts: 5,607
    edited 2024-09-14 02:13

    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.

  • roglohrogloh Posts: 5,607
    edited 2024-09-14 02:35

    @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.

  • roglohrogloh Posts: 5,607
    edited 2024-09-15 01:03

    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.

  • roglohrogloh Posts: 5,607
    edited 2024-09-17 04:42

    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! :smiley: 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 > 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

  • roglohrogloh Posts: 5,607
    edited 2024-09-17 07:44

    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.

                  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,#26
    

    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

                mov resample_ratio_int,#0
                mov resample_ratio_frac,#0
                mov resample_dejitter_period,#0
    

    into the init code to make sure the resampler is bypassed.

    Update3:
    :smiley:
    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. :smiley::smiley::smiley:

    I guess some HDMI devices can compensate for your resampling stuff while others don't like it so much.

  • Wuerfel_21Wuerfel_21 Posts: 4,905
    edited 2024-09-17 08:31

    @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.

  • roglohrogloh Posts: 5,607

    @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.

    That's what it ought to do, yes.

  • roglohrogloh Posts: 5,607
    edited 2024-09-17 09:27

    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.

  • roglohrogloh Posts: 5,607

    @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:

                 ' 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,#26
    

    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.

  • roglohrogloh Posts: 5,607

    @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.

Sign In or Register to comment.