The 1 euro HDMI input solution for your next DIY DAC

[MCH]

Hi,
A couple of weeks ago i bought one of these from Aliexpress.

I had no idea what was inside but these HDMI to whatever boxes are always full of surprises and i couldn't resist for as little as the title price (1.8 euros to be exact).

Of course, as soon as i had it in my hands the first thing i did was to crank it open.

The IC is a Macro Silicon MS1836S HDMI to AV chip.... with SPDIF and I2S output up to 192kHz and hardware mode with no need to program???

The datasheet is nowhere to be found, so i plugged it to my tv, fired up the osciloscope and started tapping pins:

Yes, the digital audio output was alive and kicking, even if not connected to anything

(LRCLK at 48kHz and i2s Data signal at 1.58MHz)

Now, why is this interesting? Probably it isn't for most people, but if you like diy in the digital audio domain, it might be an easy way, or maybe the only feasible way, to add a stereo HDMI input to your next diy DAC project. No MCU, no hundreds of pages of datasheet (well, no datasheet at all actually) no programming...

And that's all folks, i still need to decide if i reverse engineer the rest of the circuit and transplant it to a future project. It should be easy, there is nothing on the other side of the PCB.
Thanks for reading and happy new year!

 

[wwenze]

And it even comes with RCA connectors.

Is the default output SPDIF?

 

[TonyJZX]

that socket 1 is yellow

ie. its composite?

<shudder> hdmi to composite????

 

[MCH]

And it even comes with RCA connectors.

Is the default output SPDIF?

No, the RCA is for composite..None of the audio outputs is connected

 

[TonyJZX]

the reason why these are cheap is that the amount of people who desperately need to convert HDMI to rca composite video is vanishingly thin...

i personally cant think of use case except in security or car reverse cams etc. where you are feeding a 5-6-7in center dash screen and coax in is all ya got

BUT i mean these are cheap enough you can experiment and do coax dig breakout which is vastly more useful however even here... I have a few $10-$20 four port hdmi switchboxes which output digital audio thru 'legacy' ports like optical and coax.

 

[MCH]

the reason why these are cheap is that the amount of people who desperately need to convert HDMI to rca composite video is vanishingly thin...

i personally cant think of use case except in security or car reverse cams etc. where you are feeding a 5-6-7in center dash screen and coax in is all ya got

BUT i mean these are cheap enough you can experiment and do coax dig breakout which is vastly more useful however even here... I have a few $10-$20 four port hdmi switchboxes which output digital audio thru 'legacy' ports like optical and coax.

Yes sure, audio extractors are a solved problem if you don't mind one additional box. What makes this chip interesting is that even the less skilled DIYer can implement it on his own DAC circuit/PCB and have HDMI input fully integrated.

The problem with the regular HDMI extractors is that they are either much more complex to implement or depend on a separate preprogrammed MCU, an the datasheets are always nonexistent. But here, if you look at the PCB, you have a 27MHz crystal, a LDO for the power supply that you might not even need, what seems to be a second LDO, a bunch of resistors and that's it. A dream for the DIYer. I personally would add some ESD protection in case and call it a day. Remains to be seen how it handles sample rate changes, but if it works like the regular extractors, it will just output what it receives without any additional setting.

 

[t1msu]

Very nice, I'm definitely interested. But for most applications you would need an HDMI passthrough instead of an input, right?
Do you think this would work with this too?

 

[MCH]

Very nice, I'm definitely interested. But for most applications you would need an HDMI passthrough instead of an input, right?
Do you think this would work with this too?

I am afraid you can't have a pass through with this.
To have pass through you need a HDMI transceiver. I reversed engendered the Amazon basics HDMI extractor if you are interested. It does not need MCU, does pass through and can output 4 channels i2s audio, but:
1. Is much more complex than this one
2. When you source the chip, you need to make sure it comes programmed. My plan was to take the chip from a functional extractor, but left the project unfinished.

 

[MCH]

I did a bit more of digging, trying to find out if the claimed 192kHz of the description were true.

Plugged the device to my raspberry pi with the KMS HDMI driver that i use for audio over HDMI and checked what the real capabilities of the device are:

Up to 32 bits 192kHz, not bad! other HDMI cards i have go only 24bits. I needed to confirm this. I prepared a 192kHz 32 bit PCM test file in audacity, copied it to the rpi and played with aplay, no problems!

tapped the LRCLK pin with the oscilloscope. 192kHz indeed:

And there you go guys, a fully capable 192kHz 32 bit stereo audio card in one single chip.

While i was at it i checked fast the rest of the circuit with the multimeter. I am no expert but the only stuff accompanying the IC are two LDO, one for 3.3V and the 5 pin one for 1.2V and 0.6V, nothing else.

 

[phofman]

@MCH: Did you check the bitclock to be 64xFs and the data to actually contain all 32 bits? IIUC the HDMI specs the audio sample subpackets are always 7 bytes where bytes 1-3 and 4-6 are for two 24-bit samples and byte 7 is for parity/aux data - see section 5.3.4 + table 5-13 in HDMI 1.4 specs https://picture.iczhiku.com/resource/eetop/WykdeTTrpaEticnM.pdf

 

[Multicore]

Yes sure, audio extractors are a solved problem if you don't mind one additional box.

Sorry to hijack the thread but what do y'all recommend to extract audio to TOSLINK optical? My experience with extractors has been bad and the only one I ever got that worked is getting old.

 

[MCH]

@MCH: Did you check the bitclock to be 64xFs and the data to actually contain all 32 bits? IIUC the HDMI specs the audio sample subpackets are always 7 bytes where bytes 1-3 and 4-6 are for two 24-bit samples and byte 7 is for parity/aux data - see section 5.3.4 + table 5-13 in HDMI 1.4 specs https://picture.iczhiku.com/resource/eetop/WykdeTTrpaEticnM.pdf

Hi Pavel,
Bitclock reads indeed 12.3MHz:

I wanted (and still want) to capture the complete i2s signal, if only to try the logic analyzer i also got almost simultaneously from Aliexpress. But it isn't being an easy task: as the pins of the chip are not connected, the way i read them is to attach a needle to the prove and hold it by hand. That is doable for one pin, but not so easy for 4!! but i definitely want to do it, at least try to capture LRCLK and DATA and report back.
What got me confident i had 32 bits is that in other occasions i had it wrong ,aplay reports the format is wrong (when the file is not that format), or not available (when the player is not capable). It converts and plays anyways but reports it. Maybe i am wrong, but i am sure you know how it works.
Will do the previous capture and report what i get, now i am also curious. Thanks!

 

[MCH]

Sorry to hijack the thread but what do y'all recommend to extract audio to TOSLINK optical? My experience with extractors has been bad and the only one I ever got that worked is getting old.

First i would recommend you the Amazon Basics HDMI extractor. I tested it up to 192kHz and works fine.

If what you are asking is how to use a decoder like this to output spdif optical, in principle the chip is capable of doing it, but i still couldn't find how. I suspect there is a pin that acts as switch (i.e. if it is low, it outputs i2s, if it is high, spdif), but without the datasheet i can't tell. It won't be an easy task to find out, so if you want spdif from HDMI, my recommendation is to try a commercial solution. now they sell them with ARC too.

 

[phofman]

I am afraid the supported format hard-coded in the driver does not specify the actual device resolution E.g. ice1724 driver accepts only S32LE as ice1724 supports only 32bit-frames DMA, yet all I2S interfaces of that chip are 24bit only.

IMO checking the data is simple - just create a stream with data only in bits below 24 (e.g. sox ... gain -160) and check the data line with a scope. I use a stream with only the 32nd bit set to check for position of the first bit of the audio sample data line against the I2S frameclock:

sox -V -r 768000 -c 1 -n -c 2 -b 32 -t alsa hw:GenericStereoAu trim 0.0 100.0 dcshift 0.0000000004

 

[MCH]

I am afraid the supported format hard-coded in the driver does not specify the actual device resolution E.g. ice1724 driver accepts only S32LE as ice1724 supports only 32bit-frames DMA, yet all I2S interfaces of that chip are 24bit only.

IMO checking the data is simple - just create a stream with data only in bits below 24 (e.g. sox ... gain -160) and check the data line with a scope. I use a stream with only the 32nd bit set to check for position of the first bit of the audio sample data line against the I2S frameclock:

sox -V -r 768000 -c 1 -n -c 2 -b 32 -t alsa hw:GenericStereoAu trim 0.0 100.0 dcshift 0.0000000004

not sure if i am doing it right, well, almost sure i am NOT doing it right. This is what i get:
I run sox with gain -160 (not sure if the sintax is ok, it is the first time i use sox):

I read the LRCLK pin on the logic analyzer. I get edges up every ca 4.5 us, what seems compatible with 192kHz, all good until here:

now i read the data pin. I get edges every ca 200 ns, what seems compatible with 6MHz if my maths are good. But i see bits regularly. I was expecting to see several 0 in a row... edit: to be honest, i think 6 MHz is getting too close to the resolution of the analizer, there are barely 2 samples in between bits. Tomorrow i will try to repeat the test with a lower sample rate.

I dont know, it is my first time with the logic analyzer as well, give me some time to try to capture both LRCLK and data simultaneously and see what happens.
Thanks for the suggestions and learning!!

 

[phofman]

That 768kHz rate was just an example of what I use. Your sox generates 768kHz stream and resamples down to 192kHz. It's very likely the resampling creates some artefacts above 24 bits. Generate directly in 192kHz, store to wav and check e.g. with mcview + hex view that the wav contains what you wanted.

 

[gordoste]

At least you're learning how to use your logic analyzer!

 

[phofman]

If the analyzer bandwidth is close to the limit, for this check it may be easier to use the oscilloscope - just checking whether the data line outputs no ones (which are always below the 24th bit).

 

[MCH]

@phofman sorry for the late answer but after tapping the pins of the chip too many times with needles, i ended up deforming the solder to the point that Data out with BCLK shorted. Needed to rework the pins with the soldering iron and as i was at it, i soldered two thin cables to LRCLK and Data out, so now i can easily measure both simultaneously. (btw, i also found out the spdif output pin, that is actually what i initially thought was i2s data, being i2s data the one in between spdif out and BCLK. Both spdif and i2s work simultaneously.)

I believe that the following results using sox show that the chip is actually outputting 24 bits instead of 32, but wanted to hear your opinion.

This is the result when i don't apply any attenuation (i am not familiar with the syntax of sox, sorry in advance if there is something wrong):
sox ~/1kHz192kHz32bstereo.wav -V -r 192000 -c 2 -n -c 2 -b 32 -t alsa hdmi:vc4hdmi0 gain 0 trim 0.0 100.0 dcshift 0.0

(D0 is LRCLK and D1 is Data)

the last few bits are always low, i guess an indication of 24 bits output?

-90dB attenuation:
sox ~/1kHz192kHz32bstereo.wav -V -r 192000 -c 2 -n -c 2 -b 32 -t alsa hdmi:vc4hdmi0 gain -90 trim 0.0 100.0 dcshift 0.0

Still some bits left


And this is applying -160db attenuation as per your suggestion:

sox ~/1kHz192kHz32bstereo.wav -V -r 192000 -c 2 -n -c 2 -b 32 -t alsa hdmi:vc4hdmi0 gain -160 trim 0.0 100.0 dcshift 0.0

no signal whatsoever...

btw, i also observed that the signal changes every few samples from all low to all high. I don't know why this happens. See another section of the same -160dB attenuation capture. All bits are high except for the last ones that are always low no matter what:

and the change all high to all low happens regularly. see below the capture zoomed out:

(the change happens each 0.5 milisecond aprox)

for completeness, this is what sox outputs (0 gain case):

marcosch@raspcamilla2:~$ sox ~/1kHz192kHz32bstereo.wav -V -r 192000 -c 2 -n -c 2 -b 32 -t alsa hdmi:vc4hdmi0 gain 0 trim 0.0 100.0 dcshift 0.0
sox: SoX v14.4.2
sox INFO formats: detected file format type `wav'

Input File : '/home/marcosch/1kHz192kHz32bstereo.wav'
Channels : 2
Sample Rate : 192000
Precision : 32-bit
Duration : 00:01:00.00 = 11520000 samples ~ 4500 CDDA sectors
File Size : 92.2M
Bit Rate : 12.3M
Sample Encoding: 32-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no


Input File : '' (null)
Channels : 2
Sample Rate : 192000
Precision : 32-bit


Output File : 'hdmi:vc4hdmi0' (alsa)
Channels : 2
Sample Rate : 192000
Precision : 32-bit
Sample Encoding: 32-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no


Input File : '/home/marcosch/1kHz192kHz32bstereo.wav'
Channels : 2
Sample Rate : 192000
Precision : 32-bit
Duration : 00:01:00.00 = 11520000 samples ~ 4500 CDDA sectors
File Size : 92.2M
Bit Rate : 12.3M
Sample Encoding: 32-bit Signed Integer PCM

sox INFO dcshift: has no effect in this configuration
sox INFO sox: effects chain: input 192000Hz 2 channels
sox INFO sox: effects chain: gain 192000Hz 2 channels
sox INFO sox: effects chain: trim 192000Hz 2 channels
sox INFO sox: effects chain: output 192000Hz 2 channels
In:100% 00:00:59.99 [00:00:00.01] Out:11.5M [!=====|=====!] Hd:0.9 Clip:0
Input File : '' (null)
Channels : 2
Sample Rate : 192000
Precision : 32-bit

In:0.00% 00:00:40.02 [00:00:00.00] Out:19.2M [ | ] Clip:0
Done.

 

[MCH]

btw, i also observed that the signal changes every few samples from all low to all high. I don't know why this happens. See another section of the same -160dB attenuation capture. All bits are high except for the last ones that are always low no matter what:
View attachment 340123
and the change all high to all low happens regularly. see below the capture zoomed out:
View attachment 340138
(the change happens each 0.5 milisecond aprox)

This left me thinking yesterday.... the file i was using for testing was a 1kHz tone, and 0.5 milisecond is half a period of the tone signal. Were all bits set to high when the wave was, say, positive and zeroed when it was negative?

I have no idea how i2s encoding works, so to find out i generated an identical tone in audacity but this time a 3 kHz tone. Played it again with sox and captured the signal:

Same thing as before, all high for some time, then all low for some time, and this time the change was happening each ca. 0.175 miliseconds, so yes, again, half a period of a 3 kHz tone.
So what we see at -160dB attenuation is a sort of oversimplified version of the tone signal. I guess it is the way it is, but i find it surprising, as intuitively i would think that this would translate in a sort of square wave 3 kHz signal (that would be a 3 kHz tone + its overtones?)
Very interesting indeed, if anyone cares to explain what is going on, i would be curious to hear.

PS: i was even thinking that this could be useful to send inaudible information while no music is playing, like for instance some sort of hidden i2c instructions to the DAC chip (?)