And I stopped seeing any sync sequences on the oscilloscope
Perhaps I need to setting up something else?
Perhaps there is a list of default settings for managing I2S4 in alsa?
what could be the reason for this error because the device just rebooted
Hi Kayccc, is there something specific to this issue in there? I would love to follow the docs better.
for example I found this:
Device Tree Configuration for a Custom Audio Card
To support a custom audio card or other external audio device, you may need to add or update various device tree nodes such as clocks and power supplies.
To enable the codec, you must add the codec under the device tree node of the device that is used to access the codec. Most codecs use either I2C or SPI for access. In the example below, the codec uses I2C for its control interface, and so is added to the appropriate I2C node.
i2c@ {
sgtl5000: sgtl5000@0a {
compatible = “fsl,sgtl5000”;
reg = <0x0a>;
clocks = <&sgtl5000_mclk>;
micbias-resistor-k-ohms = <2>;
micbias-voltage-m-volts = <3000>;
VDDA-supply = <&vdd_3v3>;
VDDIO-supply = <&vdd_3v3>;
status = “okay”;
};
};
See the device tree binding documentation to determine what properties must be populated for the codec and how to configure them.
Make sure that the relevant control interface (I2C, SPI, etc.) is enabled in the platform’s device tree. The 40-pin GPIO expansion header exposes an I2C controller; the table below shows the address of the I2C controller exposed on each Jetson platform.
@kayccc this is what i’ve come across. is it true that you can’t persist the mixer across reboots?
Would these solutions work?
The behavior you’re observing is typical. The ALSA mixer settings are not persistent across reboots. They reset to default values when the system restarts.
To make your amixer configurations persistent across reboots, you can consider the following methods:
Startup Script: This is one of the most straightforward methods.
For a system using systemd, you can create a custom service that will run your script at startup.
Alternatively, if your distribution supports it, you can place your amixer commands in the /etc/rc.local file, ensuring that it’s executable.
ALSA State Save/Restore: Use alsactl to save and restore the ALSA mixer state.
After you’ve made your configurations using amixer, you can save the current state with sudo alsactl store.
Ensure the saved state is loaded at boot. Some systems do this automatically, but if yours doesn’t, you can add sudo alsactl restore to your startup script or /etc/rc.local.
Custom ALSA Configuration: Set default behaviors in /etc/asound.conf or ~/.asoundrc. This method doesn’t replace the amixer commands but can be used to set default behaviors.
Here’s a quick guide to set up a systemd service for your needs:
also @georgiy.lutsenko is reporting that the configuration is there after reboot but it is just not working.
If the configuration was saved and applied during boot but is not working as expected, there might be a couple of potential reasons:
Race Condition: It’s possible that your script is running before the sound modules or services have been fully initialized, leading to a race condition. In this scenario, the settings might not apply correctly.
Overwritten Settings: Another service or system routine may be overwriting your settings after they’re applied during boot.
Let’s address these potential issues:
1. Delay the Execution
You can modify the systemd service to wait for the sound system to be fully initialized. You can achieve this by making your service depend on the sound.target:
Edit the /etc/systemd/system/alsa-setup.service file:
If you’re using a desktop environment like GNOME or KDE, they might have their own sound services or daemons that are overwriting your settings. You might need to check their documentation or settings to ensure they’re not interfering.
3. Diagnostic Steps
Check Logs: After reboot, check system logs to see if there’s any relevant information:
sudo journalctl -u alsa-setup.service
This will give you the logs specific to the alsa-setup service. Look for any errors or warnings.
Manually Run After Boot: After reboot, if the settings aren’t working, try manually executing your script:
sudo /usr/local/bin/alsa_setup.sh
See if manually running the script after boot makes a difference. If it does, it’s a strong indicator of a timing issue during the boot process.
These steps should give you more insight into what might be going wrong. If the issue persists, you may need to dig deeper into the specific behavior of the Jetson Nano’s sound system or other system components that could be interacting with your ALSA settings.
If so we can track in single query for better tracking. FYI. ALSA conf files are present to apply mixer controls during the boot. I don’t see need for separate scripts. But I will work with you to sort out the issues.
