Improving i2s_dacs detection ?

[macmpi]

I'm following-up from here as it ends-up more as a Volumio 2 topic.

While I was suggesting to initiate START PLUGINS only after i2sDetect() (in ControllerI2s.prototype.onVolumioStart) is finished by re-arranging the promises & defer chain, I did some further reading on HAT EEPROM and i2c0 and i2c1.

It seems to turn out that actually eeprom read should normaly happen on i2c0 (rather than i2c1) as ID_SC and ID_SD (GPIO0/SCL and GPIO1/SDA) are reserved for board detection / identification.
Actually one can find different methods to extract EEPROM info (sample code in earlier link), but the following is quite promising:

To avoid the need for modules and applications to access the EEPROM, the VC bootloader reads the vendor, product and custom data and populates the /hat node of the device tree.

Then it's just a matter of reading /proc/device-tree/hat which is definitely simpler, immediate and won't delay things (as i2cdetect does) when nothing is connected. It seems information is also dynamically updated on 4.4.y.

Wouldn't that be sufficient for Volumio DAC detection?

[macmpi]

For some reasons (DAC eventually not having proper eeprom), Volumio implements 2 methods:

• /proc/device-tree/hat
• address detection

Looking at the supported DAC list, address detection method does not account for many cases: 2 of them listed at this time, only 1 for which really depending on that method (other one has eeprom info).
So the expected addresses are anyway (1) well-known, (2) relatively few.

Then, instead of scanning the whole bus with i2cdetect -y, which in some cases, can hold things for about 115 sec due to clock stretching (i.e. if nothing connected), how about just trying to read sth in those very-few select addresses (still with timeout)?

Wouldn't this be much quicker than scanning the whole bus address space, and would then release the bus much sooner, in case some plugins might need it?...

[volumio]

I think we can solve it just by using timeout...

[macmpi]

Happy to test any suggested line change.

[volumio]

Ok! Give me a couple of days, and many thanks for your help and suggestions!

[macmpi]

Happy if it can help: I wish I could just contribute PRs so that it's even easier for you, but I'm afraid not fluent enough in js and node to do that.

Besides this "scheduling" problem during DAC detection, I'm actually wondering why it is necessary to go for such detection at each boot, if audio settings do not care about DACs...
For instance I have a rpi0 with HDMI output, no DAC plugged on that one, DAC is set to off, and I'm happy with that: no need to go for i2s DAC detection each time I boot the device, right?

So you may want to improve that test a bit, so that it is evaluated only if DAC UI switch is set to ON within Playback Option / Audio output (alsa_controller .json I guess)

This will definitely reduce occurrences of such DAC detection, while the earlier measures (i2c probe timeout & START PLUGINS dependency) will help ensure detection process is optimal when used.

Makes sense?

[volumio]

We use this to enable I2S DAC autodetection: it means that if a compatible i2s dac is found, it's enabled without user intervention (which I think is a cool feature).
The i2c read and eeprom read are not triggered if an i2s dac is enabled

[macmpi]

From a user perspective, it looks strange to have the system trying to detect i2s DAC, if user positively sets i2s DAC to OFF, and other audio routes are indeed saved (such as HDMI or jack,...or possibly USB DAC) by user intervention.

It is indeed a cool feature that system tries to detect i2s DAC when nothing has been set for audio route (and conf file is "empty"), but once user decides to use other audio path, doing such i2s detection seems a bit overruling user's decision.

[macmpi]

On a side note, I tried auto detection of Hifiberry DAC+ (pro) on raspi3: Volumio did report entering into detection in log I2S DAC not set, start Auto-detection, but it did not report any successful detection on log such as I2S DAC DETECTION: Found Match with ... (initally no eeprom, and address 4d).

I then flashed DAC EEPROM with Hifiberry's provided method, and had no more detection success, although the device did show-up in /proc/device-tree/hat then.
However product string is only DAC+ and vendor is HiFiBerry: isn't look-up in json table failing due to incomplete expected hatnamefile reading only product string?

[volumio]

Hifiberry told me that their eeprom is what we have in dacs.json...

[macmpi]

Here is what /proc contains with eeprom-flashed Hifiberry DAC+ pro (maybe @hifiberry can confirm):

/proc/device-tree/hat/name: hat
/proc/device-tree/hat/product: DAC+
/proc/device-tree/hat/product_id: 0x0000
/proc/device-tree/hat/product_ver: 0x0000
/proc/device-tree/hat/uuid: <my UUID here>
/proc/device-tree/hat/vendor: HiFiBerry

Indeed, what you have in dacs.json is concatenation of vendor and product (with space in between), but Volumio seems to only read product string out of the system: so comparison is never right.
Maybe it's the same for other products...

[macmpi]

Trying to summaries this issue to make it clearer and hopefully more actionable:

1- i2S DAC autodetection happens even when i2S is set to OFF (and setting saved as such):
Therefore OFF in that case really means AUTO.
This AUTO mode is great feature at boot, but once user has positively saved audio preferences towards non i2S audio-path (i2S saved as OFF and/or audio set to HDMI or jack), then it would be desirable AUTO mode really becomes OFF (i.e. no auto-detection at all).

2- When no DAC (and actually no i2C HAT) is connected to Pi, reading i2C bus can take very long time (about 115sec), due to clock stretching on SCL pin (GPIO 3). Therefore it may be a good measure to set a time-out (1sec should be ok) on i2cdetect -y command so that Volumio releases GPIO 2/3 quickly in case something else uses it.

3- When HAT EEPROM-based detection is successful, there is no need to alter config.txt with overlay references (nor modify /etc/modules), as the kernel will automatically search for and load modules that support the indicated, enabled devices.

4- EEPROM-based detection is failing on (at least) Hifiberry DAC+ (pro). This is due to the fact that Hifiberry DAC+ (pro) identification string in dacs.json is composed of concatenation of two fields (vendor and product) where code only scans one (product). Either string in dacs.json should be limited to product only, or code be adapted to concatenate vendor and product: it's likely the latter is preferable to better identify all devices.

5- Address-based detection is less reliable than EEPROM-based detection, as different DACS may use same address (observed in dacs.json). Therefore EEPROM detection result should probably prevail (eventually done first and address based done if first one does not give conclusion).

Hope this helps.