Rockbox

Looking on the webpage, the last change aside from button mappings was in March. Are you sure it worked this summer? You could checkout and compile r20562 -1 to see if it 20562 interoduces the problem.

another commit that afected midi playbcak on the ipod video is 20635 which introduced 22kHz playback capability for tthe ipod video which the midid plugin uses when available.

Yes, that was it. All pre-20635 versions play MIDI fine, in excellent 44.1 kHz mixing frequency and all without aliasing effects.

All versions starting from 20635 play MIDI files in very bad quality, with aliasing frequencies, probably due to downsampling to 22 kHz without interpolation / decimation filter.

I suppose to change the MIDI plugin to *always* use 44.1 kHz sample frequency / mixing frequency on iPod, for best playback quality. iPod 5G plays MIDIs just fine at this frequency since the buffer handling has been optimized some builds before 3.2 (if I remember correctly right now). Okay, you shouldn't play files with a whole symphony orchestra playing "tutti" over several measures or so - but it works well and it is much better than distorted, aliased 22 kHz playback with maybe a longer buffer instead.

Btw. Why has been 22 kHz Playback support been added anyway? What is its use besides the midi plugin?

Maybe the MIDI plugin could get added an option to choose which mixing frequency to be used? And if 22 kHz is selected, a proper interpolation should be done!

Anyway, thanks for the information! For now, I'll stick back to an old version without 22kHz playback, until there is a solution to this problem. Keep up the *great* work!

Best regards, kzuse

AFAIK its not down sampled, the native sample rate is actually 22.1kHz. If it aliases, its probably due to a bug in the synthesizer.

Yes, it just generates 22kHz sound instead of 44.1kHz, there is no downsampling done, i have used the midi plugin quite a bit on a player that does 22kHz playback and while it doesn't sound as good as using 44.1kHz, I wouldn't describe it as horrible. Assuming that the ipod video 22kHz playback is done correctly it should sound the same, If the aliasing is a bug in the synth or not i can't comennt on but the reason for using the lower sample rate is that it is *much* faster and will play much more complicated files without stuttering.

MIDI playback actually never has a "native sample rate", because all the different Instruments are just samples that are played at different pitches, thus resulting in different sampling rates for each note, if you want to put it that way.

Wavetable MIDI sound output always results in mixing different instrument samples together, which is done at one specific mixing rate. For me on my iPod 5G, the 44.1 kHz rate sounded much, much better. I have some piano tunes that introduce a strange, ringing distortion in every note. This sounds very bad to me. I would prefer an option to choose 44.1 kHz sample rate for MIDI playback manually, even if the player supports 22.05kHz. There has not even to be a GUI to this option, maybe just read out a setting "midi.ini" file in the .rock plugins folder or so.

This would be great.... :-)

Anything new on this issue?

I think I might be experiencing this issue on my iPod Nano 2G as well. MIDI files play at the wrong pitch and sound awful. Also, attempting to play one causes the iPod to begin emitting audio static until it is rebooted.

This does not cause midi to play at the wrong pitch and it does not cause a player to emit static noise, it just samples audio at a lower sample rate if the hardware can handle it, now the nano2g has the defines for this so what you are experiencing is likely a driver bug triggered by using this sample rate on that player.

This "bug" is however a trade off between better sounding higher samplerate but with more horribly sounding buffer underrun skips or lower worse sounding sample rate but fewer skips. The midi plugin is in need of serious optimization to be able to play most files at 44.1kHz on pp based players like the ipod video so i'm reluctant to change this, players with faster chips like the nano2g could still use 44.1kHz even if the hardware can go lower.

Thanks; I will file another bug.

Also on iPod 5G it *definitely* causes aliasing and also wrong pitch of certain notes. It is a fact. (But the static noise I couldn't recreate).

I don't know what is causing it, whether it is the MIDI plugin or it is the 22kHz driver or core capability - I just know that it sounds horrible and definitely worse than occasional skips.

What about my idea to implement an option in to the MIDI plugin, whether to always use 44.1 kHz (which would be my favorite setting), or to use 22kHz if available on the device. That would serve everybody!!! :-)

Best regards, kzuse

@Michael Marley (mamarley) I have the same problem, too. I only hear high-frequency noise (White Noise).

With the latest Builds (r25889) the "wrong pitch error" is gone, all instruments seem to play the right notes.

But still, there is a HEAVY aliasing in playback which was not there back then when 44.1kHz were used for MIDI. Maybe it is the iPod hardware that doesn't apply an imaging filter for 22.05 kHz.

Btw, I could not find that wirh 22.05kHz there is less skipping or left-out notes. I find we should go back to 44.1 kHz on ipod for MIDI as it brings much better sound and does not significantly "skip" more in MIDI. I will keep watching this issue.

best regards, kzuse

Info: for me personally I finally fixed the problem by building the MIDI plugin for myself. I just removed the IFDEF at the beginning of midiutil.h and forced it to use 44 kHz by just leaving the line

#define SAMPLE_RATE SAMPR_44

This is better for iPod, believe me, 22 kHz sounds crappy on it...
I recommend everybody of you, who also finds this disturbing, to do so. It's the easiest way to get rid of it.

I just did the same on my Nano2G, and it works great.

Somehow the configuration in midiutil.h is strange. E.g. for PP processors MAX_VOICES is set to 16 because "those targets mainly use 44100 Hz sampling rate". r20635 implemented other sampling rates as 44100 for the iPod Video, since then 22050 is used for this target -- without increasing MAX_VOICES...
So, we should either go back to 44100 Hz (and stop aliasing) or increase MAX_VOICES for PP-targets which do use sampling rates <44100 Hz.

I'd really recommend going back to 44 kHz as it sounds so much better (on iPod at least). It's the only device I can test it on.

But, as I mentioned above, I changed midiutil.h to always use 44 kHz, as in former times, and it is such a relief not to hear those aliasing frequencies and have an overall better sound quality, that I would really recommend to go back to 44 kHz by default.

Just my EUR 0,02... :-)

Indeed, the aliasing sounds nasty. The attached patch does change the synthesizer to always use 44.1 kHz. For PP CPU's the max amount of voices is limited to 20.

The attached patch v06 implements the following changes:
- Use 22 kHz if supported, except for iPod Video (produces aliasing artifiacts)
- Use up to 20 voices for PP in case of 44.1 kHz sampling rate (beyond that I experience buffer misses)
- Move some data to IRAM
- Introduce panSample macro which avoids multiplication and shifts for balanced panning (pan = 64)
- Change sample calculation to int16 instead of int32. This is slower but correct.

Some comments on the patch:
1) Testing some more files on my h300 i hear the ringing or aliasing on some files but not on the ones i used for testing before :/
2) The conditional pan multiply doesn't bring any speedup for cf
3) The patch slows down midi by ~10% on cf

While i agree that correctness is more important than speed i'd like to try out doing it correctly while keeping the sample buffer 32 bits and will hopefully find the time for that in the near future.

Edit: If we want to go all-out we could mimic what the ape codec does, since it also deals with packed 16-bit values for cf and >= ARMv5 while keeping the 16 bit samples as 32 bit for ARMv4 as the unpacking and repacking cost more than the gain from the reduced mem usage there.

Also something with the pan==64 case looks fishy to me, *64 should equal << 6 but the samples were shifted >> 7 and << 9 which would equal a shift of >> 1 for both but you don't shif them at all.

Lots of targets have SAMPR_CAP_22 in HW_SAMPR_CAPS, so it's suspicious if this only or mainly happens on the 5G iPod. I just reviewed the WM8758B datasheet at http://www.wolfsonmicro.com/documents/uploads/data_sheets/en/WM8758B_1.pdf because it wasn't available when I worked on  FS#10086  / r20635. I don't see any problems which would cause aliasing. The relevant part of the datasheet is this:

>The WM8758B filter characteristics for the ADCs and the DACs are set using the SR register bits.
>The cutoffs for the digital filters and the ALC attack/decay times stated are determined using these
>values and assume a 256fs master clock rate.
>If a sample rate that is not explicitly supported by the SR register settings is required then the
>closest SR value to that sample rate should be chosen, the filter characteristics and the ALC attack,
>decay and hold times will scale appropriately.

You can see the ADDCTRL_SR_ defines in firmware/export/wm8758.h and their use in firmware/drivers/wm8758.c. Sample rate calculations are in a spreadsheet at https://docs.google.com/spreadsheet/ccc?key=0AsEpnuZKewlIcmhFRXYtN0RVQTMtSVllWGUyeUI2aUE&hl=en_US#gid=0

You could try changing the ADDCTR_SR_ values in freq_setups, using the value below the frequency instead of the closest value which is above the frequency. I'm attaching a patch which does this for 22 kHz. I'm not sure if it actually helps. Even if it does help, that doesn't mean there's a driver error, because it could cover up aliasing in the audio being played. Doom uses 11 kHz. Is there aliasing there?

After a long time I installed a new Rockbox Build on my player (3.11.2), before I had 3.6.something with my "custom" midi.rock which (just patched privately for me) in "steamroller method" just always uses 44.1kHz - which worked (and sounded) fine.

Now with the new build, aliasing/ringing is there again! I actually thought, due to the comments you've added some months ago, that it has been fixed by no longer using 22kHz on iPod targets?
Or did I get that wrong, and the patch(es) you've attached above didn't make it into the normal trunk?

Is there a chance this could be done? So iPod Video users don't always have to patch for themselves for every new release? :)

Thanks a lot!