13:39 <xdarklight> jbrunet: two audio related questions: 1. I have noticed that /proc/interrupts does not show any name for the AIU FIFO interrupts. same behavior on my Odroid-C1 and Le Potato board. hardcoding a name doesn't seem to fix it either: https://pastebin.com/2k6HbcCQ

13:40 <xdarklight> jbrunet: question 2: (this one is out of curiosity) have you managed to use non-I2S (on the 32-bit SoCs it seems to be SPDIF) input for the HDMI route?

13:47 <jbrunet> this is because the irq is requested when stream starts and is release on stop. When playing, you should see the irq name. After the playback stops, the name disappears from `/proc/interrupts` but the irq number stays

13:48 <jbrunet> Q2: have not tried it. I don't think it is supported by the dw-hdmi driver yet

13:49 <xdarklight> jbrunet: ah, I only looked at /proc/interrupts after playing something. that explains it - thanks!

13:49 <jbrunet> If you wish to play with HDMI/SPDIF - I would suggest to get it to work on sm1/g12 first ... The new audio arch is much easier to debug IMHO

13:50 <jbrunet> from `sound/soc/meson` perspective, everything should be there I think

14:01 <xdarklight> jbrunet: ah, I thought that dw-hdmi supports the second input since we list it in alsamixer. but I think I understand now: from AIU control perspective we can change the routing to HDMITX but it still depends on the other side to support the different input formats

14:01 <xdarklight> thanks :)

14:06 <jbrunet> I have not studied it much but I think the spdif is an independent input the dw-hdmi (among the different possible types). AIU (and AXG) should be ready to route the audio correctly, hdmi-codec should be ready too. What is missing is the dw-hdmi-spdif.c driver, like there is a dw-hdmi-i2s.c

14:15 <xdarklight> I was wondering about the different inputs that I can validate with existing code on GX (and newer) on the 32-bit SoCs

14:17 <xdarklight> it's not that I need the SPDIF input, but if I have no "reference" to test against I'll skip investigating closer for now

15:30 <xdarklight> jbrunet: also what do you use for testing multi-channel audio? and is this expected to work with AIU yet/what's missing?

15:54 <jbrunet> For SPDIF I used an HIFI audio system with an optical SPDIF input - or a simple SPDIF DAC -> jack - it requires a board with the proper interface, like the p230. I also used a logic analyser to check the frame content.

15:54 <jbrunet> For multi-channel, I often used an HDMI analyser showing the info frames and channels vu-meter, I also used a simple splitter HDMI => 4xjack outputs

15:58 <jbrunet> It is supposed to work but more testing would be welcome. As I explained when the AIU was merged, it is not clear how the switch between 2ch and 8ch mode should be done on the AIU. Some reset must be applied. The sequence I found works, mostly :( However sometimes the switch (one way or the other) appear to fail the output gets very noisy.

16:00 <jbrunet> This is all linked to these mysterious resets. As reported earlier, if the issue becomes annoying (too many complains) I'll probably submit something to restrict to 2ch until more progress can be made.

16:02 <xdarklight> OK. so one of your testing devices is something like this: https://asset.conrad.com/media10/isa/160267/c1/-/de/1229082_ZB_02_FB/audio-extraktor-hdmi-hdmi-cinch-toslink-1920-x-1080-pixel-speaka-professional-sp-ae-h-6k.jpg?x=480&y=480&format=jpg&ex=480&ey=480&align=center ? (but with 4x jack output instead of 6x cinch)

16:03 <jbrunet> indeed

16:04 <jbrunet> and this https://www.amazon.com/PROZOR-Digital-Converter-Optical-Toslink/dp/B00KNNSKV0/ref=sr_1_1_sspa?dchild=1&keywords=spdif+dac&qid=1608566642&sr=8-1-spons&psc=1&spLa=ZW5jcnlwdGVkUXVhbGlmaWVyPUFIUjYwNkNIOUNIVjcmZW5jcnlwdGVkSWQ9QTA2MDgxMTkyWlVRSEJVV1FQSFhVJmVuY3J5cHRlZEFkSWQ9QTAxMDczNzJQNjRMNDBCUEc1Q0cmd2lkZ2V0TmFtZT1zcF9hdGYmYWN0aW9uPWNsaWNrUmVkaXJlY3QmZG9Ob3RMb2dDbGljaz10cnVl

16:05 <xdarklight> some of these optical to headphone converters I already have (they were cheap enough to not think about buying twice ;)). this is how I did the first experiments with audio on the 32-bit SoCs

16:05 <xdarklight> then I bought some raspberry pi I2S board and used that to test I2S on my Odroid-C1+

16:06 <xdarklight> unfortunately these HDMI audio extractors are more expensive than I thought, approx 75 Euros here

16:45 <jbrunet> :/ this was useful to dev on HDMI side TBH. If you are after testing the AIU, maybe you can output the different i2s lines on a GPIO connector (I did that too) ... the HDMI controller is given the same signals

17:16 <xdarklight> jbrunet: 2.0 audio is getting through via HDMI using I2S already (on my Odroid-C1+) :). even the "problematic" sample rates (44.1kHz and multiples of that). SPDIF is not working, but I am not sure if that's a problem with my "receiving equipment" or the TX driver side

17:39 <jbrunet> If you've got a scope, SPDIF is "fairly" simple to observe

18:40 <xdarklight> jbrunet: I have one of these sigrok fx2law "cheap scopes": https://sigrok.org/wiki/Fx2lafw - I think it should be fast enough for SPDIF

20:06 <Tonymac32> xdarklight I would think so. can it do 10 MHz or so?

20:06 <xdarklight> Tonymac32: yes, it can do up to 24MHz. spdif works fine (I just tested it :))

20:07 <Tonymac32> nice. I couldn't remember if that was the same as my cheap sigrock-compatible 8-channel thingy or not

20:08 <Tonymac32> I also picked up a Siglent 200 MHz 2-channel about a year ago in case I need to look at something a bit more challenging

20:08 <Tonymac32> The "real" stuff is massively outside my budget XD

20:09 <xdarklight> at one point I wanted to measure a 125MHz RGMII TX clock signal. I fixed it by spending like 3USD on a STM32 blue pill board and then improving and flashing this: https://github.com/dword1511/stm32-freqmeter

20:09 <xdarklight> fx2law and that combined got me pretty far :)

20:10 <Tonymac32> ah nice. I have a could Cypress PSoC 5's around that I can use for all kinds of interfaces

20:10 <Tonymac32> couple*

20:10 <Tonymac32> but the IDE is only Windows. :/

20:19 <xdarklight> jbrunet: interesting. SPDIF using the I2S FIFO works (it generates a signal on the pin which "looks valid"), but the SPDIF FIFO doesn't. the SPDIF FIFO doesn't even generate an interrupt

21:06 <xdarklight> false alarm, I was looking wrong