FS#10086 - 5G iPod WM8758 codec sample rate setting

Attached to Project: Rockbox
Opened by Boris Gjenero (dreamlayers) - Wednesday, 01 April 2009, 19:17 GMT
Last edited by Boris Gjenero (dreamlayers) - Tuesday, 07 April 2009, 16:34 GMT
Task Type Patches
Category Drivers
Status Closed
Assigned To No-one
Operating System iPod 5G
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Currently, the only sample rate supported on the 5G iPod is 44100 Hz. This patch adds support for all other rates which can be supported both by Rockbox and the codec. Supported rates are:
48000, 44100, 32000, 24000, 22050, 16000, 12000, 11025, 8000

The patch is based on the WM8983 datasheet, because the WM8758 datasheet is unavailable. The WM8983 supports sample rates between 8 and 48 kHz. It would be easy to compute settings for 96000, 88200 and 64000, but I think it's best to not overclock the codec.

This is patch was inspired by problems with Doom sounds: . With this patch, a compile-time check makes Doom use 11025 instead of 44100 and then sounds work properly. However, there may be another underlying issue which needs to be looked at: sound from plugins may underrun too easily. In test_sampr, merely scrolling through a list causes underruns.

This does absolutely nothing for standard audio playback. There doesn't seem to be any sample rate changing support there, and so software resamples to 44100 if necessary.

The same process which sets playback sample rates also sets recording sample rates. I have enabled use of all of the new sample rates for recording. I haven't been able to test this however, because I don't have a line in adapter. Playback sample rate changing may be tested via the test_sampr plugin. To build it, add test_sampr.c it to apps/plugins/SOURCES.
This task depends upon

Closed by  Boris Gjenero (dreamlayers)
Tuesday, 07 April 2009, 16:34 GMT
Reason for closing:  Accepted
Additional comments about closing:  Committed in r20635
Comment by Michael Sevakis (MikeS) - Thursday, 02 April 2009, 01:09 GMT
> However, there may be another underlying issue which needs to be looked at: sound from plugins may underrun too easily. In test_sampr, merely scrolling through a list causes underruns.

They shouldn't underrun. The only thing I'd expect is glitches when changing rates on the fly (not minor ones either). Anything <= 44100 should definitely work since it's an equal or lesser load than core playback. If there are underruns under a steady rate, then it's something else surely. The pcm DMA code attempts to maintain a constant period of DMA interrupts for all samplerates for the PCM tick so maybe there's an issue with that?
Comment by Boris Gjenero (dreamlayers) - Thursday, 02 April 2009, 05:48 GMT
The sampr_test list scrolling underruns (which happen even if code is commented out so audio settings don't change) and the Doom 44100 Hz underruns might happen because both plugins compute data in get_more and return short chunks of samples. Setting OUTPUT_CHUNK_SAMPLES to 32000 in test_sampr.c gets rid of glitches while scrolling through the volume list. BTW The same things happen in Rockbox 3.1, so the PP502x I2S DMA code is not causing this problem.

Just to clarify again: The underruns in plugins aren't a problem with this patch. This patch stops underruns in Doom because Doom can use the 11025 Hz sample rate when it is available. I feel that Doom probably should not underrun the buffer at 44100 Hz, and there may be another entirely separate bug there.
Comment by Boris Gjenero (dreamlayers) - Sunday, 05 April 2009, 23:01 GMT
I just recorded PCM wave files at all sample rates. Recording works properly.
Comment by Boris Gjenero (dreamlayers) - Monday, 06 April 2009, 02:49 GMT
Committed in r20635. I'll leave this open for a few days.
Comment by Gman (Thecoolgman) - Tuesday, 07 April 2009, 13:50 GMT
This patch works great