Hi all,
So, after almost half a year of arduous blood, sweat and tears I have managed to scrape together "something that works". It consists of a custom schematic and PCB powered by an STM32F0C6T6 and an Si4705 radio tuner (from Skylabs).
The STM32 uses the internal clock circuitry that is configured as depicted here. The CRS sync source is not shown here, but it is set to USB, so that the chip runs completely without any external crystals. The USB 2.0 is full-speed since the STM32 is only full-speed:
The Si4705 currently uses a precise, external 32,768 kHz crystal oscillator (SG-3030CM from Seiko) that only requires a by-pass capacitor. This crystal oscillator is not connected to the STM32 in any way.
The tuner chip has a prescaler and precise REFCLK adjustment so it can, if required, support a frequency range from 31130 Hz up to 140,89 MHz. Currently these settings are in their default values due to the crystal oscillator.
The STM32 commands the Si4705 via I2C, without DMA, and this communication works just fine. The relevant settings are shown below:
The STM32 also uses I2S and DMA to transfer data, and its settings are as shown here:
There are also several other settings that are related, and which can all be adjusted:
- The Si4705 has a programmable sampling rate and bit resolution for I2S, and they are currently set to 44117 Hz (as per "Real Audio Frequency" from the STM32's I2S) and 16 bits (per channel)
- The DMA buffer in STM32 is 352 bytes long
- The I2S DMA transfer is initiated with value of 176 "16-bit data lengths" (whatever that means in reality)
- There is a single EP1 IN that uses double-buffering, and the two PMA areas involved are both 176 bytes each
- At half-complete and full-complete DMA interrupt the STM32 transfers either 176 bytes from the start of the DMA buffer, or 176 bytes from the half-point of the buffer
- The USB Audio 1.0's Audio Type I Format is 2 channels, sub-frame size of 2, bit resolution of 16 and frequency of 44,1 kHz
- The USB Audio's Audio Streaming Endpoint uses 176 bytes as max packet size, and interval of 1
With these in place, I have managed to obtain "almost acceptable" audio from the tuner device, recorded it, and attached both an MP3 and a WAV sample here.
However, I am not exactly sure which of all the various settings I should try to adjust in order to overcome the clear skipping/stuttering that the audio has. I have tried fiddling with all the above settings but no matter what I try I only seem to get worse results. Clearly I do not fully understand how all these various settings work together to produce the end result.
Unfortunately all the code, schematics and what-not are only on my computer so I cannot upload the full project anywhere. I am in the process of putting it to GitHub for everyone to use but I am having issues in writing the licenses correctly so that its "free to use for all but commercial purposes". Especially since the code is half-and-half by ST's HAL / USB Device Library and my own produce.
If I look at the Wireshark output I see an almost-clear recurring phenomenon: the device first sends approximately 22 frames with 1760 packet data length (10 microframes), then several frames with 1056, 880 or 1584 data lengths, before resuming with 1760 ones. Even these "shorter" packets claim to have 10 microframes in then. This repeats around every 22-24 frames but sometimes there's up to 30 "clean" frames before the shorter ones occur again.
This looks like a a bus saturation issue to me, with the host side unable to keep up. What kind of things I could do in order to try solving this? I know I am not far off from the result.
