Mic Volume locked to 0

[bostjanlaba]

After programming CM108B with Manufactured and Product name, volume of microphone input is locked to 0.

Any idea why? If I delete the eeprom, it works again (volume slider in Windows).

Also issuing "read" command seems somewhat unreliable, outputting different eeprom content every time. Even when erased and read, it outputs many 0xFF but also some non FF bytes on random places...

Thanks for the help

Bostjan

[islandcontroller]

Hi there! Thanks for opening the issue!

After programming CM108B with Manufactured and Product name, volume of microphone input is locked to 0.
Any idea why? If I delete the eeprom, it works again (volume slider in Windows).

I suspect this could have something to do with other bits in the EEPROM being set to invalid data. Could you paste an EEPROM dump in here? I currently only have boards using the CM108AH, which does not exhibit this behaviour.

Also issuing "read" command seems somewhat unreliable, outputting different eeprom content every time.

I did notice that too, albeit it was "mostly" reliable on the CM108AH. I believe this is either an issue with the python HID library or the chip itself. I'll look into adding a "--thorough" option or similar to the read command, to read the device multiple times while checking for differences.

Best regards,
islandc_

[bostjanlaba]

Hi, thanks for quick reply and update!

Dump of multiple reads of empty eeprom:

Dumps after programming manufacturer and product name:

But since read is not reliable it's hard to provide proper dump :)

Thanks for the help.

Bostjan

[bostjanlaba]

Regarding the MIC input I fiddled a bit and it did start to work when: I set the serial number and when I put 2A byte on value 0 (def values 0, min/max flags all 0). What serial num has to do with Mic input I have zero idea but without serial - no go.

Regarding unstable verify/read - could it be some timing issue? I'm a programmer but python and especially eeprom programming are not my "field"... Thanks

[bostjanlaba]

read start returning consistant values if I add time.sleep(0.01) into read8 method. Then I get same result every time.

Now time to figure verify :)

[islandcontroller]

Hi, thanks for taking the time to troubleshoot this issue further!

when: I set the serial number and when I put 2A byte on value 0

This leads me to believe it might have something to do with the validity flags in the "magic word" at address 0. In the CM108B datasheet, bit[3] is mentioned as toggling the validity of addresses 0x2A, 0x2B and 0x32. Could you try changing address 0 value from 0x670D to 0x6705 and see if this issue still persists?

Regarding unstable verify/read - could it be some timing issue?

I agree, this could be due to timing or some sort of race condition. But I am unsure whether it's internal to the ASIC (sending out old data over USB) or if something inside pywinusb is returning bogus data. Timing usually should be handled outside of "application space".

read start returning consistant values if I add time.sleep(0.01) into read8 method

I used something along those lines for a previous version of write8/write16, but it was causing issues with another version of the driver (see 307e952).

I'll have a more thorough look into it this weekend - currently a bit swamped with work.

Best regards,
islandc_

[bostjanlaba]

Yeh, I tried with 0x6705, mic stays locked.

Regarding the sleep 0.01 "solution" I'm using just default windows drivers in Windows 11, no special driver.

I have way too little knowledge about the eeproms and programming so it's pure guess but could it be that somehow speed of my PC could be also a factor? Meaning if CPU is too fast it does not properly wait for some confirmation of data transfer or whatever?

Thanks

[bostjanlaba]

One odd thing happened. I set serial to 00000031 and it was ok in all aspects. But when I set it to 00000001, device was recognized in windows and all but any software declared it with some MMI error and could not work with the device. Changing serial to 000000000001 (12 digits) made it work. I guess another strange thing undeclared properly in data sheet of cm108b....

[islandcontroller]

Hi! Happy saturday 😁

Yeh, I tried with 0x6705, mic stays locked.

Ah, bummer. I tried to test this with my board, but I have the "MODE" pin tied to +3.3V which disables microphone input by hardware.

default windows drivers in Windows 11, no special driver

Good to know! The in-box drivers do have some issues - for one, SPDIF volume is pegged at 100% when using default drivers. When I use the CMedia driver (see "Releases"), volume control works fine.

speed of my PC could be also a factor?

This depends on how CMedia implemented their USB <-> EEPROM interface, as USB devices can tell the PC to wait while they are still processing data. If this issue is caused by the driver sending out old data then no, it would "just" be a bug in the driver.

when I set it to 00000001, device was recognized in windows and all but any software declared it with some MMI error

This is very odd. I can set any of those IDs and they all work fine.

--

One more thing - could you check the USB VID:PID with an erased or blank EEPROM? Just in case they are different from the CM108AH.

I used "USB Tree View" to check it, and it dumps out something like this:

      ========================== Summary =========================
Vendor ID                : 0x0D8C (C-MEDIA ELECTRONICS INC.)
Product ID               : 0x013C

Best regards,
islandc_