sneakers-the-rat commented 6 months ago

Another thing I noticed further on in the installation progress is that the hifiberry setup thinks it works when you set up prefs.json, but when you actually try to run autopilot, ALSA can't find the hifiberry. After some troubleshooting I think it's because the setup is adding some dtoverlay things to boot/config.txt. On this new raspbian install, boot/config.txt starts with this warning:

"DO NOT EDIT THIS FILE The file you are looking for has moved to /boot/firmware/config.txt"

Originally posted by @Rodgers-PAC-Lab in https://github.com/auto-pi-lot/autopilot/discussions/208#discussioncomment-8498060

sneakers-the-rat commented 1 month ago

I guess they were shy and deleted the comment, but i got an email saying that a helpful anonymous person said this and it reminded me to fix this:

For reference, anyone else having this issue should paste these lines into the new /boot/firmware/config.txt: dtoverlay=hifiberry-dacplus dtoverlay=i2s-mmap dtoverlay=i2c-mmap dtparam=i2c1=on dtparam=i2c_arm=on

Rowanon commented 1 month ago

I'm the one in Chris' lab who had originally mentioned the issue. He was trying to set up a new pi again yesterday so I looked up the lines for him but then deleted it because apparently something else changed and now those lines don't fix the issue. He and a grad student are working on it right now, I can post again when they have it sorted. Supposedly the answer is somewhere in here and changed in March: https://www.hifiberry.com/docs/software/configuring-linux-3-18-x/

cxrodgers commented 1 month ago

The main other thing that has changed in the instructions is it claims hifiberry-dacplus-std replaces hifiberry-dacplus in newer kernels but still checking this..

sneakers-the-rat commented 1 month ago

Ok! Reopened.

211 just changed the paths to the new boot config location, but the config script is otherwise unchanged (if I was doing this now id just use ansible because that script runner is pretty brittle).

I dont have a pi set up with a hifiberry right now, but I can do that tomorrow. Havent had the space in new lab to rebuild my old pi farm yet but that actually has changed in the last few weeks, so I can actually set up a test runner to confirm changes.

Are the overlays mutually exclusive? Like can we just add hifiberry-dacplus-std or do we need some kind of switching logic depending on version? I know yall are off on your own fork atp, but lmk what ends up working and I can make a better system for configuring audio devices - the scripts modules are a really fragile design, should be config based on detected or configured hardware, and esp. If different OS versions or cards need different mutually exclusive configs

cxrodgers commented 1 month ago

Update: my Amp2 works even without a dtoverlay at all. Results are the same whether we use dtoverlay=hifiberry-dacplus-std; dtoverlya=hifiberry-dacplus; no dtoverlay; or a mis-spelled dtoverlay. I've asked HIfiberry whether this is expected and whether it changes anything.

Jonny, what do the following do? dtoverlay=i2s-mmap dtoverlay=i2c-mmap dtparam=i2c1=on dtparam=i2c_arm=on

On Wed, Jul 10, 2024 at 8:05 PM Jonny Saunders @.***> wrote:

Ok! Reopened.

211 https://github.com/auto-pi-lot/autopilot/pull/211 just changed the

paths to the new boot config location, but the config script is otherwise unchanged (if I was doing this now id just use ansible because that script runner is pretty brittle).

I dont have a pi set up with a hifiberry right now, but I can do that tomorrow. Havent had the space in new lab to rebuild my old pi farm yet but that actually has changed in the last few weeks, so I can actually set up a test runner to confirm changes.

Are the overlays mutually exclusive? Like can we just add hifiberry-dacplus-std or do we need some kind of switching logic depending on version? I know yall are off on your own fork atp, but lmk what ends up working and I can make a better system for configuring audio devices - the scripts modules are a really fragile design, should be config based on detected or configured hardware, and esp. If different OS versions or cards need different mutually exclusive configs

— Reply to this email directly, view it on GitHub https://github.com/auto-pi-lot/autopilot/issues/209#issuecomment-2221740240, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEWFUJUVIIURW5OOXJPTJ3ZLXD43AVCNFSM6AAAAABKTIA6N2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRRG42DAMRUGA . You are receiving this because you commented.Message ID: @.***>

sneakers-the-rat commented 1 month ago

The i2c overlays are to enable the I2c driver, maybe predictably, some docs here : https://www.raspberrypi.com/documentation/computers/configuration.html#part3.3 And parameter docs here: https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README

I2c1 refers specifically to the CPU-based I2c device, I guess I2c_arm is an alias?

I guess the mmap overlays dont exist anymore: https://github.com/raspberrypi/linux/issues/5319#issuecomment-1382719495 they used to be listed by hifiberry as being required, and used to be required to get jackd and alsa to play nice, but I suppose they can be removed now!

That is uh remarkable and welcome that it works without an overlay enabled, I wonder if they have figured out how to automatically detect the device?

cxrodgers commented 1 month ago

Here's what I asked Hifiberry: Results are the same with dtoverlay=hifiberry-dacplus, dtoverly=hifiberry-dacplus-std, or no dtoverlay at all. Is this expected? Does it matter which dtoverlay is used?

And here's what they wrote back: _Yes, with the latest kernels that is ok this way. They just read the board ID from the EEPROM and load the correct overlay. Other configured overlays for the same card will be ignored if you don't set "force_eepromread = 0".

I guess this means that:

The default behavior (no force_eeprom_read setting) is to auto-detect the board. In this case dtoverlay is ignored
If force_eeprom_read=0, then dtoverlay must be set, presumably correctly

I seem to be getting good results with pretty much a default config.txt: no force_eeprom_read, no dtoverlay, no i2c or mmap flags. I did disable the other audio outputs as they recommend, but I'm not even sure that's necessary.

sneakers-the-rat commented 1 month ago

Well that is just shockingly good ux for embedded hardware. Ill update the docs and the wiki. Thanks for the update :)

sneakers-the-rat commented 1 month ago

I assume the ALSA config is still necessary? And probably the memlock limit and rtprio raise too for 128kHz? Although I finally got my hands on some raspi 5's and they might just be full on computers enough to not need to juice every drop from them anymore

cxrodgers commented 1 month ago

Not sure..

I made the usual ALSA change and didn't test without it
For whatever reason, on this pi I installed jack from APT instead of source, so it does its own memlock and rtprio change. I didn't try messing with it

On Fri, Jul 12, 2024 at 10:14 PM Jonny Saunders @.***> wrote:

I assume the ALSA config is still necessary? And probably the memlock limit and rtprio raise too for 128kHz? Although I finally got my hands on some raspi 5's and they might just be full on computers enough to not need to juice every drop from them anymore

— Reply to this email directly, view it on GitHub https://github.com/auto-pi-lot/autopilot/issues/209#issuecomment-2226722658, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEWFUPRNSJ4JXGOORNFPJDZMCEQLAVCNFSM6AAAAABKTIA6N2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRWG4ZDENRVHA . You are receiving this because you commented.Message ID: @.***>

auto-pi-lot / autopilot

Fix hifiberry dtoverlay script #209

211 just changed the paths to the new boot config location, but the config script is otherwise unchanged (if I was doing this now id just use ansible because that script runner is pretty brittle).

211 https://github.com/auto-pi-lot/autopilot/pull/211 just changed the