Hard to tell from that video what is going on but with 16-bit data the I2S frame will be half empty. Input LRCK to scope channel 1 and SD to channel 2 and view single pulses triggered by LRCK. If you repeat that a few times you should be able to see whether or not data is the same in every sample.
It is working now! 192 kHz @ 32 bits - pure sound! The reason of strange SAI behaviour was Data Cache. Just disabled Data Cache and sound distortions desapeared! SAI DMA is used in normal mode.
For those who may be interested in SAI behaviour with Data Cache enabled / disabled, what I tried explaining in the previous post, here are diagrams received by means of a logic analyzer.
1) Data Cache enabled. It is seen that data (line 2) are lost periodically
2) Data Cache disabled. It is seen that data are never lost, transmitted permanently.
3) Data Cache disabled, previous diagram is zoomed in, test data 0x0F are transmitted.
@bohrok2610, thank you very much for your time and support! You helped me a lot!
For those who may be interested in SAI behaviour with Data Cache enabled / disabled, what I tried explaining in the previous post, here are diagrams received by means of a logic analyzer.
1) Data Cache enabled. It is seen that data (line 2) are lost periodically
@bohrok2610, thank you very much for your time and support! You helped me a lot!
D-Cache and DMA is terrible in STM32F7/H7.
As disable D-Cache at all is not a good idea for other firmware parts, it is better to make the separate RAM area for DMA buffers, and define it with MPU as "non cacheable", while other RAM remains cacheable.
Nice to hear that it is working!
This D-cache issue was already discussed in another thread https://www.diyaudio.com/community/...bit-stereo-balanced-input.390996/post-7162632 (post #89 onwards).
I have D-cache enabled and have separate RAM for DMA buffers using MPU but in my case I did not see any issues even with D-cache disabled.
@bohrok2610, how do you play 384 kHz / 768 kHz audio? I have not managed to do that yet. Windows lists 384 kHz in audio device settings but when I choose for example 384 kHz @ 32 bit (or 384 kHz @ 24 bit) and then click play button in a player, player seems to be playing audio but via debugger I can see that no data are transmitted to audio device from PC.
I mean: what player do you use?
I mean: what player do you use?
In Win10 wasapi exclusive played any samplerate my linux UAC2 gadget was configured to support/report, tested up to 4MHz https://www.diyaudio.com/community/threads/linux-usb-audio-gadget-rpi4-otg.342070/post-6725714 . IIRC foobar2000 + the wasapi exclusive plugin played any-samplerate wav/flac too (generated e.g. with sox).
I had a look at the different readme information and key file headers. Most examples are related to 2 channels/stereo. I haven't seen examples/projects related to UAC2 multichannel features. So from this quick look, it is unfortunatly not demonstrated that USB multichannel audio would be easily achievable on the stm32 MCU.
The NXP IMXRT10xx range seems to be in a better position there. I downloaded their SDR, and looking at their examples, thay have some USB multichannel ones (5.1).
I really appreciate the stm32 and their Nucleo boards. We just miss a good USB UAC2.0 stack.
I have seen the tinyUSB and CherryUSB codes, but I don't know how mature they are for that application.
I do not know how what data layout stm32 requires for multichannel SAI, but in linux USB audio gadget the number of channels is just a parameter, used on a few places. The blocks of interleaved samples delivered by each USB packet are just copied to the output buffer. Sending more channels just means receiving a longer block of bytes.
This is basically how it works with STM32 as well (and probably with any other MCU). But as each SAI in STM32 caters for 2 channels multichannel audio samples requires more than one output buffer. E.g. 5.1 audio would require 3 buffers.
Hi, Since 2015 I have identified all the potential of those SAI. They can also get a dedicated Cristal for the audio clock, to get clean 44.1k and 48k.
But it took m monthes to achieve a USB asynchronous mode, as it was not covered by the stm32 ST code, despite on the paper it was 100% feasible. Good Hardware, imcomplete software... For my part I won't dig in a new uncertain aventure here with my limited knowledge of USB standard and coding skills. I'm just good at adjusting almost good examples and integrating some ;-)
But NXP has the UAC2 stack. Could be easier to switch to those...
The fact that ST does not releases a UAC2 official stack is a no go for me unfortunatly...
JM
But it took m monthes to achieve a USB asynchronous mode, as it was not covered by the stm32 ST code, despite on the paper it was 100% feasible. Good Hardware, imcomplete software... For my part I won't dig in a new uncertain aventure here with my limited knowledge of USB standard and coding skills. I'm just good at adjusting almost good examples and integrating some ;-)
But NXP has the UAC2 stack. Could be easier to switch to those...
The fact that ST does not releases a UAC2 official stack is a no go for me unfortunatly...
JM