Playing raw data '/dev/zero' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:1":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S32_LE
SUBFORMAT: STD
SAMPLE_BITS: 32
FRAME_BITS: 64
CHANNELS: 2
RATE: 48000
PERIOD_TIME: (666 682667)
PERIOD_SIZE: [32 32768]
PERIOD_BYTES: [256 262144]
PERIODS: [2 2048]
BUFFER_TIME: (1333 1365334)
BUFFER_SIZE: [64 65536]
BUFFER_BYTES: [512 524288]
TICK_TIME: ALL
--------------------
aplay: set_params:1352: Sample format non available
Available formats:
- S32_LE

>what rate does snd_pcm_hw_params_set_rate_near return
48k

RATE: 48000

Your hw:1 supports only 48k. Since you are playing with plughw, the plug plugin always resamples to 48kHz and the device always runs at 48kHz.

I forgot to mention:
I made this dump for "plughw" and for "hw", with the same results.
I assume that the only limitation is software/firmware (peripheral driver, or someting), not the hardware itself.
On page 40 of this thread, someone was running I2S at 768, 1024 and 1536 kHz succesfully.
Even if it was a different RPi modeli, I don't believe that the dump returned that it supports such frequencies (1024 for sure, because it's not even an audio frequency). But changing the driver to special/dedicated one, made it work.
So I believe that the same can be done on RPi Zero 2W, the only question is how.

everito wrote: ↑

Wed Feb 05, 2025 7:01 pm

I forgot to mention:
I made this dump for "plughw" and for "hw", with the same results.

That's rather unusual as the plug plugin typically reports full rate range because the plugin deploys a resampler for any rate unsupported by the plugin slave device.

I assume that the only limitation is software/firmware (peripheral driver, or someting), not the hardware itself.
On page 40 of this thread, someone was running I2S at 768, 1024 and 1536 kHz succesfully.

I could not find any such discussion on page 40, there is a discussion about PDM microphones on page 41. But that is not I2S.

I have had RPi4 I2S running at 768kHz as well as 1.536kHz https://www.diyaudio.com/community/thre ... st-6654924 . But my rig has a flexible clock generator and the RPi4 I2S interface was a slave. Such setup requires changing the hw_params of the RPi i2s driver, as well as hw params of the SPDIF driver which you use in your DTS (I used the same DTS config from github)

But the data lines were already skewed against the frame clock lines, and running at 768kHz required modifying DAC/ADC I2S configs along with RPi4 I2S defaults directly in the driver, to get the communication running correct.

Even if it was a different RPi modeli, I don't believe that the dump returned that it supports such frequencies (1024 for sure, because it's not even an audio frequency).

The dump returns whatever hw params are configured by the driver. If you add 1024 to the driver hw_params, it will report 1024.

But changing the driver to special/dedicated one, made it work.

I have not seen any special/dedicated driver for RPi I2S, only the one in the mainline/rpi kernel.

So I believe that the same can be done on RPi Zero 2W, the only question is how.

I have not played with Zero 2W. First you should investigate why hw:1 reports only 48kHz - check the kernel driver source code. Maybe Zero 2W has some limitations there.

Ok, so it is better for now to check it on some bigger Rpi as you proved it worked there. I checked the aplay command on an Rpi3B but got only 48k there - should 3B be equivalent to your Rpi4 for tests ?
I also have an Rpi4 and 5 but on both I am getting an arror:
aplay: main:831: audio open error: Unknown error 524
It seems it is some missing I2S config but using some suggestions from the net did not make it work yet - maybe you could have some suggestion so I could have a possibility to check on more HW ?

everito wrote:aplay: main:831: audio open error: Unknown error 524

Does dmesg give some clues?

Do not have experience in analyzing this log unfortunately, I have not found anything related to I2S at least but if you could kindly have a look ?

> I have had RPi4 I2S running at 768kHz as well as 1.536kHz
That;s great news so at least on Rpi4 768k that would be very useful for me is achievable (sooner or later :). I am not sure from the thread you quoted if there is also a chance of getting bit-perfect 1,5M ? It seems you mentioned 1024 as the limit for the error-free transmission ?
Do you think using full I2S 2x32 frame bits is also possible ? I remember a collegue testing this 32-bit feature some time ago and he got standard 2x24 bit and could not find a relevant config in the I2S HW registers that could toggle the frame size to 32 bit.

>But the data lines were already skewed against the frame clock lines,
I am not quite sure what you mean by data lines being skewed ?

Do you actually have the I2S module loaded? Do you output to the I2S alsa soundcard?

Yes, that's also my feeling that I am missing sth fundamental for RPi I2S here.
I have good experience with audio and I2S in general; but unfortunately not in configuring the Linux ALSA I2S port on Rpi.
I very much appreciate your expertise and insight, if you could suggest some links/threads where the I2S module load and output to the I2S alsa soundcard is described it would help me greatly on my Linux RPi learning curve :)

To be honest, I am afraid that the gap between the basics of listing audio devices and tweaking your device to run at the large samplerates you mention is rather large, unfortunately.

List of audio devices: aplay -l

To make some I2S soundcard initialized you need to define an overlay for it - e.g. https://github.com/AkiyukiOkayasu/Raspb ... I2S_Master

I'm writing i2s device driver for raspberry pi 4 with kernel 5.10.
I have registered i2s interrupt with number 79 (I2S_INTERRUPT) by calling funtion

result = request_irq(I2S_INTERRUPT, (irq_handler_t) i2s_interrupt_handler, IRQF_TRIGGER_RISING, DEVICE_NAME, NULL);
if(result < 0)
{
printk( "Failed to acquire I2S interrupt %d. Returned %d", I2S_INTERRUPT, result);
return -EBUSY;
}

function return success, but when I send data to i2s , interrupt handler will never call. Anyone have experiment with these ?