Hi,
The board looks specific to raspberry pi and pins may not be compatible with Jetson Nano. Other users may have experience of porting it to Nano and can share here.
Hi,
Sorry for late reply. We are still evaluating to support it in future releases. It is pending and under discussion now. The new release of JetPack(r32.3.1) does not support it by default. Would need other users to share experience.
I saw that it is not supported by default, which is fine.
I’d like to help setting it up if possible.
If I understood correctly, the kernel module should be installed (not so complicated a priori) and the device tree overlay should be written for it.
I’ve read the device tree for the supported microphone and soundcard but that doesn’t really help me to find out what to write for pisound.
Also I think activating i2s4 in “configure 40-pin expansion header” is not enough to make pisound work, so the device tree should be written by hand rather than by the jetson-io.py, am I correct?
I’ve kept on digging a bit, I didn’t go forward much but I have a new bunch of questions
The only place I find overlay files is in the download directory of JetPack when I untar the linux folder (under kernel/dtb). They are in binary format so I have to use dtc to convert them and read them. When I read those files (both overlays and original device trees), there are hexadecimal adresses everywhere. It makes it pretty difficult to read, understand and create new ones. I guess that those hexa adresses appeared after compiling the written device trees (and overlays). Is that right? Could you share the original dts files please? And the overlays for the two already supported devices?
Is it intentional not to release the .dts files in the public sources? What would be the incentive for that?
Hello, I am one of developers at Blokas, please feel free to reach out to us if you’re interested to support Pisound via PM or contact e-mail at the bottom of our site https://blokas.io/
I took a quick look at the pinout of Jetson Nano and it seems like the critical pins the Pisound depends on should be possible to configure to function as needed.
We don’t own the devkit ourselves at the moment, so we can’t help much in practical stuff, but we can answer any questions regarding the kernel module or device tree for RPi.
Btw, I think I see .dts files within kernel_src.tbz2: hardware/nvidia/platform/t210/jetson/kernel-dts - not sure if that’s the right ones for the board.
You’re right, I didn’t inspect the hardware folder, I was now able to find the original overlay files in hardware/nvidia/platform/tegra/common/kernel-dts/overlays.
It is so much better with human readable overlays, I might give a try and right an overlay for Pisound.
I guess a reasonnable approach would be to write AN OVERLAY pisound.dts and add the corresponding binary file into the folder downloaded by Jetpack just before flashing. Am I right?
Yes adding a new overlay for the pisound would be the correct way to go. There is some high-level documentation available for adding overlays for custom hardware. Please see …
For the overlays that are included in the Jetpack release, the source in hardware/nvidia/platform/tegra/common/kernel-dts/overlays/ are written to be a platform independent. These dts files are then included by the overlay for each Jetson platform to create the platform specific dtbo file. For example, the Jetson Nano ADAFRUIT SPH0645LM4H overlay is located in the file …
I saw this documentation, thanks, but I cannot generalize to use it for Pisound.
That’s good to know, thank you.
I’ve read the overlays for ADAFRUIT SPH0645LM4H and FE-PI Audio Z V2 and I also cannot generalize from them. It looks like there are Nano specific parts which I don’t get.
How can I find the fields to edit in each fragment?
Where do I find the definition of tegra_sound and pinmux etc?.. In remember finding a file defining each pin but I cannot find it anymore.
Sorry but even if I’m willing to write this overlay, I’m quite lost. Surprinsigly, will is not enough, skill is also needed ^^
Are you able to share a schematic for the pisound board with us or at a minimum a detailed pinout for the 40-pin connector showing exactly what signals are used by the board?
I see from your website [0] that you show which pins are used by the board, but it does not show what each of the pins are used for. If we know what the pins are used for, then we should be able to create an overlay for pisound that works for Jetson.
Here is the list of pins that are used by Pisound:
Pin 11 - The Button GPIO input, when button is pushed down, it gets connected to GND, so the pin should be configured as a GPIO input with pull-up enabled.
Pin 19, Pin 21, Pin 23, Pin 24 - MOSI, MISO, SCLK, SS for SPI communication, the devkit should be the SPI master.
HAT I²C EEPROM containing DT overlay for RPi is attached on pins 27 and 28 - just in case mentioning here.
You may find all uses of the mentioned GPIO pins in the Pisound kernel module source code here. Search for ‘gpiod_get_index’. In case ‘gpiod_to_irq(data_available)’ does not return a proper value on Jetson Nano, this part must be modified to use the correct value.
And for reference, current overlay for RPi is available here.
Thanks for the information. I have been reviewing the source code for the DT overlay and kernel module on the github page [0] for the pisound board. I don’t see any reason why we cannot make this work, but the majority of the work will be porting the kernel module to work with the Tegra Audio Processing Engine soundcard driver. The current version of the L4T documentation [1] does have some information on adding support for new codecs via the 40-pin header. This is quite advanced but we can support people that wish to do this.
It does seem advanced for me right now. I’ll let you know if I try to get to it.
In the mean time, I’m using an USB sound card, I don’t know the gain in speed I could expect from a GPIO-based one.
I’m working on very low latency audio processing (around 5ms) so the roundtrip latency of the card is very important.
I’ll look more into it if I feel limited over USB.
Do you need the MIDI capabitilities of the pisound or just the analog audio capture/playback?
I am wondering if we need the kernel module itself to get the analog audio capture/playback working and if this can be accomplished purely in device-tree. If the audio ADCs and DACs do not require any configuration, which I believe that the audio DAC does not, then it could be quite simple.
Alternatively, if you are just looking for an I2S based codec, then we do have a configuration for the FE-PI Audio Z V2 board [0] that supports the headphone/mic inputs.
I do not need the MIDI capabilities, just record/playback indeed.
I did see the FE-PI Audio Z V2 board DTS and I was considering it as well but I found more docs on Pisound. In particular, I don’t see a roundtrip latency specification for the Fe-Pi board.
Sadly, I’m not knowledgable on this subject so I wouldn’t know.
Sorry not to be clear, but I did not expect you to know if device-tree change itself are sufficient to get audio capture/playback working. However, I can see from the DT overlay for Raspberry Pi that for the audio ADCs and DACs there is not much needed. However, at the same time I am not exactly sure what the SPI chip does and if the various GPIOs are needed or not.
Please note that the round-trip latency will be different for pisound on Jetson as well. You will see from the pisound webpage that this was measured on a RPi2 device and will most likely vary depending on the platform or version of the platform you are using with pisound. So I would treat that as a guide. However, I can understand that at least it goes give you an idea of what to expect.